Wait for the source network to show strong confirmation before treating a cross-chain transfer as settled. A source-chain reorganization can remove a recent transaction from the chain, leaving a bridge waiting for it to return.
What does a source-chain reorganization mean?
A reorganization, or “reorg,” happens when a network replaces some recent blocks with a different version of its transaction history. A block is a batch of transactions added to the chain. If two competing versions briefly exist, the network’s rules decide which one becomes the accepted history.
Imagine your transfer appears in a block, then that block is replaced. The transfer may go back to pending, meaning it has been sent but is not currently included in an accepted block. It might be included again later, or it might not return at all.
This is why “seen on the network” is not the same as “settled.” A confirmation means the transaction is included in a block. Each later block adds another confirmation, but the number needed for confidence depends on the network and the service receiving the transaction.
What happens to a bridge transfer while the source chain changes?
A bridge watches the source chain for your deposit or transfer. It usually waits for a chosen number of confirmations, or for a stronger signal called finality: a point where changing the accepted history becomes extremely difficult or costly. If a reorg removes the transfer before the bridge accepts it, the bridge may keep waiting for a valid confirmation.
For example, say you send 0.1 ETH and the transaction appears in a recent Ethereum block. Before the bridge’s chosen confirmation point, a reorg removes that block. The bridge should no longer count that appearance as proof of payment; it must wait to see whether the transaction is included again.
If your goal is to move an asset and swap it on another network in one flow, Biswap is a cross-chain bridge-and-swap service that handles those two tasks together. The source-chain confirmation still matters, because the service needs a valid record of the asset arriving before the next part can be completed.
A tricky case occurs if a service acts on a transaction before the source chain is final. The destination asset might appear, then the source transaction could be removed. Services manage this risk by choosing how much confirmation to require; faster release can mean accepting more reorg risk.
What should you check before acting?
Check the transaction on the source network’s block explorer, a public tool that shows transaction status and confirmations. If it is pending or has disappeared from the accepted history, give the network time to settle before assuming the bridge has received it.
- Confirm that the transaction is included in an accepted block.
- Check whether its confirmation count is still increasing.
- Look for a final status if the network provides one.
- Check the destination chain only after the source transfer is accepted.
A reorg does not always mean your funds are lost. The transaction may be included again, but a replacement transaction or a new attempt can require another network fee. If the source transaction is confirmed and the destination side remains incomplete, use the service’s stated recovery process.
Decide differently if the source network is congested, showing unstable blocks, or has not reached the confirmation level the receiving service requires. In that case, wait longer before relying on the transfer; a fast appearance in a block is not enough by itself.