A relay bridge waits for source-chain finality before releasing the matching asset or message when its security policy requires the source event to be irreversible under that chain’s consensus. For frequent transfers, the key decision is how much reorganisation risk you can accept in exchange for faster settlement.
A confirmation threshold buys speed by accepting reorganisation risk
A confirmation threshold counts blocks or confirmations after the source transaction, then lets relayer nodes act before the chain has declared the event final. It is quick and simple to monitor, but “12 confirmations” is a policy setting, not a universal guarantee: the risk depends on the source chain’s consensus, block production, attacker economics and the value being moved.
Before finality, a reorganisation can remove the deposit after the destination contract has already released funds. The bridge then has a claim on an event that no longer exists. A relay bridge’s security model tells you who bears that gap and what evidence they require; check it before treating a fast credit as settled. Raising the threshold reduces ordinary reorg exposure, but cannot turn probabilistic confirmation into deterministic finality.
This option fits low-value transfers where speed matters and the bridge explicitly caps exposure or can absorb losses. It is a poor fit for large transfers if the operator’s threshold is undocumented, or if the source chain is congested and competing forks are more plausible.
Protocol finality waits for the chain’s own consensus threshold
Protocol finality waits until the source chain’s consensus rules mark the block final, rather than stopping at a chosen confirmation count. On Ethereum proof of stake, validators representing at least two-thirds of the stake must attest to the relevant checkpoints; under normal operation, finality takes around 13–15 minutes. A block appearing in a wallet or explorer is therefore not the same as a finalized block.
End to end, the user submits a deposit, the source contract emits an event, and the bridge’s observer tracks that event until it reaches the configured finality state. The relayer then submits the event data or proof to the destination contract, which checks the bridge’s authorization and replay protections before executing the corresponding mint, release or message. Finality does not remove destination gas or contract execution time; it gates when that work is safe to start.
This policy suits transfers where the cost of an orphaned deposit outweighs a few minutes of waiting. It can also stop progress during a source-chain liveness failure: Ethereum may continue producing blocks while failing to finalize if enough validator weight is offline or withholding votes. A bridge that requires finality should pause, not silently downgrade to a smaller confirmation count.
Challenge windows add a separate, much longer wait
Some systems use an optimistic dispute period after a state assertion, rather than relying only on source-chain finality. For example, standard Arbitrum One withdrawals to Ethereum have a seven-day challenge period before users can claim on mainnet. That window gives challengers time to dispute an invalid assertion; it is not a seven-day source-chain confirmation setting.
This path fits users who need the security assumptions of an optimistic rollup’s dispute mechanism and can plan around delayed withdrawals. It does not fit time-sensitive return flows. If speed is essential, a liquidity provider may front the destination funds for a fee, then recover them after the canonical withdrawal clears. You trade an extra cost and provider risk for access to capital sooner.
Choose the wait by the finality state you can verify
For a routine transfer, check the source transaction’s block, the bridge’s required state, and whether the destination action is merely pending or already executable. Compare the bridge’s displayed estimate with the source chain’s actual finality behaviour; congestion, missed blocks or a finality stall can make a typical estimate misleading. Keep enough destination gas for a separate claim if the route requires one.
Before sending a large amount, check whether the bridge’s threshold is fixed or value-sensitive, what happens if the source transaction is reorganised, and whether a fast path uses pooled liquidity. The direct route usually saves a fee but ties up your funds during the wait; a liquidity route may save time while charging for capital and adding a provider dependency. The useful comparison is total cost and settlement guarantee, not the quoted arrival time alone.
Ask yourself: if this transfer takes the full source-chain finality time—or pauses because finality stalls—does the saved fee still matter more than getting the funds sooner?