Axelar
Axelar connects cross-chain messages with destination execution
Axelar connects blockchains so applications can transfer supported tokens and send instructions to contracts on another network. General Message Passing carries those instructions, while destination execution requires compatible contract logic and gas. A confirmed source transaction records the request; successful destination execution establishes whether the requested action occurred.
Last updated ยทIn this guide
Key takeaway: A cross-chain message needs compatible destination logic and sufficient execution gas for the approved call to produce the intended contract change.
Match the destination before authorizing a transfer
The destination must support the intended operation before an application commits assets or sends a cross-chain contract instruction. Compatibility includes the network, deployed contract, message format, and any token integration the operation requires. A connected blockchain does not make every application or asset on it compatible. For a token transfer, the receiving token contract matters alongside the recipient address. For a contract call, the receiving application needs logic capable of processing the message.
Applications submit requests through the source gateway, and the network processes those requests for the destination. The source transaction identifies the original instruction. Destination approval permits execution, while the destination receipt and resulting contract state establish what actually happened. These records describe different parts of the operation. A source-side debit alone does not establish delivery to the intended recipient.
What does the cross-chain gas payment cover?
The Gas Service accepts a source-chain prepayment to fund the processing and destination execution of a General Message Passing transaction. This payment supports automated delivery without requiring the sender to perform the final transaction manually. The initiating transaction also consumes gas on its own blockchain. Applications need to distinguish that local transaction cost from the payment funding work across chains.
Destination congestion can raise execution costs after the initial estimate. An insufficient prepayment can therefore leave a request awaiting additional funds. Manual destination execution provides another payment path when the message has approval and the contract call remains valid. Neither payment method changes the receiving contract's compatibility requirements.
Choose between message delivery and token movement
The required destination action determines whether an application sends data, transfers tokens, or combines both through an appropriate integration.
General Message Passing carries application instructions
General Message Passing supports cross-chain contract calls without an attached token transfer. The payload contains the data the receiving application interprets. On supported gateway-token integrations, an application can also send a message with tokens. That capability does not extend automatically to arbitrary assets. The destination needs the corresponding executable logic for the chosen message type.
Interchain Token Service connects token deployments
Interchain Token Service, or ITS, supports creating interchain tokens and integrating eligible existing tokens across supported networks. Token managers implement the asset-handling behavior. A mint-and-burn integration destroys tokens on departure and creates them on arrival, subject to the required permissions. A lock-and-unlock integration holds tokens in a manager and releases them when the corresponding transfer returns. The selected integration determines the destination representation and the permissions needed to maintain it.
Gas parameters bind payment to execution
The Gas Service's EVM payGas method accepts a destination, an execution gas limit for estimation, and a refund recipient. These parameters describe the particular call. They are not network-wide defaults, and a larger payment cannot correct an incompatible destination.
| Parameter | Accepted value | Requirement or outcome |
|---|---|---|
| destinationChain | String identifying the target chain | Must identify the intended supported destination |
| executionGasLimit | Unsigned integer specifying execution gas units | Must account for the destination call's gas requirements |
| refundAddress | Address designated to receive a gas refund | Receives any applicable refund on the source chain |
| These call-specific values determine where execution funding applies and where any refundable remainder goes. | ||
The method also accepts an on-chain estimation flag. When enabled, its payment check rejects an amount below the calculated requirement. That check concerns the gas estimate; it does not establish that the destination application's own conditions will pass.
Authentication and token controls define the security boundary
Message authentication, application permissions, and token controls address different failure conditions. Each affects what the receiving system can safely execute.
Gateway approval authenticates the message
Axelar uses proof-of-stake consensus for its blockchain network. Its message-processing infrastructure validates cross-chain requests before authorizing destination actions. Relayers transport requests and authorized messages through that process. Transporting a message does not give a relayer permission to invent its contents.
The receiving application remains responsible for interpreting authenticated data and enforcing its own permissions. Authentication does not establish that every requested application action is appropriate. The executable contract supplies the integration point for that application logic.
Token permissions and flow limits restrict movement
Mint-and-burn managers need the token permissions their operations require. ITS also supports configurable flow limits restricting token movement through a manager. Authorized roles can adjust those limits, so the applicable ceiling depends on the manager's current configuration. A transfer can encounter a token-control restriction even when its gas funding is sufficient.
Why can an approved message remain unexecuted?
An approved message can remain unexecuted because destination execution still needs sufficient gas, transaction inclusion, and successful application logic.
Destination approval and successful destination execution are separate states in the General Message Passing workflow. The transaction record distinguishes a request awaiting approval from one ready for execution. That distinction determines whether a recovery action concerns message delivery or the receiving contract call.
An insufficient-fee condition calls for additional execution funding. A contract execution error requires examining the failed call and its error instead. Paying more cannot repair invalid payload handling or missing application permissions. Recovery tools support gas additions and manual execution, but the relevant action depends on the recorded failure.
Retrying an existing request and submitting a new source request are different operations. Preserve the original transaction identity when investigating a delay. A new submission does not resolve the status of the first one.
Account for delivered assets and unused gas separately
A completed destination action and a gas refund produce separate records. For transfers, compare the destination execution record's token contract, recipient, and credited amount with the original request to verify delivery. For messages, the receiving application's state establishes the effect of execution. Unused prepaid gas follows the refund mechanism on the source chain and goes to the designated refund address. That refund concerns execution funding; it does not reverse the application action or return the transferred principal.
Practical questions
Is holding AXL necessary to pay for every cross-chain application call?
Holding AXL is not a universal requirement for an application call using source-chain gas prepayment. The Gas Service supports native-currency payment methods on the source chain. The application determines which payment path it exposes, so the asset required for its transaction can differ from the network's staking token.
What determines the time an Axelar transfer takes?
Transfer duration depends on source-chain finality, network processing, and destination-chain execution conditions. Different blockchains reach finality differently, and congestion changes transaction inclusion times. A source transaction appearing in a block does not necessarily mean the cross-chain service can already treat it as final. These dependencies prevent a single completion time from applying to every route.
Why does a successful token approval leave the transfer unfinished?
A token spending approval grants permission for a contract to move tokens; it does not itself perform the cross-chain transfer. Some ITS integrations need that allowance before they can collect or burn the selected tokens. This wallet-level approval also differs from destination gateway approval, which concerns a particular cross-chain message.
Can a destination contract send a reply to the original chain?
A destination application can initiate a return message through a supported two-way General Message Passing integration. The reply requires another cross-chain execution, with sufficient funding for the return leg. Successful outbound execution therefore does not establish that the reply has arrived. The Gas Service supports this pattern and can require additional gas when the remaining payment is insufficient.
Does the gas refund have to return to the initiating wallet?
The application can designate a refund address when it pays for gas. Any applicable refund goes to that address on the source chain, which need not be the wallet initiating the application call. The configured refund recipient matters when checking a missing credit; the destination asset recipient may be a different address.