When a Bridge’s Source Chain Reorganizes

If a bridge acts on a deposit and the source chain later reorganizes, the destination chain may show a transfer that no longer has a valid source transaction. A reorganization, or “reorg,” happens when a chain replaces recent blocks with a different version of its history. The risk is greatest before the deposit is final, meaning the network treats its block as settled.

Bridges watch for an event such as a token lock or a message from a contract. They may ask validators to attest to it, then let a destination contract mint or release assets. A fuller guide to the portal bridge covers the transfer flow; the key issue here is what happens if that source event disappears.

What does a source-chain reorg change?

A reorg can remove the block containing the deposit from the chain’s accepted history. The transaction may be dropped, or it may be included again in a later block. Until the source chain reaches its chosen level of finality, a bridge can act on an event that is still at risk of being replaced.

That creates a timing mismatch. The destination chain may already have processed the bridge message, while the source chain no longer records the deposit that supported it. The destination transaction remains part of its own chain; a source reorg does not automatically erase it.

What happens to the bridged funds?

The outcome depends on the bridge’s design and how far the transfer progressed. If no destination action occurred, the bridge may wait for the source transaction to appear again or reject the message. If assets were already minted or unlocked, the bridge may need to pause transfers, investigate the event, and reconcile its records. There is no universal undo button across two separate chains.

A re-included deposit can also be recorded at a different place in the source chain’s history. Some messaging systems use event order or sequence numbers, so a reorg can complicate how watchers identify the message. The bridge’s rules determine whether it recognizes the re-included event as the same transfer, a new one, or an invalid message.

How can users reduce the risk?

For most users, the better choice is to wait for the bridge’s stated confirmation or finality requirement before assuming a transfer is settled. Faster processing can reduce wait time, but it gives the source chain less time to settle its history. Bridges and applications choose their own balance between speed and reorg resistance.

• Check whether the bridge marks the transfer as pending, completed, or failed.
• Look up the source transaction and confirm it remains in the accepted chain history.
• Do not submit the transfer again while the first attempt is unresolved; it may still be processed.

A source reorg does not always cause a loss, and deeper finality makes this kind of reversal less likely. But once a destination chain has acted, the bridge must handle any mismatch between the two histories. Treat a transfer as complete only when the bridge reports completion and the destination transaction is visible.