How a cross chain bridge works, which trust model fits your protocol and which attack vectors to model before mainnet: a technical guide for DeFi and L1/L2 teams.
A cross chain bridge is a system that detects verified events on a source chain and executes corresponding actions on a destination chain. At its core, cross-chain bridge verification (also referred to simply as verification) solves the problem of proving an event occurred on a source chain to a destination chain. Verification can be used for asset transfer between two chains, as well as for cross-chain governance votes, for updating oracles, and for calling smart contracts on completely different VMs.
Cross chain bridge development has evolved from being a handy feature to become a core part of the blockchain infrastructure. And the attack surface area for such cross chain bridges grows with the volume of assets. Audits of such code are not sufficient to uncover vulnerabilities that were created at the architecture design stage. Missteps in the design of cross chain bridges can include choosing the wrong trust model, incorrect message passing and mistakes with regards to upgrades. The rest of this document outlines the various cross chain bridge architectures, trust models including multisig. Additionally, there are various security features that are related to cross chain bridge architectures.
Cross-chain asset transfer is supported at the protocol level by three different patterns. The risk and operational implications of the different patterns vary greatly.
A lock-mint bridge transfers the original assets to a custodian contract on the source chain, while a wrapped version of the asset is minted on the destination chain. The lock-mint bridge design is relatively easy to implement, but it suffers from a single point of failure as the value is locked in a single contract, which has been the target of several high-profile attacks.
A burn-mint bridge mints a canonical version of the token on the destination chain after the original token has been destroyed on the source chain. This type of bridge removes all of the risk associated with a custodian, but requires the token contract to be natively deployed on the destination chain, which typically requires coordinated governance across all instances of the token contract on that chain.
Liquidity pool bridges allow users to transfer assets via pre-funded liquidity pools on each chain. Due to the nature of directional flow of large volumes of assets, the LPs may experience occasional drains that require temporary boosts to incentives.
Cross-chain bridge security can ultimately be reduced to one simple question: Who confirms an event on the source chain actually happened? Understanding bridge trust models is essential for any team deciding which verification architecture best fits their risk tolerance and operational constraints.
Multisig based cross-chain messaging attests messages via the signature of an N-of-M signer set (e.g. multi-signature account) or MPC committee. Whilst quickly implementable, such cross-chain messaging systems can fall instantly if enough key holders fall prey to phishing/coercion for example.
An optimistic bridge usually allows any bonded relayer to post messages in a source chain and then afterwards opens a challenge window (e.g. 7 days for canonical optimistic-rollup withdrawals) during which a dispute can be opened for the message. Bridge-level challenge windows can vary a lot, and are usually set on a per-deployment basis.
ZK bridges verify consensus proofs on-chain and thus do not rely on a trusted committee anymore. The corresponding light client verification only uses chain headers. For now, this high security comes at the cost of expensive proofs. Therefore, projects often start with a simple multisig bridge and migrate to a ZK/ light client bridge later, once TVL and attack-surface value have matured.
As attack surfaces, bridge validator attacks very rarely embed into the same smart contract code that a bridge implementation relies on for normal operation. Implementing rate limits, as well as timelocked upgrades, combined with an MPC (Multi-Party Computation) based key management of separate validators (across individual operators) significantly reduces this surface area for attack.
Replay attacks happen when a message validly signed for Chain A is replayed on Chain B. By ensuring that all signed messages include the Chain ID for the destination Chain and by registering a unique nonce on the sending and receiving contracts, this attack vector can be fully closed. Such a dedicated audit of the complete message lifecycle (as opposed to a general review of the contract) would need to be performed before mainnet deployment.
The finality assumption failures can similarly cause a lot of harm: A bridge which waits 12 blocks to accept the state on the Ethereum main chain can accept to be rolled back on EVM-side-chains with larger reorg-depths. Independent monitoring of reorg-depths on the source-chain for a bridge, paired with a pause-function for the minting on the destination-chain before it actually happens, is the sufficient control.
The off-chain infrastructure determines whether messages actually get sent across the bridge or if they get stuck. The contracts take care of verification, the relayers and the monitoring take care of making sure the bridge is live.
A bridge relayer is responsible for watching source-chain events (e.g. new deposits) collecting required attestations and forwarding a proof to the corresponding destination smart contract(s). Off-chain this is a latency/failure-prone step where one relayer going down will block all pending withdrawals until it comes back online.
Relayer redundancy requires independent relayers that can automatically fail over to each other. In the permissionless case, relaying can be opened up to everyone, while still increasing censorship resistance. The destination contracts then enforce strictly increasing nonces and chain-IDs to avoid replaying old messages.
This decision affects the scope of audit, the operational overhead and the long-term fee exposure on every single chain that a protocol is targeting.
Off-the-shelf messaging layers are usually suitable for basic token transfer functions and simple cross-chain calls on well-established EVM chains. This allows for a rapid time-to-mainnet for standard token models that can be represented as a wrapped version (e.g. wETH), with corresponding finality settings.
Custom bridge contracts are typically built for such scenarios as canonical burn-mint control, finality that differs from that provided by a generic cross-chain layer, and other messaging volumes that after factoring for building and auditing a single set of custom contract code make for cheaper per-message fees than would be charged by off-the-shelf messaging layer providers.
The scope comprises the smart contracts per VM, the off-chain relayers, local multi-chain test environments for individual chains as well as independent audits, bug bounties, monitoring and timelocked upgrade processes for all governance levels. For implementation support, refer to smart contract development services.
On the bridge incident response and upgrade governance front, these should be specified prior to mainnet launch and implemented such that time-locked multisig with a minimum 48-72 hour window and community voting (e.g. via token holding) is used to govern upgrades to contracts on this layer. See cross-chain DEX aggregator guide for related reading on this front, and how guarantees on latency for a given dApp end up constraining the routing logic on DEX aggregation build out on this layer.
Models can be ranked by their trust minimization from most trust minimizing to least trust minimizing: zero-knowledge proof-based bridges, optimistic bridges, and trusted multisig bridges. The choice between these options ultimately depends on several factors including latency, budget, and most importantly assets that will be secured by the bridge.
Attackers have targeted three main attack surface areas of blockchain bridge implementations: 1) faulty signature verification code, 2) stolen or compromised validator/ relayer secret keys, and 3) bugs in the minting/ releasing smart contracts themselves. However, implementing a liquidity pool that is subject to price manipulation as well as attacks via so-called “flash loans” can further introduce substantial risk. Implementing formal verification on message handling as well as very strict access controls to sensitive functions can help mitigate these attack surfaces.
