Published on Sat Aug 22 2026 00:00:00 GMT+0000 (Coordinated Universal Time) by Jacob Cavazos

Blockchains do not talk to each other by default. A contract on Ethereum cannot read state on Solana, and a token native to one chain has no meaning on another. Cross-chain bridges exist to solve this problem. They move assets and messages between networks that share no consensus, no validator set, and no native trust.

Bridges are also the most repeatedly exploited category in crypto. According to public tracking by DefiLlama, over $2.6 billion was lost to bridge exploits in the years leading up to 2023. The reason is structural: bridges concentrate value. To let users move assets between chains, a bridge typically holds large reserves of locked tokens on one side while issuing claims on the other. That pool of locked collateral becomes a single, high-value target.

Not all bridges work the same way, and the differences matter. The security of a bridge is determined less by its marketing and more by its underlying architecture and trust assumptions. This article breaks down the four dominant bridge security models, what each one trusts, and what the public record of bridge hacks tells us about where each model fails.

What a Bridge Actually Does

At its core, a bridge is a protocol that takes an action on chain A and produces a corresponding, verified action on chain B. The most common action is moving value: lock 100 USDC on Ethereum, receive 100 USDC on Polygon. But bridges also move arbitrary messages, which lets them power cross-chain governance, inter-chain contract calls, and multi-chain applications.

Every bridge has to solve two problems. First, it has to verify that the event on the source chain actually happened. Ethereum and Solana do not share a consensus mechanism, so chain B cannot natively trust chain A. Second, it has to act on that verification, releasing or minting assets on the destination.

How a bridge solves those two problems defines its security model. The four models below cover the vast majority of production bridges today.

Model 1: Lock-and-Mint

Lock-and-mint is the oldest and most common bridge design — for a full comparison of lock-mint, burn-mint, and liquidity pool architectures, see Bridge Architecture. The flow is simple. A user deposits tokens into a custody contract on the source chain. The bridge detects the deposit, verifies it, and mints a wrapped version of the token on the destination chain. The wrapped token is an IOU, backed one-to-one by the locked collateral. When the user wants to go back, they burn the wrapped token on the destination and the bridge releases the original from custody.

Wormhole, Multichain, and many early bridges used variations of this model. The wrapped tokens that circulate on destination chains, like Wormhole-wrapped ETH on Solana, are claims on locked reserves.

The trust assumption here is significant. Users are trusting the custody contract on the source chain to hold the collateral, and they are trusting the verification mechanism to only authorize mints that correspond to real deposits. If an attacker can forge a verification message, they can mint wrapped tokens that have no backing. That is exactly what happened to Wormhole.

The Wormhole Hack

On February 2, 2022, an attacker exploited a signature verification vulnerability in the Wormhole bridge on Solana. According to Wormhole’s own incident report and independent analyses by CertiK and Chainalysis, the attacker bypassed the guardian signature verification by injecting a fake sysvar account. This let them generate a malicious validator action approval, or VAA, that instructed the Solana-side contract to mint 120,000 wrapped ETH without any corresponding deposit on Ethereum.

The attacker then bridged roughly 93,750 of those wrapped ETH back to Ethereum and redeemed them for native ETH. The total loss was approximately $323 million. Jump Crypto, Wormhole’s parent company, recapitalized the bridge to make wrapped ETH holders whole. The root cause was a smart contract bug in the verification logic, not a key compromise.

Lock-and-mint bridges are only as secure as their verification layer and their custody contract. A bug in either one can mint unbacked tokens at scale.

Model 2: Burn-and-Mint

Burn-and-mint is the mirror image of lock-and-mint, and it is the model used by native asset bridges like LayerZero’s OFT standard and some stablecoin issuer bridges. Instead of locking tokens on the source chain, the bridge burns them. The destination chain then mints a fresh supply.

This model is most practical when the token issuer controls both sides of the bridge. Circle, for example, can burn USDC on one chain and mint it on another because Circle is the issuer and can attest to the burn. The token supply stays constant globally because nothing is locked, nothing is wrapped, and there is no separate IOU token.

The trust assumption shifts. There is no pool of locked collateral sitting in a contract, which removes the honeypot problem. But users are now trusting the token issuer, or the bridge’s attestation layer, to correctly authorize mints only after a verified burn. If the attestation layer is compromised, an attacker can mint tokens without burning anything.

Burn-and-mint is generally cleaner for native assets but does not work for arbitrary third-party tokens, where the issuer has no control over minting on the destination chain.

Model 3: Liquidity Pool Bridges

Liquidity pool bridges do not lock or mint anything. Instead, they maintain pools of liquidity on both chains. A user deposits USDC into the Ethereum pool and receives USDC from the Polygon pool. The bridge rebalances later, or pays liquidity providers a fee for providing capital on both sides.

Across, Stargate, and Synapse use variations of this model. The advantage is that users receive the native token, not a wrapped IOU. There is no separate wrapped asset to worry about, and no single custody contract holding all the collateral for a given asset.

The trade-off is liquidity fragmentation. Every chain pair needs its own pool, and liquidity providers take on the risk of rebalancing. The security assumption is split between the liquidity pool contracts and the verification layer that tells the destination pool to release funds. If the verification layer is tricked into authorizing a release, the liquidity pool is drained.

Liquidity pool bridges also introduce a different failure mode: insolvency. If the source-side deposit never actually settles, or if the bridge’s accounting gets out of sync, the destination pool can release funds it is not actually backed for. This is less catastrophic than minting unbacked wrapped tokens at scale, but it still results in loss.

Model 4: Intent-Based and Solver Bridges

The newest model is intent-based bridging. Instead of a user calling a bridge contract directly, the user signs an intent: I want 100 USDC on Polygon, and I am willing to pay up to X in fees and slippage. Off-chain solvers, also called fillers or relayers, compete to fulfill that intent. A solver sends the user 100 USDC on Polygon from their own inventory, and in exchange receives the user’s deposit on Ethereum.

Across was an early proponent of this with its intent architecture, and the model has spread. The key property is that the user receives the destination asset before the bridge settles the source-side deposit. Settlement between solvers and the protocol happens later, often through a rebalancing or reconciliation process.

The security assumption is different again. Users are trusting the solver network and the settlement layer. If a solver front-runs or fails to settle, the protocol needs a mechanism to penalize them, typically by bonding capital that can be slashed. The advantage is that users do not have to wait for finality on the source chain, and there is no wrapped token risk.

The risk is that the settlement layer, often an optimistic or challenge-based system, can be gamed if the challenge window is too short or if watchers are not actively monitoring. Intent bridges trade custody risk for settlement risk.

The Nomad Hack: When Verification Breaks

The Nomad bridge hack in August 2022 is the clearest example of a verification layer failing in a way that affected all of the above models. Nomad used an optimistic verification mechanism built on Merkle trees. Messages were committed to a Merkle tree, the root was propagated to remote chains, and messages were proven against that root.

According to Nomad’s own root cause analysis and a Halborn postmortem, a routine upgrade to the Replica contract initialized the trusted root to the zero hash, 0x00. In Solidity, an uninitialized mapping returns the zero value by default. The protocol’s acceptableRoot check was supposed to return true only for valid roots whose optimistic timeout had elapsed. But because the zero hash was now a trusted root, and because unproven messages defaulted to a root of bytes32(0), every message was treated as automatically proven.

The result was catastrophic and bizarre. Anyone who copied a valid exploit transaction and replaced the recipient address with their own could drain funds. It became what observers called a decentralized crowd looting event. Approximately $190 million was drained, not by a single sophisticated attacker, but by dozens of copycat transactions. The root cause was a configuration error, not a key compromise and not a complex exploit.

Nomad’s failure shows that the verification layer is the most fragile part of any bridge. A single misconfiguration can make the entire authentication system collapse.

The Multichain Hack: When Keys Are the Weak Point

The Multichain hack in July 2023 illustrates a completely different failure mode. Multichain used an MPC, or multi-party computation, key management system to approve cross-chain transactions. According to Chainalysis and CoinDesk reporting, the company’s CEO, Zhaojun He, was detained by Chinese authorities in May 2023. The bridge’s MPC keys were held on a centralized server under his control.

In July, approximately $126 to $210 million in assets were drained from Multichain’s Fantom, Moonriver, and Dogecoin bridge contracts. The funds moved to unknown addresses. The root cause was not a smart contract bug. It was centralized key custody. When the person holding the keys became unavailable, the keys were either compromised or used by insiders.

Multichain ceased operations shortly after. The lesson is that any bridge whose security depends on a small set of keys, whether MPC shards, multisig signers, or a single custodian, inherits the operational security of those key holders. A bridge can have perfect smart contracts and still fail if its key management is centralized.

