Bridge Finality

Overview

Context and purpose

The source event must reach sufficient chain finality, the bridge must accept or prove it under its security model, and the destination execution must become canonical on the receiving network. Optimistic bridges may add a challenge window, validator bridges may require a signature threshold, and light-client bridges may follow finalized headers. Fast liquidity can pay a user before underlying settlement, shifting delay and reorganization risk to a liquidity provider rather than eliminating it. Payment systems should define finality for each route and direction, including source, bridge, and destination states. They must not credit high-value transfers solely from a source event or signed message. Records should preserve proof, message, and destination transaction identifiers for later audit and dispute handling. Asset recognition must use chain-specific identifiers because the same ticker can represent unrelated or differently backed tokens.

How it works

Bridge finality concerns when a cross-chain transfer is secure under source-chain, bridge-verification and destination-chain rules. Different routes may have challenge windows, validator signatures or light-client proofs.

Practical checks and failure points

Track three statuses separately, retain proof IDs and define route-specific safe thresholds.

Related concepts

Bridge Failure Scenario · Cross-Chain Stablecoin

Further reading

• ethereum.org official reference