If your cross-chain transfer is pending after the source transaction confirmed, first find out whether the message is waiting to be delivered or failed during execution; those need different fixes. A confirmed send does not prove that the destination chain has completed the action.
A confirmed send can still be unfinished
“Confirmed” describes the transaction on the source chain, while the transfer may still need several more steps. The source contract emits a message; a verification network observes and signs it; then a delivery process submits it to the destination contract, which runs the application’s instructions.
In Wormhole’s messaging design, Guardians sign a Verifiable Action Approval (VAA) after observing a message, and a relayer can carry it to the destination. If verification is still in progress, there may be no signed message to execute yet. If the destination transaction reverted, the message arrived but the application action did not complete.
A multichain application may coordinate balances or other shared state across chains, so a delay can leave the source and destination showing different stages of the same action. For how to check omnichain message security, timing, and fees, read the separate guide; this one focuses on locating a pending or failed delivery.
The transaction records show where it stopped
Compare the source transaction with the destination record to identify the stalled stage. A quick what-if: if your source transaction succeeded and emitted a message, but there is no destination transaction, the delay is likely before execution; if the destination transaction reverted, look for an execution problem.
Follow these steps:
- Check the source transaction. Confirm that it succeeded on the correct source chain. If it reverted, the message may never have been emitted; check the transaction details before trying again.
- Find the message identifier. Look in the source transaction’s emitted events for the protocol’s message details. For Wormhole, these include the emitter chain, emitter address, and sequence number. Use them to match the message across records.
- Check verification status. See whether the message has been observed and signed. If verification is incomplete, wait and check again rather than submitting a new transfer.
- Look for destination execution. If a destination transaction exists, check whether it succeeded. For a revert, read its error details; the destination contract may have rejected the message or lacked the conditions needed to carry out the application action.
A pending message and a reverted message need different responses
If the message is still waiting for verification or delivery, note its identifier and check again after a reasonable interval. Timing depends on the source chain’s finality, the verification process, destination chain conditions, and the delivery design. A pending status alone does not tell you that the transfer failed.
If execution reverted, use the destination error and the application’s instructions to decide whether the same message can be retried. Some systems support a retry or manual delivery path; others require the application or its configured delivery service to handle it. A retry should target the existing message, not create a second transfer.
Before sending again, make sure the first message cannot still complete. Otherwise, both actions could eventually run, depending on how the application handles repeated requests. Don’t assume that a failed destination transaction means the original source action was reversed.
Resolve the failed stage before starting over
Once you know the stage, use the recovery path intended for it. In an omnichain application, message delivery and application execution are separate tasks, and the right recovery depends on which one failed.
Keep a short record of these details when you investigate:
- Source chain and transaction status
- Message identifier or sequence number
- Verification status
- Destination transaction status and revert reason, if present
With those records, you can tell whether to wait for verification, follow the application’s retry instructions, or contact the application team with a specific failure. Check the message again before repeating the original transfer.
Top comments (0)