How Cross-Chain Bridges Stop a Message Being Used Twice

A bridge prevents replay by binding each message to one route and marking it used on the destination chain. First, a source contract emits a message when an action occurs, such as locking tokens. A verifier checks that the message came from an approved source and that its proof is valid. Then the destination contract checks the message’s route and whether it has already been processed before it releases or mints assets.

A signature proves that an authorized signer approved a message; it does not prove that the message is new. The message therefore needs a unique identity, usually derived from fields such as the source chain, source contract, destination chain, destination contract and a sequence number. Readers comparing routes can find more detail in this guide to Manta bridge routes for a wallet. Those fields work like an address on a parcel: they say where it came from and where it can be delivered, but the receiver still needs to record that delivery.

What does replay protection check?

Replay protection checks both the message’s domain and its prior use. Domain separation means a message approved for one chain and bridge contract cannot be accepted as a valid instruction on another route. A destination contract should verify the source chain and contract against an allowlist, confirm its own chain and address are the intended destination, and validate the message identifier before executing the action.

The contract then stores a consumed marker for that identifier. A second submission finds the marker and fails. Some bridges track individual message hashes; others use sequence numbers scoped to a particular source and destination. The important detail is that the sequence belongs to the full route. A bare number such as “17” is not unique if separate senders or routes can each have a message 17.

Where should a bridge record that a message was used?

The destination should mark a message as consumed as part of the same transaction that performs its action. The check, state update and token transfer or contract call need to behave as one unit. Otherwise, two submissions could both pass the check before either records the message, or a failed action could leave the bridge in a state that permits an unsafe retry.

In a typical token transfer, the source locks or burns tokens and emits a message. After the destination verifies it, the destination releases or mints the corresponding tokens and records the message as consumed. This accounting only works if the destination action cannot happen twice. If the receiver calls another contract, that contract’s effects must also be protected from duplicate execution.

What should bridge users and builders check?

For builders, replay defense is a set of linked checks, not a single signature test. Review the bridge’s code and message format for:

• A unique message ID that includes the full source and destination route.
• Verification of the approved source chain and contract, plus the intended destination.
• A consumed-message check that is updated atomically with execution.
• Clear handling of retries, failed calls and source-chain reorganizations.

Waiting for source-chain finality reduces the chance that a valid-looking event is later removed by a reorganization. Ordered sequence tracking can simplify duplicate detection, but a missing message may block later ones. Per-message tracking allows more flexible delivery, at the cost of storing more state. For most bridges, explicit route binding and destination-side consumption are the core protections; the next thing to watch is how the bridge handles finality and retries without reopening a message for reuse.