Axelar
Axelar message status separates gateway approval from destination execution
Axelar message recovery starts by locating the original call and identifying its last completed stage before authorizing another transaction. A successful source transaction does not establish destination execution, and gateway approval does not establish application success. Match the source event to its destination record, inspect gas payment and execution errors, and choose recovery for that specific failure. Afterward, check the destination receipt and the contract state the call should change.
Last updated ·In short: Gateway approval permits destination execution; the matching transaction receipt and application state show whether the intended contract operation completed.
Approval authorizes the destination call but does not execute it
Gateway approval authorizes a particular message, while a separate destination transaction invokes the receiving contract with its payload. That separation explains how a call can remain approved without completing its application operation. In the standard EVM executable, gateway validation precedes the application's internal execution logic. A relayer or a caller executing manually must submit the destination call, the transaction needs sufficient gas, and the receiving code must accept the operation. Identify which condition remains unmet before paying for recovery.
Match the source event to the destination receipt
The source transaction hash anchors the investigation, but a transaction containing several messages also requires the correct event index. Keep the selected event consistent throughout status queries and recovery requests.
Preserve the original message details
Record the source chain, transaction hash, relevant event index, destination chain, receiving contract, and payload details. The source address in a gateway message identifies the calling application contract when that contract initiated the call. Substituting the wallet address changes the message identity. Preserve exact identifiers rather than reconstructing them from an interface label, especially when the same transaction contains several contract calls with different destinations.
Check the destination operation
A destination transaction hash identifies an attempt; its receipt establishes whether that transaction succeeded or reverted. Inspect the receiving contract's relevant events and state as well. Application code can handle a downstream failure without reverting its outer transaction, so receipt success alone may not establish the business outcome. Compare the resulting state with the operation encoded in the original payload. Token movement and an application instruction may require different completion checks.
What does the last completed stage tell you?
The last completed stage narrows the repair: missing approval requires relay investigation, insufficient payment calls for a gas top-up or a separately funded manual execution, and a contract revert requires diagnosis.
Source confirmation without destination approval
Source confirmation establishes progress on the originating chain. It does not establish approval at the destination gateway. A message still awaiting source finality differs from one whose relay failed after confirmation. Recovery tools can resubmit an eligible request for network processing, but they cannot substitute a user signature for network approval. Preserve the current status and any relay error before requesting recovery.
Approval without a successful execution
Inspect whether the executor submitted a destination transaction and whether its record reports insufficient funding. A missing transaction and a reverted transaction need different investigation. Payment status also has its own meaning: a recorded gas payment may still fall short of the execution requirement. Avoid treating every approved message as ready for an identical retry.
Validation failure or application revert
The standard EVM AxelarExecutable checks gateway approval using the hash of the supplied payload before invoking application logic. A validation error therefore warrants comparison of the command identifier, source chain, source address, receiving contract, and payload. Also check whether an earlier successful execution already consumed the approval. An application revert occurs further inside the receiving contract's execution. Decode its error using that contract's interface and inspect the failing condition.
More gas does not repair an invalid payload or a contract condition that still rejects the operation. A transaction trace or simulation can help locate that condition. Preserve the original bytes while debugging.
Source gas funding and destination execution incur different costs
Adding gas funds the service's handling of an existing message; manual destination execution pays for a destination attempt directly. The former requires a source-chain payment, including the transaction fee for submitting it. The latter requires destination-chain transaction funding. Compare those costs using the actual message and execution estimate. Neither option changes a receiving contract's acceptance conditions, and a changing destination gas price can alter the funding requirement.
The EVM Gas Service's addNativeGas function associates an additional payment with a source transaction hash and log index. Those identifiers must select the intended call. Check that the refund-address parameter identifies the intended recipient of any refund before signing. A top-up receipt proves the additional payment succeeded; it does not prove the destination contract completed its operation. Record the payment separately from any later execution transaction.
A higher gas requirement changes a recovery decision
Consider a hypothetical stalled EVM call with destination approval, no successful execution, and a reported gas shortfall. Assume the unchanged payload passes a simulation against the receiving contract's present state. These conditions support funding recovery without replacing the original message. The reader records the approval and existing payment, then obtains a fresh funding estimate for that same call.
The reader submits the source-chain top-up with the matching transaction hash and log index. Signing authorizes the top-up; successful on-chain execution transfers the additional payment and incurs the transaction fee. In this example, the payment receipt succeeds, the service submits destination execution, and the destination receipt succeeds. A follow-up contract read shows the state change specified by the original payload. The record now distinguishes the recovery expense from the completed application operation.
Change only the destination gas requirement before execution: if it rises beyond the funded allowance, the same payment no longer covers the attempt. The earlier estimate no longer supports proceeding unchanged. Rechecking payment and execution status establishes whether another shortfall exists before any further commitment. The relevant trade-off is the cost of additional funding versus a separately funded destination attempt, using refreshed estimates for each.
Keep an unresolved execution attached to its original message
An unresolved call needs its source event, destination attempt, decoded error, and current approval state kept together. Those details let the application maintainer investigate the exact operation without confusing it with a replacement request. Stop repeating a paid action when the same rejection persists. A repair must address the failing condition before another attempt makes sense. For an EVM validation failure, preserve the full error, including NotApprovedByGateway.
Questions worth asking
Why does a GMP status query return cannot_fetch_status?
A cannot_fetch_status response means the query did not retrieve a usable message status. It does not prove the source transaction failed or the destination executed. A newly submitted transaction may not yet appear in the indexed records. Confirm the transaction hash and selected environment, then inspect the source receipt before interpreting the missing status.
Can I inspect a stalled message without connecting a wallet?
Reading public transaction status does not require a wallet signature or private key. Transaction hashes, event records, and contract reads support diagnosis without authorizing a payment. A recovery action that submits a paid transaction is separate and may require a connected signer. Never enter a seed phrase into a status lookup.
Does editing the payload let an approved message execute?
Changing the payload prevents it from matching the original approval unless the resulting bytes remain identical. Gateway validation binds approval to the payload hash and other message details. If the application needs different instructions, its supported correction process must handle that change. Manual execution cannot rewrite an already approved message.
How can an application monitor recovery programmatically?
The AxelarJS SDK exposes queryTransactionStatus through AxelarGMPRecoveryAPI for programmatic status checks. Its response can include gas-payment information, approval details, execution records, and errors. Keep repeated reads separate from methods that submit transactions. A monitoring loop should not automatically repeat a paid recovery action merely because an earlier status remains visible.
Is submitting the original application request again the same as retrying delivery?
Submitting a new source request can create a separate cross-chain message, while delivery recovery targets the existing message. Replay protection for one approved message does not automatically deduplicate a newly created application request. Before repeating the source operation, determine whether the application prevents duplicate effects and whether the original message can still execute.
Could the wrong environment explain a missing recovery record?
A mainnet query does not locate a testnet message simply because it uses the correct transaction hash. Recovery configuration must match the environment where the source call occurred. Contract deployments and transaction records differ between environments. Confirm that context before treating an empty response as evidence of a relay failure.
What can recovery do when the source EVM transaction reverted?
Message recovery cannot relay a gateway event that a reverted source transaction never committed. Check the receipt before looking for destination approval. If the entire source transaction reverted, diagnose the source operation first. Repeating that operation after a correction creates a new attempt rather than completing an existing destination execution.