Skip to content
Financial Context Wiki

Cross-chain message replay protection

Cross-chain replay protection binds an authenticated source message to one protocol version and destination domain, then permits retries without allowing more than one successful economic effect.

Updated

For educational purposes only; not investment advice. A replay-control defect can duplicate minting, unlocking or arbitrary destination calls, and recovery may be impossible.

Direct answer

Cross-chain message replay protection ensures that one authenticated source message can produce no more than one successful economic effect in its intended destination domain. A relayer may deliver the same proof repeatedly, and a failed attempt may be retryable, but a message already completed must not mint, unlock or call the receiver again.

Authenticity, finality and replay protection are separate checks. A valid signature, validator attestation or storage proof can authenticate data without proving that the source event is final, that the intended destination and receiver were bound, or that the destination has not already processed it. Likewise, an authorized relayer is only a delivery path; relayer identity must not replace message authentication.

There is no universal cross-chain messageId. The exact protocol specification controls serialization and identity. A robust envelope commonly binds protocol and version, source domain and messenger or emitter, source sender, nonce or source transaction/log identity, destination domain and receiver, value, payload, and any expiry. Wormhole, CCTP, Optimism and ERC-5164 use different fields and state machines, so their identifiers are not interchangeable.

How it works

A source action emits or stores a message. After the required confirmation or finality policy, validators, guardians or a proof system authenticate it. On the destination, the verifier checks the relevant root or signature set, protocol version, trusted remote sender, destination, receiver, payload and time bounds. The receiver derives the protocol-defined identity and consults persistent processed state before producing an external effect.

Delivery is often at least once, while the desired business effect is effectively once. A useful state machine distinguishes never attempted, processing, failed or retryable, and successful or consumed. A failed destination call is not automatically a replay attack. ERC-5164, for example, requires a message to execute successfully at most once while permitting another attempt after failure. Product-specific retry rules, gas handling and value accounting still control.

The replay flag or processing guard should be established before an untrusted external call, with reentrancy controlled. If the whole transaction reverts, that state change normally reverts too, leaving a defined retry path; if a protocol intentionally catches a downstream failure, it must record a distinct failed state without accidentally retaining partial value or effects. The receiver should also be idempotent where downstream systems can be called through another path.

Nonce scope matters. A sequential nonce enforces order but can block later messages behind a missing one. An unordered nonce or bitmap permits independent delivery but requires exact word and bit computation. Batch designs must state whether the whole batch is atomic or whether each leaf has independent proof and processed state. Marking only a batch root as consumed after partial execution can either duplicate successful leaves or strand failed ones.

Source reorganization policy is part of replay safety. A signed observation made before sufficient finality can remain cryptographically valid even if the source event later becomes noncanonical. Upgrades are another boundary: proxy storage layout, processed mappings, version domains, old entry points, peer rotations and fork or chain-ID reuse must preserve or deliberately invalidate prior identities without reopening consumed messages.

Use this workflow:

  1. Pin the protocol, deployed version, source and destination domains, trusted messenger or emitter, sender, receiver, value, payload, nonce or event identity, and expiry semantics.
  2. Reproduce the specification’s canonical encoding and messageId test vector; reject ambiguous concatenation, omitted fields and assumptions borrowed from another bridge.
  3. Verify source inclusion and the required finality or confirmation policy, then verify the correct proof root, signature quorum, validator or guardian set, and version.
  4. Verify destination, receiver, cross-domain sender, value, payload and expiry independently; treat the submitting relayer as transport rather than authority.
  5. Read persistent message state and enter processing or consumed state before any untrusted external call, with reentrancy protection and transaction-revert behavior explicitly tested.
  6. Define successful, failed and retryable transitions, ordered or bitmap nonce behavior, batch atomicity and value accounting; prove that repeated delivery cannot repeat a successful leaf.
  7. Test upgrades, storage migration, disabled legacy entry points, peer rotation, forks and emergency recovery, then reconcile receipts, events, processed state and destination balances.

Examples

  • Destination-domain binding. Two instructions both carry nonce 42 and value 1,000, but one targets chain 10 and the other chain 8453. An identifier that omits the destination treats 2 messages as one collision candidate; a canonical encoding that binds the destination produces 2 distinct IDs. The actual hash function and domain representation must come from the protocol.
  • Unordered bitmap. For nonce 513, word = floor(513 / 256) = 2, bit = 513 mod 256 = 1, and mask = 1 << 1 = 2. The first success changes bitmap word 2 from 0 to 2. A duplicate finds 2 & 2 = 2 and is rejected, while nonce 512 uses bit 0 independently.
  • Retry is not a second effect. The same authenticated message is delivered 3 times. Destination calls using 110,000 and 125,000 gas fail and revert; the third uses 140,000 gas and succeeds once. Total gas is 110,000 + 125,000 + 140,000 = 375,000; at 20 gwei, that is 0.0075 ETH. Deliveries equal 3, but successful business effects equal 1.
  • Partial batch accounting. Four independently executable leaves carry 25 + 40 + 15 + 20 = 100 units. Leaves 0, 1 and 3 succeed for 25 + 40 + 20 = 85; leaf 2 fails and leaves 15 pending. Consuming only the batch root would strand the 15; retrying the whole batch without leaf state could repeat the 85. Use atomic rollback or per-leaf processed state as specified.

Risks

  • The identifier omits the destination chain or domain.
  • The identifier omits the source messenger or emitter.
  • Protocol or message version is absent from the domain.
  • A nonce namespace collides across senders or deployments.
  • Ambiguous packed encoding creates different-field collisions.
  • A fork or reused chain ID makes an old domain valid again.
  • A source event is accepted before sufficient finality and is reorganized out.
  • The wrong proof root, validator set or guardian set is accepted.
  • An old signature domain remains valid after an upgrade.
  • Proxy storage corruption resets or aliases processed-message state.
  • Migration omits consumed messages or leaves a legacy entry point active.
  • State is marked only after an external call, enabling reentrancy.
  • A failed call is marked successful and can never be retried.
  • A successful call is not persisted and repeats its economic effect.
  • A missing ordered nonce blocks all later messages.
  • Bitmap word, bit or invalidation arithmetic is wrong.
  • Batch-root state conflicts with per-leaf partial execution.
  • A retry repeats leaves that already succeeded.
  • Deadline, expiry or destination-clock units are misread.
  • Relayer allowlisting is mistaken for message authorization.

Common misconceptions

  • A nonce alone is globally unique. Its sender, protocol, deployment and source and destination domains determine its namespace.
  • Only an authorized relayer can prevent replay. Relayers provide delivery; destination verification and persistent consumed state enforce authority and replay control.
  • Every repeated delivery is an attack. At-least-once networks may retry a failed message; the invariant is no more than one successful effect.
  • A valid proof or signature proves finality and intent. It may omit the intended target, bind the wrong version or attest to a source state that later reorganizes.
  • A successful bridge transaction proves exactly-once completion. Verify receipt status, processed storage, receiver events and actual balances, including every batch leaf.

Sources

Navigation

Search the wiki...