Handling a Chain Reorg During a Bridge Transfer

Handle a bridge reorg by checking the source transaction against the canonical chain, then reconciling any destination action against the bridge’s message state. A transaction seen in a block is not necessarily settled: a reorg can remove that block and its deposit event, leaving a relayer with a stale observation. The right response depends on whether the bridge has acted on the event and what finality rule its contracts enforce.

Bridges typically observe a source-chain event, construct or relay a message, and trigger an action on the destination chain. That action might release locked assets or mint a representation; the exact path depends on the bridge design. For a route-level account of costs and path selection, the bungee bridge article covers the detail this overview only touches. In a reorg, the key question is whether the event the bridge acted on still belongs to the source chain’s canonical history.

What changes when the source chain reorganizes?

A source-chain reorg replaces one chain tip with another, which can orphan blocks that were previously observed. Transactions in those blocks may disappear from the canonical history, return to the mempool, or be included again in a later block. A bridge watcher that saw a deposit in an orphaned block must treat that observation as provisional until it checks the canonical chain again.

Confirmations reduce the chance that a block will be displaced, but a confirmation count is not the same as protocol finality. Some chains expose a consensus-defined finalized checkpoint; others use a bridge-specific confirmation threshold as a practical risk limit. A bridge’s contract or verifier may accept a message under one rule while its relayer waits longer before submitting it. Operators should identify which rule controls contract acceptance and which controls their own monitoring.

When a transaction is re-included, verify the new canonical receipt and event rather than assuming the old observation remains valid. The transaction hash can stay the same while its block placement changes. The bridge’s message identifier may depend on event fields, transaction data, or other protocol-specific inputs, so confirm the identifier using the bridge’s own rules. A re-inclusion is not automatically a duplicate transfer, but replay protection and message state must be checked before any retry.

What should an operator check before retrying?

Before retrying, establish whether the original source event remains canonical and whether the destination has consumed its corresponding message. A retry based only on a missing interface update can submit a duplicate or conflicting action. Check the source receipt, the bridge’s indexed event, the message status, and the destination transaction or contract state.

• Confirm that the source transaction has a canonical receipt and that the expected deposit event appears in it.
• Compare the receipt’s block hash and event data with the bridge indexer or relayer record; investigate mismatches before resubmission.
• Check whether the destination message is pending, executed, or rejected under the bridge’s contract rules.
• Record the old and replacement block references so monitoring can distinguish an orphaned observation from a new canonical inclusion.

If the source event is absent from the canonical chain and the destination has not executed the message, do not relay the orphaned event. Wait for a valid re-inclusion or confirm that the source transaction was dropped. If it was replaced, track the replacement transaction and verify that it emits the expected event. A user interface may lag behind the chain, so use the relevant chain data and bridge state as the decision basis.

What if the destination already acted?

If the destination contract executed a message whose source event was later orphaned, the destination action does not automatically roll back. The chains have separate consensus histories, and a source reorg does not reverse a destination transaction. The result may be an unbacked representation or an inconsistent accounting state, depending on what the bridge released or minted.

At that point, stop automatic retries and follow the bridge’s incident procedure. The protocol may support pausing message execution, invalidating a message, or applying a compensating transaction, but those controls are design-specific and may require an authorized operator or governance action. A destination transaction that succeeded should be treated as executed unless the destination chain itself reorgs or the bridge’s own contracts provide a defined recovery path.

For most operators, the better default is to gate relay on the bridge’s documented source-finality rule and to reconcile source and destination state before replay. This adds latency, especially where the bridge uses a conservative confirmation threshold, but it narrows the window in which a relayer can act on an orphaned event. The final check is simple: confirm the source event is canonical, confirm the bridge message is valid and unconsumed, then submit or retry according to the protocol’s state machine.