Retry a Failed Cross-Chain Message Without Duplicating It

Retry a failed cross-chain message only after you confirm whether it was delivered and whether its destination action already ran. A cross-chain transfer or instruction usually has separate stages: the source transaction is submitted, a message is relayed, and a destination contract executes it. A failure at one stage calls for a different response from a transaction that is merely delayed.

Before relayers and destination execution became common parts of cross-chain apps, users often thought of a transfer as one transaction. Now, a successful source transaction can coexist with a pending or failed destination action. The distinction matters: resubmitting on the source chain can create a second message, while retrying destination execution may safely reuse the original message if the app prevents duplicate effects. For more on the coordination problem, see this explanation of how omnichain apps coordinate state across chains.

How do you tell where the message failed?

Check the source transaction and the message’s destination status in the app or explorer for the protocol you used. Confirm that the source transaction succeeded, then look for a message identifier and a destination transaction or execution result. A confirmed source transaction proves only that the source-side action happened; it does not prove that the destination contract completed the requested action.

If no destination attempt appears, the message may still be waiting for delivery. If an attempt appears and reverted, inspect the stated reason where available: the destination contract may have rejected its inputs, lacked gas, or encountered a temporary condition. The protocol’s status labels vary, so use the transaction records and the app’s own guidance rather than treating “pending” or “failed” as universal states.

When should you retry instead of resubmitting?

Retry the existing message when the protocol identifies it as delivered but not executed and provides a retry path for that message. This can avoid paying for a new source action and reduce the chance of duplicate instructions. If the message is still in transit, waiting may be safer than starting over; relaying can take time, and a second source transaction may produce a separate message.

Before retrying, check these details:

• The source transaction succeeded and its message identifier matches the one shown by the retry interface.
• The destination attempt failed or remains unexecuted, rather than having completed successfully.
• The retry uses the protocol’s supported route and shows any execution fee before you confirm.
• The receiving app or contract can handle a repeated execution without applying the action twice.

Do not resubmit the original transfer just because the destination view has not updated. If the app offers no retry for the existing message, consult its recovery instructions or support channel before creating another source transaction.

What makes a retry safe?

A safe retry repeats delivery or execution of the same message, with the destination app recognizing that message as already processed if it succeeded earlier. That protection is called idempotency: repeating the request does not repeat its effect. It is a property of the protocol and application design, not something a user can assume from a generic “retry” button.

Retries also have costs and limits. A destination execution may require another fee, and a failed call may continue to fail if its cause has not changed. Read the failure details, confirm the destination address and action, and use the app’s documented retry control. Never share a recovery phrase or sign an unrelated transaction presented as a way to release the message.

The practical rule is to preserve the original message and act only on its recorded status. Watch for a destination transaction hash, a change from pending to executed, and any fee or retry limit shown by the protocol. Those signals tell you whether to wait, retry the same message, or seek recovery guidance.