A Failed Omnichain Message Needs a Diagnosis Before a Retry

Retry a failed omnichain message only after you know whether it failed before delivery or during destination execution. That distinction matters: in some systems, a verified message can be executed again without sending a new source transaction; in others, the app or bridge defines its own recovery path. Before retrying, check the source transaction, message status, destination transaction and any recorded error. A source transaction that reverted is different from a message that reached the destination but could not complete.

What does a failed message status mean?

A status is useful only when you know which stage it describes. Cross-chain systems typically involve a source transaction, message verification or relay, and destination execution. A delay at one stage can look like a failure in a wallet even when the message is still progressing. Check the transaction on both chains and use the protocol’s tracker, if available, to identify the last completed stage. For a broader explanation of how omnichain apps and assets work, see the separate guide; here, the focus is recovery.

If the source transaction reverted, the message may never have been created, so there may be nothing to retry on the destination. If verification or relay is still pending, another execution attempt may not help. If the destination call reverted after the message arrived, some protocols let someone submit that same message again. The available action depends on the protocol and application, not just the word “failed” in a tracker.

What should you check before retrying?

Read the destination error before submitting another transaction. A retry repeats execution; it does not automatically repair the condition that caused the first attempt to fail. A temporary shortage of execution gas may be addressable through the protocol’s retry process or a new execution option. A contract rejection, invalid parameter or application-level restriction may fail again until the underlying cause changes. Some messages also trigger follow-on calls, so check whether the failure occurred in the main delivery or in a later step.

• Confirm the source transaction succeeded and note its message identifier.
• Check whether the message is pending, verified, delivered, or failed at destination execution.
• Read the destination transaction’s error and determine whether the cause can change.
• Confirm the retry function and fee in the protocol’s own interface or contract flow.

Do not send a second source transaction just because destination execution failed. It may create a second message and duplicate an action if the first one later succeeds. Likewise, do not call a low-level retry function unless you can match the message identifier, destination and parameters to the failed attempt.

When is a retry better than sending again?

A protocol-supported retry is usually the cleaner option when the original message is verified and the destination app can safely execute it again. It preserves the original message’s identity and avoids asking the source contract to create another instruction. But retries are not universal: some systems store failed payloads, some expose a retry call, and others require application-specific recovery or do not permit replay. A new source transaction is appropriate only when the original never dispatched or the application explicitly requires a fresh instruction.

The trade-off is between preserving the original message and starting a new operation. Retrying can save a source-chain fee, but it can still cost destination gas and repeat application logic. Resending gives the app a new instruction, but risks duplicate intent or inconsistent state if the earlier message later completes. For most users, the better sequence is to verify the stage, fix any destination-side cause, then use the protocol’s documented retry path once.

What signals should you watch next?

Watch for a destination execution transaction, a status change from pending or failed to delivered, and any app-level balance or state update that confirms the intended action. If the retry reverts again, stop repeating it and inspect the new error; repeated submissions add cost without changing the cause. The key comparison is simple: a message that never left the source needs a different remedy from one that arrived but could not execute.