How Cross-Chain Bridges Work
Blockchains are isolated by design. Bitcoin cannot natively read the state of Ethereum, and Ethereum has no built-in awareness of Solana. Each chain maintains its own consensus, its own ledger, and its own execution environment. Cross-chain bridges exist to break this isolation, enabling assets and data to move between otherwise disconnected networks. They are among the most consequential and most dangerous pieces of infrastructure in the blockchain ecosystem, responsible for billions of dollars in value transfer and billions more in catastrophic losses.
The Fundamental Problem: Why Bridging Is Hard
Moving value between blockchains is not like sending an HTTP request between servers. When you transfer ETH from Ethereum to an Arbitrum rollup, or swap BTC for an Ethereum-based token, you are coordinating state changes across two systems that have no shared source of truth. Neither chain can verify the other's state natively. Neither chain trusts the other's validators. The bridge must somehow convince Chain B that something happened on Chain A, without Chain B being able to check Chain A directly.
This is fundamentally a messaging and verification problem. Every bridge design is an answer to the question: how do you prove that an event occurred on a source chain, in a way that the destination chain can verify?
Lock-and-Mint: The Dominant Model
The most common bridging mechanism is lock-and-mint. The process works in two steps: a user locks (deposits) their native asset into a smart contract on the source chain, and the bridge mints an equivalent synthetic (wrapped) asset on the destination chain. The wrapped token is a claim against the locked collateral. When the user wants to return, they burn the wrapped token on the destination chain, and the bridge unlocks the original asset on the source chain.
Wrapped Bitcoin (WBTC) is the most widely known example. Users deposit BTC with BitGo, a centralized custodian, and receive WBTC tokens on Ethereum. WBTC is a 1:1 backed ERC-20 token -- each WBTC in circulation corresponds to a real BTC held in BitGo's custody. At its peak, over 150,000 BTC (worth roughly $4 billion) were locked in the WBTC system.
The lock-and-mint model has a critical property: the locked assets on the source chain become a honeypot. Every dollar of wrapped tokens on the destination chain is backed by a dollar of real assets sitting in a smart contract (or custodian wallet) on the source chain. Compromise that contract, and you can steal every bridged dollar.
Burn-and-Mint: Native Multichain Tokens
An alternative is burn-and-mint, where the token is burned (destroyed) on the source chain and minted fresh on the destination chain. There is no pool of locked collateral. This requires the token issuer to deploy contracts on both chains that have the authority to burn and mint the canonical token.
Circle's Cross-Chain Transfer Protocol (CCTP) uses this model for USDC. When you bridge USDC from Ethereum to Avalanche via CCTP, the USDC is burned on Ethereum and newly minted on Avalanche. The total supply remains constant, and there is no wrapped variant -- it is native USDC on both chains. This eliminates the wrapped-token liquidity fragmentation problem but requires the token issuer to actively participate in the bridging process.
Trusted Bridges: Speed Through Centralization
The simplest bridges rely on a trusted third party or a small federation of known operators to attest that events occurred on the source chain. The trust model is straightforward: you trust the bridge operator not to lie, not to steal, and not to get hacked.
Centralized Custodians
WBTC's model is fully centralized. BitGo holds the Bitcoin, and you trust BitGo -- a regulated, insured custodian -- to honor redemptions. This works well for institutional use cases where counterparty risk is acceptable, but it reintroduces exactly the kind of trusted intermediary that decentralized systems were designed to eliminate.
Multisig Federations
Many bridges use a multisig scheme: a group of N validators must sign off on cross-chain messages, with a threshold of M signatures required (e.g., 5-of-8). Ronin Bridge, which served the Axie Infinity game, used a 5-of-9 multisig. Wormhole originally used a 13-of-19 guardian set. These are faster and simpler than trustless alternatives, but the security of the entire bridge reduces to the security of M private keys.
Trustless Bridges: Verification Without Trust
Trustless bridges attempt to verify cross-chain messages without relying on a trusted third party. They use cryptographic proofs and on-chain verification to achieve this. There are three primary approaches.
Light Client Verification
The gold standard for trustless bridging is running a light client of the source chain on the destination chain. A light client does not process every transaction -- it verifies block headers and uses Merkle proofs to confirm that specific transactions were included in finalized blocks. If Chain B runs a light client of Chain A, it can independently verify any event on Chain A by checking the proof against the validated header chain.
This is how the IBC protocol (Inter-Blockchain Communication, used in the Cosmos ecosystem) works. Each connected chain runs a light client of its counterpart. When a packet is sent from Cosmos Hub to Osmosis, a relayer submits the packet along with a Merkle proof and the relevant block header to Osmosis. Osmosis's IBC module verifies the proof against its local light client state for Cosmos Hub. No trusted third party is involved -- the verification is purely cryptographic.
The limitation is cost. Running a light client on-chain means verifying block headers and Merkle proofs inside smart contract execution, which consumes gas. For chains with expensive execution (like Ethereum), this can be prohibitively costly. Verifying a single Tendermint header on Ethereum might cost hundreds of thousands of gas, and headers arrive every few seconds.
Optimistic Verification
Optimistic bridges take a different approach: they assume messages are valid unless challenged. A relayer posts a cross-chain message to the destination chain, and there is a challenge period (typically 30 minutes to several hours) during which watchers can submit a fraud proof if the message is invalid. If no challenge is raised, the message is accepted.
Nomad was the most prominent optimistic bridge before its hack. The design mirrors optimistic rollups: you trust that at least one honest watcher is monitoring the system and will flag fraud. The security assumption is "1-of-N honesty" -- only one participant needs to be honest, compared to the "M-of-N honesty" assumption in multisig bridges.
The tradeoff is latency. Users must wait for the challenge period to expire before their bridged assets are available. This makes optimistic bridges unsuitable for time-sensitive transfers unless a fast-liquidity layer is added on top.
Zero-Knowledge Proof Verification
The most recent development is using zero-knowledge proofs to verify cross-chain state. Instead of running a full light client or waiting for a challenge period, a ZK bridge generates a succinct proof that a set of block headers is valid and that a specific transaction was included. The destination chain verifies this proof in a single, relatively cheap operation.
Succinct Labs' bridge and zkBridge are examples. A ZK proof can compress the verification of hundreds of block headers into a single proof that costs a fixed amount of gas to verify on-chain. This combines the security of light client verification with much lower on-chain costs. However, generating ZK proofs is computationally expensive off-chain, and the proving technology is still maturing.
Hash Time-Locked Contracts (HTLCs)
HTLCs are the oldest cross-chain mechanism, predating the modern bridge era. They enable atomic swaps -- peer-to-peer exchanges of assets across chains without any intermediary. The protocol uses a combination of hash locks and time locks to ensure that either both sides of the swap execute, or neither does.
The process works as follows: Alice wants to swap BTC for Bob's ETH. Alice generates a secret value S, computes its hash H = hash(S), and creates a Bitcoin transaction locked with H and a time deadline (say, 24 hours). Bob sees H on the Bitcoin chain and creates a corresponding Ethereum transaction locked with the same H but a shorter deadline (say, 12 hours). Alice claims Bob's ETH by revealing S on Ethereum. Bob sees S on Ethereum and uses it to claim Alice's BTC on Bitcoin. If Alice never reveals S, both transactions expire and the funds return to their owners.
HTLCs are elegantly trustless but limited. They require both parties to be online during the swap window, support only simple asset exchanges (not arbitrary message passing), and suffer from the free option problem: Alice can wait to see if the exchange rate moves favorably before deciding whether to reveal S. For these reasons, HTLCs were never widely adopted for general-purpose bridging, though they remain important in payment channel networks like Lightning.
Relay Chains and Hub-and-Spoke Models
Instead of building point-to-point bridges between every pair of chains (which scales as O(n^2)), some architectures use a central relay chain that all connected chains bridge to. This reduces the number of bridges needed to O(n) -- each chain only needs one bridge, to the relay.
Polkadot's Relay Chain is the canonical example. Parachains (application-specific blockchains) connect to the Relay Chain, which provides shared security and cross-chain messaging via XCMP (Cross-Consensus Message Format). The Relay Chain validators verify state transitions on all connected parachains, so cross-chain messages between parachains are verified by the same validator set that secures both chains.
Cosmos takes a different approach with its Hub-and-Spoke model. The Cosmos Hub acts as a central routing point for IBC packets, but it does not provide shared security -- each chain runs its own validator set. Cross-chain messages routed through the Hub benefit from the Hub's connectivity, but the security of each link depends on the light client verification at each endpoint.
The Bridge Hack Graveyard: $2 Billion and Counting
Bridges have been the single largest source of losses in the blockchain ecosystem. The locked collateral in bridge contracts creates an irresistible target: compromise one smart contract or one set of keys, and you can drain hundreds of millions in a single transaction. Here are the most devastating incidents.
Ronin Bridge -- $624 Million (March 2022)
The Ronin Bridge connected the Ronin sidechain (used by the game Axie Infinity) to Ethereum. It used a 5-of-9 multisig validation scheme. The Lazarus Group, a North Korean state-sponsored hacking group, compromised five of the nine validator private keys -- four belonging to Sky Mavis (the company behind Axie Infinity) and one from the Axie DAO. With five keys, they had the threshold needed to sign fraudulent withdrawal transactions, draining 173,600 ETH and 25.5 million USDC. The hack went undetected for six days.
Wormhole -- $320 Million (February 2022)
Wormhole is a cross-chain messaging protocol connecting Ethereum, Solana, and other chains. The attacker exploited a vulnerability in the Solana-side verification logic. Specifically, a deprecated function (verify_signatures) failed to properly verify the guardian set, allowing the attacker to forge a message claiming that 120,000 ETH had been deposited on Ethereum. The Solana contract accepted this forged message and minted 120,000 wETH on Solana, which the attacker then partially bridged back to Ethereum for real ETH.
Nomad Bridge -- $190 Million (August 2022)
The Nomad hack was uniquely chaotic. An upgrade to the bridge's smart contract initialized the trusted root to 0x00, which meant that any message was treated as already proven. The first attacker discovered this and drained funds. Then, because the exploit was trivially reproducible (just copy the attacker's transaction and change the recipient address), hundreds of copycats piled in. It became a free-for-all: anyone who could copy-paste a transaction could drain the bridge. The entire $190 million TVL was emptied in hours.
Harmony Horizon -- $100 Million (June 2022)
The Horizon Bridge connecting Harmony to Ethereum used a 2-of-5 multisig. Two keys were enough. The attacker compromised two private keys and drained the bridge of its entire holdings. The absurdly low threshold (only 2-of-5 required) made this attack straightforward.
Common Attack Patterns
Across all major bridge hacks, several patterns recur:
- Key compromise -- Ronin, Horizon. When the bridge security reduces to M-of-N keys, attackers target the key holders. State-sponsored groups have the resources for sophisticated social engineering and infrastructure compromise.
- Smart contract bugs -- Wormhole, Nomad. Verification logic errors, initialization mistakes, and upgrade vulnerabilities in the bridge contracts themselves. These are especially dangerous because they can be exploited in a single transaction.
- Insufficient decentralization -- Many bridges launched with small validator sets or low thresholds to optimize for speed and cost, then got hacked before they could decentralize further.
The Interoperability Trilemma
Arjun Bhuptani (founder of Connext) articulated the interoperability trilemma: a cross-chain protocol can optimize for at most two of three properties:
- Trustlessness -- The bridge does not require trust in any third party; verification is cryptographic.
- Extensibility -- The bridge can connect to any blockchain, not just those with specific properties (e.g., specific consensus algorithms).
- Generalizability -- The bridge supports arbitrary cross-chain data/messages, not just token transfers.
Light client bridges (like IBC) achieve trustlessness and generalizability but sacrifice extensibility -- they require each connected chain to be able to run the other's light client, which constrains the set of supported chains. Multisig bridges achieve extensibility and generalizability but sacrifice trustlessness. Atomic swaps (HTLCs) achieve trustlessness and extensibility but sacrifice generalizability -- they only support simple swaps, not arbitrary messages.
This trilemma explains why no single bridge design dominates. Different applications have different requirements, and bridge designers must choose which tradeoffs to accept.
IBC: The Cosmos Approach to Interoperability
The Inter-Blockchain Communication (IBC) protocol, developed within the Cosmos ecosystem, is the most mature trustless cross-chain standard. IBC defines a layered architecture for cross-chain communication:
- Transport layer (TAO) -- Handles connections, channels, and packet delivery semantics. This is the infrastructure for sending bytes between chains.
- Application layer -- Defines what those bytes mean. ICS-20 (fungible token transfer) is the most widely used application module, but IBC can carry any data.
- Light clients -- Each chain maintains a light client of every chain it connects to. The light client tracks consensus state (validator sets, block headers) and can verify Merkle proofs of state inclusion.
- Relayers -- Off-chain processes that monitor source chains for outgoing packets and submit them (with proofs) to destination chains. Relayers are permissionless -- anyone can run one, and they cannot forge messages because the destination chain verifies every proof independently.
IBC has processed billions of dollars in cross-chain transfers across the Cosmos ecosystem with zero security incidents attributable to the protocol itself. Its security comes from the fact that verification is entirely on-chain and cryptographic. However, IBC was designed for Tendermint-based chains and requires significant engineering effort to support chains with different consensus mechanisms. Extensions like IBC on Ethereum (using zero-knowledge proofs to verify Ethereum's consensus) are in development but not yet production-ready.
LayerZero: Configurable Security
LayerZero takes a different approach to the interoperability problem. Rather than prescribing a single verification mechanism, it provides a configurable messaging layer where each application can choose its own security model. At its core, LayerZero separates two functions:
- Oracles -- Independent entities that relay block headers from the source chain to the destination chain. In early versions, this was often Chainlink or another oracle network.
- Relayers -- Entities that submit transaction proofs corresponding to those block headers.
The security assumption is that the oracle and relayer are independent -- as long as they do not collude, fraudulent messages cannot pass verification. If the oracle provides a correct block header and the relayer provides a valid proof against that header, the message is authentic. This is weaker than full light client verification (you trust two independent parties instead of cryptography alone) but stronger than a simple multisig.
LayerZero V2 introduced Decentralized Verifier Networks (DVNs), allowing applications to require verification from multiple independent DVNs. An application might require attestation from both a Chainlink DVN and a proprietary DVN, creating a multifactor security model. This configurability is powerful but shifts security decisions to application developers, who may not always choose optimal configurations.
Chainlink CCIP: The Oracle Network Approach
Chainlink's Cross-Chain Interoperability Protocol (CCIP) leverages Chainlink's existing decentralized oracle network infrastructure for cross-chain messaging. CCIP adds several layers of defense:
- Committing DON (Decentralized Oracle Network) -- A set of oracle nodes that monitor the source chain, reach consensus on cross-chain messages, and commit a Merkle root to the destination chain.
- Executing DON -- A separate set of nodes that submit the messages for execution on the destination chain after the committed root is verified.
- Risk Management Network (RMN) -- An independent, separate network of nodes that monitors for anomalies. The RMN can halt the bridge if it detects suspicious activity (e.g., large unexpected transfers). This is a secondary defense layer -- even if the primary oracle network is compromised, the RMN can stop the attack.
The separation between committing, executing, and monitoring creates defense in depth. An attacker would need to compromise both the primary DON and the independent Risk Management Network. CCIP also supports programmable token transfers, where tokens are locked or burned on the source chain and minted or unlocked on the destination, with arbitrary logic attached to the transfer.
The tradeoff is that CCIP's security ultimately derives from the Chainlink oracle network -- a permissioned set of professional node operators. This is more decentralized than a corporate multisig but less trustless than pure cryptographic verification.
Why Bridges Are Hard: Deeper Reasons
Beyond the interoperability trilemma, bridges face several fundamental challenges that make them inherently more dangerous than single-chain applications.
Composability of Failures
A bridge connects two complex systems. A bug in either chain's consensus, a reorganization on either chain, a gas price spike on either chain, or a smart contract vulnerability on either chain can compromise the bridge. The attack surface is the union of both chains' attack surfaces plus the bridge's own code. Single-chain DeFi protocols only need to worry about one execution environment.
Finality Mismatches
Different chains have different finality guarantees. Bitcoin has probabilistic finality -- a transaction becomes exponentially harder to reverse with each confirmation, but is never truly final. Ethereum with proof-of-stake achieves economic finality after two epochs (~12.8 minutes). Tendermint chains achieve instant finality. When bridging between chains with different finality models, the bridge must decide how many confirmations to wait. Too few, and a chain reorganization on the source can cause the bridge to credit assets that were never actually sent. Too many, and the user experience suffers.
Upgrade and Governance Risk
Bridge smart contracts often need to be upgradeable (to fix bugs and add features), but upgradeability introduces governance risk. The Nomad hack was caused by a faulty upgrade. If the upgrade authority is a multisig or governance token, compromise of that authority means compromise of the entire bridge. If the contracts are immutable, bugs cannot be fixed. There is no good answer.
Economic Security Scaling
The economic security of a bridge (the cost to attack it) must scale with the value it secures. A bridge holding $1 billion needs security guarantees worth more than $1 billion -- otherwise, a rational attacker will simply pay the cost to compromise it. For multisig bridges, this means each validator must have more at stake than their share of the bridge's TVL. For light client bridges, this is less of an issue (the security is cryptographic, not economic), but the underlying chains must themselves be economically secure.
The Future of Cross-Chain Interoperability
The bridge landscape is evolving rapidly in several directions:
Intent-Based Bridging
Instead of moving assets through a bridge contract, intent-based systems like Across Protocol use a network of fillers (solvers) who front the assets on the destination chain immediately, then settle the reimbursement on the source chain later. The user gets instant execution, and the settlement layer handles the actual cross-chain verification asynchronously. This separates the user experience (fast) from the security mechanism (slow but trustless).
Shared Sequencers and Shared Security
Projects like Espresso and Astria are building shared sequencers that order transactions for multiple rollups simultaneously. If two rollups share a sequencer, cross-chain atomic transactions become possible without a traditional bridge -- the sequencer can ensure that both legs of a cross-chain operation are included or neither is.
ZK-Proven Bridges at Scale
As zero-knowledge proof generation becomes faster and cheaper, ZK bridges are becoming practical. A ZK bridge to Ethereum, for example, would generate a proof that a set of Ethereum beacon chain headers is valid, verify it on the destination chain, and then use Merkle proofs against those headers to verify any Ethereum state. This gives light-client-grade security without the gas cost of on-chain header verification. Projects like zkBridge and Polymer are pursuing this approach.
Chain Abstraction
The end goal for many interoperability projects is chain abstraction -- making the user unaware of which chain their assets are on or which chain is executing their transaction. Protocols like Socket, NEAR's chain signatures, and Particle Network aim to let users interact with any chain from a single account and interface, with bridging handled transparently in the background. This requires reliable, fast, and cheap bridges as a primitive, which in turn requires solving the security challenges described throughout this article.
Bridges and Network Infrastructure
Cross-chain bridges, for all their complexity, ultimately rely on the same physical internet infrastructure as everything else. Bridge relayers, oracle nodes, and validators communicate over TCP/IP. Their traffic is routed via BGP across autonomous systems. The availability and latency of bridge operations depend on the same network topology that governs all internet traffic.
This creates an often-overlooked attack vector: BGP-level attacks. A BGP hijack could reroute traffic between bridge validators, enabling man-in-the-middle attacks on their communication channels. If a bridge's validator nodes are concentrated in a small number of networks, a targeted routing attack could partition them. The same RPKI protections that secure BGP routing are relevant to bridge security -- validators should ensure their network announcements are cryptographically signed to prevent traffic interception.
You can explore the network infrastructure that underlies these systems by looking up the hosting providers and networks that blockchain infrastructure runs on: