Cross-Chain Bridges: How Blockchains Talk to Each Other

A Fragmented Ecosystem

The blockchain ecosystem is not a single network — it is dozens of independent chains, each with its own consensus mechanism, native token, and smart contract environment. Bitcoin, Ethereum, Solana, Avalanche, and Cosmos each operate in isolation. A Bitcoin holder who wants to use DeFi protocols on Ethereum cannot simply send their BTC to an Ethereum address — the two networks have no knowledge of each other and no shared consensus.

Cross-chain bridges solve this interoperability problem. They allow assets and, increasingly, arbitrary messages to move between otherwise incompatible blockchains. But bridges are also the single largest source of stolen funds in crypto history — by far. Understanding how bridges work means understanding both their technical mechanics and their security trade-offs.

mint-the-standard-model">Lock-and-Mint: The Standard Model

The most widely used bridge architecture is lock-and-mint (also called custodial bridging or wrapped token bridging).

How It Works

Suppose a user wants to use their BTC on Ethereum. A lock-and-mint bridge operates as follows:

The user sends 1 BTC to a bridge-controlled address (or smart contract) on Bitcoin.
The bridge monitors the Bitcoin blockchain and detects the incoming deposit.
The bridge mints 1 WBTC (Wrapped Bitcoin) on Ethereum — an ERC-20 token backed 1:1 by the locked BTC.
The user receives 1 WBTC and can use it in Ethereum DeFi.

To reverse the process:

The user sends 1 WBTC to the bridge contract on Ethereum, which burns it.
The bridge releases 1 BTC from its Bitcoin custody to the user's Bitcoin address.

The wrapped token (WBTC) represents a claim on the locked original asset. As long as the bridge's custody is secure, 1 WBTC is always redeemable for 1 BTC.

The Custody Problem

Lock-and-mint bridges concentrate enormous value in a single location: the custody mechanism holding the locked assets on the source chain. This makes them the highest-value target in crypto. The Ronin Bridge hack (March 2022, $625 million) drained the Ethereum custody for the Axie Infinity game. The Wormhole hack (February 2022, $325 million) exploited a signature verification bug in the Solana-side contract, minting wrapped ETH without locking real ETH. The Nomad bridge hack (August 2022, $190 million) exploited a contract initialization bug.

The security of a lock-and-mint bridge is only as good as its weakest link: the smart contracts holding locked funds, the private keys of any multisig signers, and the bridge's monitoring infrastructure.

burn-and-release">Burn-and-Release

Burn-and-release is the reverse of lock-and-mint and is used when moving assets back to their native chain. It is also used in canonical bridge designs where the source chain representation is the native token and the destination chain uses a burned supply mechanism to track claims.

In practice, lock-and-mint and burn-and-release are often two sides of the same bridge: assets move from chain A to chain B via lock-and-mint, and back via burn-and-release. The distinction matters for understanding where custody risk is concentrated.

Multisig Bridges: The Most Common Trust Model

Most production bridges use a multisignature (multisig) model: a set of M-of-N signers who collectively control the bridge's custody. To release funds on the destination chain, a threshold of signers must agree and sign the release transaction.

For example, the early Wormhole bridge used a 13-of-19 multisig of "Guardian" validators. The Ronin bridge used a 5-of-9 multisig — but four of those nine keys were controlled by the same organization (Sky Mavis), meaning compromising five keys required compromising only two organizational units. When an attacker gained access to Sky Mavis's four keys plus one external validator's key, they had the required 5-of-9 threshold and drained the bridge.

Multisig bridges make an explicit trust assumption: users trust that fewer than the threshold number of signers will collude or be compromised simultaneously. This is a practical model — it is how most institutional custody works — but it is fundamentally different from the trustlessness of a blockchain's own consensus mechanism.

Light Client Verification: Trust-Minimized Bridges

The gold standard for bridge security is light client verification — where the destination chain verifies cryptographic proofs about the source chain's state, rather than trusting a committee of signers.

How Light Clients Work

A light client is a compact implementation of a blockchain's verification logic. Rather than downloading and verifying every block, a light client tracks block headers (which contain the Merkle root of all transactions and state) and uses cryptographic proofs to verify that a specific transaction or state element is included in a finalized block.

