Four Checks That Make Cross-Chain Retries Idempotent

Idempotent cross-chain retries use one stable message identity and destination state checks so a repeated delivery cannot repeat its effect. The source chain emits a message; a verifier or bridge authenticates it; a relayer or executor submits it on the destination; then the receiving contract changes state. Delivery can fail before execution, or execution can fail after verification. A retry should repeat the attempt, not create a second transfer or instruction.

This distinction matters in an omnichain application, where a single user action may pass through several chains and contracts. The linked omnichain explainer discusses the broader design choices after a stalled transfer. Here the practical question is narrower: what must the receiving application check before it acts again?

What makes a cross-chain retry safe?

A retry is safe when the destination can recognize the same authorized instruction and know whether its effect has already happened. A new transaction hash does not necessarily mean a new message: a relayer can resubmit the same payload in another transaction. The application therefore needs a message ID derived from stable fields, such as the source chain, source sender, channel nonce or sequence, and payload hash. The exact fields depend on the messaging protocol.

Think of the ID as a parcel’s tracking number. A second delivery attempt can use a different vehicle, but it still refers to the same parcel. If the application keys its record only to the destination transaction hash, each retry can look new. If it keys only to a nonce that can repeat across senders or chains, unrelated messages can collide. The ID must identify one instruction in its full sending context.

Which four checks should the receiver make?

The receiver should validate the identity and authorization first, then guard the effect with durable state. These four checks cover the main failure points:

• Bind the ID to the full message. Confirm the source chain, approved sender, destination, nonce or sequence, and payload. Do not let a caller reuse a valid ID with altered instructions.
• Check whether the ID has been handled. If it is already complete, return safely without repeating the effect. If it is pending or failed, follow the contract’s defined retry path.
• Record completion with the effect. On an EVM destination, update the processed record and perform the token transfer or state change in the same transaction. If execution reverts, both changes revert; if it succeeds, a retry sees the completed record.
• Track each stage of a multi-step action. A message that triggers a later call, swap, or outbound message needs separate stage identifiers or a clear state machine. Completing the first stage must not falsely mark every later stage complete.

What if a workflow only partly succeeds?

Split workflows need explicit states because a cross-chain operation is not one atomic transaction across every chain. For example, a destination contract may accept a message and record funds before a separate contract call fails. Retrying the entire instruction without stage tracking could credit the funds again; marking the whole operation complete could strand the unfinished call.

Store which step succeeded and give each step its own stable identity. A retry can then resume at the first incomplete step. Make state transitions narrow and check them before external calls, so reentrancy or concurrent submissions cannot pass the same guard twice. Where a later step cannot be retried safely, provide a deliberate recovery or refund path rather than treating every failure as permission to replay the whole action.

The useful rule is simple: retries should be cheap and repeatable, while effects should be unique. For most applications, the best starting point is a stable message ID plus an atomic processed-state guard on the destination. Add per-stage tracking when the operation continues beyond that transaction. That design lets operators retry delivery without asking users to submit a second instruction.