A destination-chain reorganization can erase a bridge credit while the source transfer remains. This happens when the destination network replaces recent blocks with a different version of its history, removing the block that recorded the incoming transfer.
A how a relay bridge moves funds explanation follows the message from one chain to another; this article focuses on what can happen after the destination chain first records it. The key distinction is that a transaction can appear successful before the block containing it is secure enough for the bridge or its user to rely on.
What does a destination-chain reorganization undo?
A reorganization, often shortened to “reorg,” happens when a blockchain switches to a different branch of recent blocks. Transactions in discarded blocks are removed from the accepted history; they may be tried again, but their earlier effects no longer count. Ethereum.org’s glossary describes a reorg as a switch to a different canonical chain.
For a bridge transfer, imagine you send tokens on a source chain and the bridge locks them in a smart contract. A relayer node sees that event and submits a corresponding instruction on the destination chain, where a contract releases or creates tokens for you. If the destination block containing that credit is later discarded, the destination contract state rolls back too.
The source and destination chains keep separate records. Reversing the destination credit does not automatically unlock the tokens on the source chain, because the source contract has no built-in knowledge that the other chain’s history changed. You can therefore see a completed source transaction alongside a missing or pending destination transfer.
How can the transfer be reversed after it looks successful?
“Included” means a transaction appears in a block; “finalized” means the network’s consensus rules treat that block as settled. The bridge may act on a source event once it has enough confirmations, but confirmations reduce reorg risk rather than removing it in every network. The exact threshold and meaning of finality depend on the chain and the bridge’s rules.
Suppose a bridge sees a deposit, then credits you on the destination chain while that chain’s block is still recent. A competing branch becomes the accepted one, and the credit block is dropped. The relayer’s earlier report of success was accurate for the branch it saw, but it is no longer accurate for the chain’s current history.
Any later transactions that depended on that credit can also be affected. If you traded the bridged tokens in a block that is discarded along with the credit, that trade is discarded too. If the trade was recorded in a block that remains canonical but the credited tokens are absent, it may fail when retried because your balance is no longer sufficient.
Ethereum.org explains that proof-of-stake finality makes reverting finalized blocks require a major consensus failure. Solana’s transaction guidance distinguishes “confirmed” from “finalized” because a confirmed transaction can still belong to a dropped fork. Those terms are useful examples, not interchangeable labels: check the commitment level and finality rule for the particular chain.
What affects the wait and the cost?
Waiting longer for destination finality lowers the chance that a bridge transfer will be reversed, but adds time before you can safely use the received tokens. There is no universal confirmation count: the bridge chooses a threshold based on its security model, the destination chain’s consensus, and the value or risk it is willing to accept.
For a simple timing estimate, say a network produces a block every two seconds and a bridge waits for 20 confirmations. That is roughly 40 seconds for those blocks, before adding relayer polling, network congestion, and the time for the destination transaction to be included. Actual wait times can be longer, and a bridge that waits for stronger finality may take much longer still.
A reorg does not have one standard fee outcome. You may have paid the source transaction fee already, while a relayer or bridge operator may need to pay again to retry a destination transaction. Whether a user pays a retry fee, receives a refund, or needs to take action depends on the bridge’s terms and its recovery process.
What should you check if the destination credit disappears?
Start with the transfer’s status in the bridge’s tracker, then compare the transaction records on both chains. A source deposit that remains confirmed with a destination transaction missing or marked reverted points to a different issue than a source deposit that itself was removed by a reorg.
- Confirm that the source transaction is still in the accepted chain history.
- Check whether the destination transaction was included, reverted, or dropped with its block.
- Look for a bridge status such as pending, retrying, or awaiting finality.
- Check whether the bridge says it retries automatically or requires a manual claim.
Do not send the same transfer again just because the destination balance is temporarily missing; the original message may still be retrying, and duplicate submissions can create confusion or extra fees. Follow the bridge’s recovery instructions and use its official tracker to check whether the original transfer has been completed or can be claimed again.
A destination reorg can remove the receiving side of a bridge transfer without undoing its source-side lock or payment. When using a relay bridge, treat a visible destination credit as provisional until the bridge’s required finality threshold is met, and check both chains if that credit later disappears.
Top comments (0)