Bridge

Overview

A bridge connects systems that do not share one native state machine. It observes, verifies, or receives proof of an event on the source network, then unlocks assets, mints a representation, supplies liquidity, or calls a contract on the destination network. Bridge designs vary widely. Some depend on custodians, guardians, external validators, optimistic challenge windows, light clients, or zero-knowledge proofs. Each model introduces different assumptions around finality, key compromise, contract bugs, censorship, liquidity, and recovery.

Users should verify source and destination chains, official contracts, supported assets, fees, limits, and completion status. Payment services must track both legs and the message identifier. A source transaction marked successful does not establish that the destination transfer executed or that the received asset is canonical. Official status alone does not reduce the technical, governance, or liquidity dependencies involved. Risk exposure depends on the exact verification route. Review should identify every dependency, including signers, validators, proof verification, relayers, administrative keys, liquidity providers, and emergency limits.

Asset handling must bind the source asset, destination representation, contract addresses, decimals, mint or custody model, and redemption path. A ticker is not a unique asset identifier; the network, contract, and issuance model must be checked before crediting. Paused contracts, depleted liquidity, delayed proofs, or destination failure should enter review rather than being reported as a completed cross-chain payment. Production support needs separate status for every stage, timeout and replay protection, route-specific monitoring, and a documented recovery path. Implementation note: Every bridge adds verification and execution assumptions beyond the connected chains, so both transfer legs require monitoring.