How Crypto Bridges Move Billions And Why Hackers Keep Breaking Them

Cross-chain bridges remain one of crypto’s highest-value attack surfaces. Yellow.com has put the problem back in plain terms: bridges have lost more money to exploits than almost any other category, with Ronin at $625 million, Wormhole at $320 million, and Nomad at $190 million in 2022. For smart contract teams, the lesson is not abstract. A bridge is not “token movement.” It is custody, authorization, and state mutation across isolated systems.

The bridge invariant is simple: lock here, issue there

Two chains do not share memory. Bitcoin has no native awareness of Ethereum. Ethereum cannot read a Solana state update by default. Each chain has its own ledger, transaction execution, and consensus.

A bridge creates the appearance of movement by coordinating two separate events.

On the source chain, an asset is locked or burned. On the destination chain, a corresponding representation is minted or released. The invariant is that these two state transitions must remain linked.

That is the full security problem.

If tokens are locked on one side and wrapped tokens are minted on the other, then the locked asset becomes the primary attack surface. If a validator set, multisig, contract, or proof system can authorize minting without a valid source-side event, the bridge has already failed. The exploit may arrive later. The invariant is already broken.

This is why bridge design must be reviewed as a custody system, not as routing middleware. The core question is deterministic: who controls the lock, and who authorizes the print.

Four designs, four failure models

Yellow.com describes four dominant bridge patterns in production. The first is lock-and-mint. A user deposits tokens into a source-chain smart contract. A validator set observes the deposit and instructs the destination chain to mint a wrapped version. Wrapped Bitcoin on Ethereum and much bridged ETH on early Layer 2 networks are cited as examples. The wrapped token is a claim on the locked original. To reverse the flow, the wrapped token is burned and the original is released.

The second model is burn-and-mint. This applies when the token issuer controls supply across chains. The token is burned on the source chain and minted on the destination chain. Circle’s Cross-Chain Transfer Protocol for USDC is cited as operating this way. The relevant trade-off is direct. There is no pool of locked tokens to drain, but authorization is centralized around the issuer.

The third model is liquidity-pool bridging. Hop Protocol and Across Protocol are named as examples. Here the bridge does not necessarily mint a representation. Liquidity providers hold native assets on both sides. A user deposits on the source chain, and an LP delivers the equivalent native asset on the destination chain. The LP is later reimbursed through the protocol.

Each pattern moves the attack vector. Lock-and-mint concentrates risk in custody and mint authorization. Burn-and-mint concentrates it in issuer authority. Liquidity-pool bridges expose settlement, reimbursement, and liquidity assumptions. None removes trust. Each relocates it.

What developers should inspect before integrating

A bridge integration should start with the authorization path, not the SDK.

First, identify the source of truth for cross-chain messages. Is it a validator committee, a multisig, a smart contract, or a cryptographic proof system. Then trace the exact condition that allows a destination-chain mint, release, or payout.

Second, map the asset custody. If the model locks tokens, find the contract or wallet holding the original asset. If the model burns and mints, identify who can authorize supply changes. If the model uses liquidity providers, inspect how reimbursement is triggered and what happens when liquidity is unavailable.

Third, test the invariant directly. A valid bridge flow should never allow destination-side issuance without the corresponding source-side lock or burn. It should never release locked assets unless the destination-side representation has been burned or otherwise settled. Any bypass here is not a bug class. It is the bridge.

The recent coverage is a useful reminder because it strips away the interface language. Bridges do not move assets between chains. They coordinate separate state transitions under some trust model. That trust model is the system. Everything else is transport.