Source-chain confirmations set a bridge’s earliest safe release
Bridge timing follows source-chain finality and the bridge’s verification threshold; a mined deposit alone does not prove destination execution.
The Blockchain Brief Desk5 min read
Time a bridge transfer by the source chain’s finality rule and the bridge’s own verification threshold, not by a universal confirmation count. A source transaction can appear in a block while that block remains vulnerable to reorganization. The bridge must observe the deposit, decide that its source-chain evidence is acceptable, then pass the message or proof through its verification and destination execution stages. Each stage has its own status.
“Confirmations” can mean successive blocks after a transaction, a protocol’s finalized-block signal, or an application-specific threshold. Those are different guarantees. For the transaction path from deposit to delivery, see this account of how acrossbridge handles first transfers. The general timing question is narrower: when is the source event safe enough for this bridge to act on it?
What does a source-chain confirmation establish?
A source-chain confirmation establishes that a transaction has been included in a block that the chain’s current consensus view accepts. It does not, by itself, establish that the block is irreversible. Bridge contracts commonly emit a deposit or message event when the user’s transaction executes. Offchain observers or verification components detect that event, but they must still apply the bridge’s rule for accepting the block.
On chains with probabilistic finality, such as proof-of-work systems, each successor block makes a reorganization that removes the deposit less likely, but does not create a protocol-level finalized state. A bridge can wait for a configured block depth: the number of blocks built after the transaction’s block. That is a risk threshold, not a proof of impossibility. Deeper thresholds lower reorg exposure and increase latency.
On chains with deterministic finality, the consensus protocol may identify finalized blocks directly. Ethereum uses Gasper, which combines Casper-FFG finality with the LMD-GHOST fork-choice rule. Casper-FFG finalizes checkpoint blocks through validator votes; a bridge or its observer can use the chain’s finalized status rather than treating every new block as an equal increment in confidence. A merely included or justified block is not the same state as a finalized one.
How should you choose the confirmation point?
Choose the bridge’s documented source-chain acceptance rule for the exact route, then wait until the deposit satisfies that rule. Do not substitute a familiar number from another chain or bridge. A bridge may rely on a finality tag where the source chain exposes one, or use block depth when it cannot use that signal. In the latter case, the threshold is an operational setting balancing reorganization risk against transfer delay.
For each route, identify the following before sending a high-value transfer:
- Source rule: Does the bridge wait for protocol finality, a finality tag, a block-depth threshold, or another verification condition?
- Evidence tracked: Is the bridge watching the transaction receipt and emitted event, or a message commitment that includes the event?
- Destination step: Does a relayer submit the accepted message, or must a user claim or execute it after source verification?
- Failure state: What does the bridge report if the source transaction is reorganized, reverted, or never observed by its verification service?
The route’s weakest relevant assumption sets the practical wait. A fast source-chain inclusion does not make the destination action safe if the bridge waits for a later finality signal. Conversely, a bridge that accepts a transaction at a shallow block depth is choosing a faster but less conservative threshold. The choice belongs to the bridge’s security design; the user should not infer it from wallet status labels such as “confirmed” or “complete.”
When is a bridged transfer actually complete?
A transfer is complete when the bridge’s destination action has executed successfully, not merely when the source transaction is included or reaches its confirmation threshold. The source event authorizes or informs the cross-chain step. Depending on the bridge design, a verifier may attest to the event, a relayer may submit the resulting message, and a destination contract may release, mint, or account for the asset. A pending transfer can therefore be correctly waiting after the source chain has finished its part.
Check the source transaction’s status and block, then check the bridge’s own transfer record for whether it has accepted that event. Finally, confirm that the destination transaction succeeded and that the expected asset or state change appears at the intended address. If the source transaction is reverted, there is no valid deposit for a bridge to process. If it is reorganized out before the bridge’s acceptance rule is met, an observer may discard the event and resume tracking the canonical chain. A delayed relay or destination failure can leave a valid source deposit pending without meaning the source confirmation count was wrong.
For rollups, “source finality” can itself have layers. A sequencer may include an L2 transaction quickly, while the rollup later posts its data or commitment to a settlement chain. An optimistic rollup may also have a challenge period before the strongest settlement guarantee applies. Bridges can act on an earlier, weaker signal to reduce latency, but that shifts the trust and risk assumptions. Read the route’s definition of accepted finality rather than treating an L2 receipt as equivalent to final settlement.
The useful timing rule is simple: wait for the bridge’s stated source-chain acceptance condition, then verify destination execution separately. A confirmation count only has meaning alongside the chain’s consensus model and the bridge component that consumes it. Where the bridge uses block depth, the residual reorganization risk remains; where it waits for protocol finality, delays in reaching finality can hold up the transfer. The exact threshold, observer behavior, and recovery path are implementation-specific and should be treated as unconfirmed until the bridge documents them.