A trust-minimized bridge embeds a light client for chain A inside a smart contract on chain B. When a user locks funds on chain A, they submit a Merkle proof to the chain B contract demonstrating that their transaction is included in a chain A block that the light client has accepted as final. The smart contract verifies this proof entirely on-chain, with no need to trust any external signers.

The security of a light client bridge reduces to the security of the source chain's consensus: if you trust Ethereum's validators, you can trust a bridge that verifies Ethereum block headers. This is fundamentally more trust-minimized than a multisig committee.

Practical Challenges

Light client verification is computationally expensive. Verifying an Ethereum block header on another chain requires checking the BLS aggregate signatures of Ethereum's sync committee — an operation that costs significant gas on chain. ZK proofs have emerged as the solution: a ZK circuit proves that a valid light client computation was performed, and only the compact proof is verified on-chain (expensive to generate, cheap to verify).

Projects like =nil; Foundation's Proof Market, Succinct Labs' Telepathy, and ZKBridge use ZK light clients to build trust-minimized bridges between Ethereum and other chains. Ethereum's own native bridging to rollups uses a form of light client verification enforced by the L1 smart contract.

IBC: Cosmos's Native Interoperability Protocol

The Inter-Blockchain Communication (IBC) protocol, used natively within the Cosmos ecosystem, is the most mature production light client bridge system. Every IBC-connected chain runs light clients for each chain it connects to, updating them as new blocks are finalized. Cross-chain transfers use these light clients to verify packet commitments without any trusted intermediaries.

IBC works smoothly within the Cosmos ecosystem because all chains use Tendermint consensus with fast, deterministic finality — the light client only needs to verify a new finalized block header, not wait for probabilistic confirmation. Extending IBC to chains with different consensus mechanisms (like Ethereum's Gasper) requires more complex light client logic but is an active area of development.

Atomic Swaps: Trustless Peer-to-Peer Exchange

Atomic swaps use Hashed Timelock Contracts (HTLCs) to enable direct peer-to-peer cross-chain exchange without any custodian.

How HTLCs Work

Suppose Alice has BTC and wants ETH, while Bob has ETH and wants BTC.

Alice generates a secret s and computes its hash h = SHA256(s).
Alice creates a Bitcoin HTLC: "Bob can claim 1 BTC by revealing the preimage of h within 24 hours; otherwise Alice can reclaim it."
Bob sees the HTLC and creates an Ethereum HTLC: "Alice can claim 1 ETH by revealing the same preimage of h within 12 hours; otherwise Bob can reclaim it."
Alice reveals s on Ethereum to claim her ETH. This reveals s publicly on-chain.
Bob reads s from Ethereum and uses it on Bitcoin to claim his BTC.

If either party abandons the swap, the other can reclaim their funds after the timeout. The protocol is atomic: either both transfers complete or neither does. No custodian holds funds at any point.

Atomic swaps are theoretically ideal but practically limited: both parties must be online simultaneously, the swap requires multiple on-chain transactions (expensive), and there is no way to match counterparties without a centralized order book or coordinator.

The Security Landscape

The history of bridge hacks reveals a clear hierarchy of attack surfaces:

Smart contract bugs — Incorrect logic in custody contracts (Wormhole, Nomad). Mitigation: audits, formal verification, time-locked upgrades.
Private key compromise — Theft of multisig signer keys (Ronin). Mitigation: hardware security modules, geographic distribution, organizational separation.
Validator collusion — A majority of validators collude to steal funds. Mitigation: larger validator sets, economic bonds, random selection.
Oracle manipulation — Manipulating the price or state data the bridge uses to verify deposits. Mitigation: light client verification.

The fundamental tension is this: bridges that are more trust-minimized (light clients, ZK proofs) are more expensive to operate and slower to verify. Bridges that are cheaper and faster (multisig committees) introduce trusted third parties. Most production bridges accept some level of trust in exchange for usability, while the research frontier focuses on making light client bridges economically viable.

The Future: Native Chain Interoperability

The long-term vision for blockchain interoperability involves reducing reliance on external bridges entirely. Ethereum's rollup-centric roadmap treats rollups as native extensions of Ethereum, with settlement and asset movement handled by the L1 protocol rather than external bridge contracts. Cosmos's IBC achieves similar native interoperability within its ecosystem.

For bridges between fundamentally different consensus systems — connecting Bitcoin to Ethereum, or Solana to Cosmos — the trust-minimized ZK light client approach represents the most promising path toward security comparable to the underlying chains themselves.