Comparing the Trust Assumptions

Each bridge model trusts something different, and understanding that difference is the point of this article.

Lock-and-mint bridges trust the custody contract and the verification layer. If either is compromised, unbacked tokens get minted. The Wormhole hack was a verification bug. The custody contract held real ETH, but the verification layer was tricked into minting claims against it.

Burn-and-mint bridges trust the attestation layer and the token issuer. There is no locked collateral to steal, but a compromised attestation layer can mint unbacked tokens. This model is strongest when the issuer is also the bridge operator.

Liquidity pool bridges trust the pool contracts and the verification layer. There is no wrapped token, but the pools can be drained if verification is bypassed. The risk is more contained per asset but requires deep liquidity on every chain pair.

Intent-based bridges trust the solver network and the settlement layer. Users get their destination asset fast, but the protocol depends on solvers being honest and on the settlement mechanism being enforced. Slashing and bonding are the primary security levers.

Across all four models, the two recurring failure points are verification logic and key management. Wormhole and Nomad failed on verification. Multichain failed on keys. No model is immune to either.

What Makes a Bridge More Secure

There is no single bridge design that eliminates risk. But the public record of hacks points to several principles that reduce it.

First, minimize the value held in any single contract. Liquidity pool bridges and intent bridges do this naturally by spreading collateral across pools and solver inventories. Lock-and-mint bridges concentrate it, which is why they have produced the largest single losses.

Second, make verification as simple and well-audited as possible. Nomad’s failure was a configuration error in a complex optimistic verification system. Simpler verification, like a light client that directly checks consensus proofs, has fewer edge cases but is harder to build for arbitrary chains.

Third, decentralize key management. Multichain’s collapse was a direct consequence of one person holding the keys. Bridges that distribute signing across many independent operators, with transparent slashing, are harder to compromise through a single point of failure.

Fourth, use multiple independent verification paths. Some bridges combine a primary verification mechanism with a watcher or guardian network that can pause the bridge if it detects fraudulent messages. This adds a layer of defense, though it also adds a centralization risk if the watchers can unilaterally halt traffic.

The Honest Takeaway

Bridges are necessary infrastructure for a multi-chain world, and they are also the most dangerous category in crypto. The security model matters more than the brand — for institutions, ISO 20022 compliance adds another layer of consideration. A lock-and-mint bridge with a buggy verification layer is more dangerous than a liquidity pool bridge with shallow liquidity, because the former can mint unlimited unbacked tokens while the latter can only drain what is in the pool.

Anyone using a bridge, building on one, or evaluating one should ask the same questions — our guide on how to bridge to Base chain walks through these choices in practice. What does this bridge trust? Where is the value held? Who controls the keys? What happens if the verification layer is wrong? The answers to those questions, not the marketing page, determine whether a bridge is safe to use.

The hacks described here, Wormhole, Nomad, and Multichain, are all public, documented, and analyzed. They are not edge cases. They are the predictable consequences of specific architectural choices. Understanding those choices is the first step toward not repeating them — and choosing the right bridge for your transfer to Base starts with our guide to bridging.

Frequently Asked Questions

What is a lock-mint bridge?

A lock-mint bridge locks the original asset in a smart contract on the source chain and mints a representative token on the destination chain. The minted token is backed 1:1 by the locked asset. When bridging back, the representative token is burned and the original asset is released from the lock contract.

What is a burn-mint bridge?

A burn-mint bridge burns the asset on the source chain and mints an equivalent amount on the destination chain. This model requires the asset to be natively supported on both chains, meaning the token contract exists on each network. It avoids holding collateral but depends on the bridge’s minting authority being secure.

What is a liquidity pool bridge?

A liquidity pool bridge uses pre-funded pools of assets on each chain to enable instant transfers. When you bridge, you deposit into the source chain pool and receive an equivalent amount from the destination chain pool. This model is fast but limited by available liquidity and can become unbalanced when flows are one-directional.

Which bridge model is safest?

No bridge model is universally safest, as each has different risk profiles. Lock-mint bridges risk the locked collateral being stolen if the verification layer is compromised. Liquidity pool bridges are limited by pool depth. The safest choice depends on the specific implementation’s audits, track record, and security assumptions rather than the model alone.

Written by Jacob Cavazos