Why Bridge Routes Wait for Source Confirmations

A bridge route waits for source confirmations because its destination payout depends on a source-chain event that could still be reverted. The wait gives the bridge’s verification and delivery path time to decide that the deposit is stable enough to act on. It does not mean every bridge uses the same confirmation count or finality rule.

The route begins when a source transaction calls a bridge contract, locks or burns an asset, or publishes a message describing the requested action. A watcher, relayer, validator or oracle observes that event and supplies evidence to the destination. The receiving contract checks that evidence before releasing or minting assets. Readers looking at how route design affects transfer speed can use acrossbridge for the broader set of checks. The key point here is that the source event must remain canonical long enough for the bridge’s proof process to complete.

What do source confirmations establish?

Source confirmations establish how far the chain has progressed beyond the block containing the deposit. They reduce the chance that the block will be removed by a reorganization, but the meaning of “enough” depends on the chain’s consensus and the bridge’s policy.

On a chain with probabilistic finality, later blocks make a reorganization progressively less likely without making it impossible at a specific early point. A bridge can require a chosen depth before its watcher treats an event as eligible. On a chain with a protocol-level finality signal, the bridge can instead wait for that signal, if its verifier supports it. These are different rules: a block count is an operational threshold, while finalized status is a claim about the chain’s consensus state.

Wormhole makes this choice explicit in its message flow. A source application calls the Wormhole Core Contract, which publishes a message in the chain’s logs with a consistency level. Guardians observe the message and wait for the corresponding level of finality before signing an attestation called a VAA. The destination contract verifies the VAA before acting on the message. Wormhole’s `instant`, `safe` and `finalized` options expose a latency and reorganization-risk trade-off; the selected level affects how long Guardians wait. The names do not imply one universal number of blocks across all supported chains, because chains have different finality behavior.

Why can a route stay pending after the wallet says confirmed?

A wallet’s “confirmed” status usually reports that a transaction has been included in a block. It does not necessarily mean that the bridge has reached its own source-chain threshold or received all required attestations.

The status path may include several separate steps. The source transaction must execute successfully and emit the expected event. A watcher must detect and index it. The required confirmations or finality condition must accrue. A validator set or verifier must produce acceptable evidence, and a relayer must submit that evidence or the resulting instruction to the destination chain. Congestion or an unavailable relayer can extend the wait even after source finality has been reached.

Some routes use a liquidity provider or relayer to pay the recipient before the source event reaches the settlement stage. That can make the user-facing transfer fast, but it changes who carries the interim risk. The relayer advances destination liquidity against a source deposit and later seeks repayment through the route’s settlement mechanism. Other routes wait for stronger source evidence before releasing funds. A fast displayed fill therefore does not, by itself, tell you whether the source transaction is already final.

• Inclusion means the source transaction appears in a block.
• Confirmation depth means additional blocks have been built after that block.
• Finality means the chain’s rules treat the block as irreversible under the stated assumptions.
• Destination execution means the receiving contract has accepted the bridge’s proof or instruction and performed the requested action.

What happens if the source transaction is reorganized?

If the source block is reorganized out before the bridge’s proof is accepted, the deposit event may no longer exist in the canonical chain history. A well-designed route delays or rejects destination execution when its verification rule says the source event is not sufficiently stable. If destination funds were already released on weaker evidence, the bridge can face an imbalance: assets were paid out against a source action that was later reversed.

That is why confirmation thresholds are a security parameter rather than a cosmetic delay. Lower thresholds reduce latency but increase exposure to reorganization risk. Higher thresholds reduce that exposure while keeping deposits pending longer. The route operator has to set the threshold in light of the source chain’s behavior, the value at risk, the bridge’s verifier design and whether a relayer is advancing funds.

For a user, compare the route’s stated completion stages rather than treating a wallet confirmation as proof that the transfer is settled. Check whether “filled” means a relayer has paid on the destination, whether a separate settlement step remains, and what condition triggers a refund if delivery fails. The practical trade-off is simple: a route can deliver earlier by accepting more interim risk, or wait for stronger evidence before the destination contract acts. The confirmation wait is the bridge’s chosen boundary between those two outcomes.