Cross-chain bridges are supposed to make blockchains useful together. Instead, they have become one of crypto’s favorite attack surfaces, with more than $4 billion stolen from bridges since 2021.
- Blockchains don’t natively communicate: bridges exist to move assets and messages between separate ledgers.
- Trust assumptions are the real battleground: most bridge failures trace back to weak verification or bad key setup.
- Safer designs usually cost more: stronger security tends to mean slower transfers, higher gas, or more complexity.
- The biggest hacks were predictable in hindsight: Ronin, Wormhole, Nomad, and Harmony all exposed structural weaknesses.
Bitcoin, Ethereum, Solana, Arbitrum, Avalanche, and the rest all keep their own books. They do not naturally read each other’s state. If value is going to move across those chains, some system has to prove that something happened on chain A so chain B can act on it.
That system is the bridge.
The idea is simple. The execution is where the bodies are buried.
According to Coinbase’s analysis of bridge hacks cited by the source material, bridge exploits have caused roughly $3 billion of the $17 billion lost to crypto hacks over the past decade. The same material describes bridges as the most attacked category of smart contracts. That should surprise exactly no one. They concentrate value, complexity, and trust assumptions in one place, which is basically a neon sign for attackers.
How cross-chain bridges work and why $4 billion has been
At a basic level, a bridge has to do two things:
- Detect that an event happened on the source chain.
- Allow something to happen on the destination chain only if that event was real.
The hard part is the second step. A bridge must decide who or what is trusted to verify the event. That choice defines the security model. If the model is weak, the bridge can be tricked into minting fake assets, releasing locked funds, or accepting false messages.
There are four common design patterns: lock-and-mint, burn-and-mint, liquidity pool bridges, and intent-based transfers. They all try to solve the same problem, but they do it with very different tradeoffs.
Lock-and-mint: the wrapped-asset model
Lock-and-mint is the classic bridge setup. An asset is locked on the source chain, and a wrapped version is minted on the destination chain. The wrapped token is a claim on the original asset.
It works, but only if the bridge correctly verifies that the lock really happened.
If verification fails, the bridge can mint wrapped assets that are not backed by anything. That is not interoperability. That is counterfeit finance with a smart contract logo.
Wormhole is one of the clearest examples. On February 2, 2022, attackers exploited the bridge and stole approximately $326 million. Wormhole used 19 guardians, and those guardians signed a VAA, or Verified Action Approval, which is the bridge’s attestation that a cross-chain event is valid.
The exploit centered on the Solana-side contract, which used a deprecated instruction called verify_signatures. The attacker was able to forge the conditions that the contract accepted as proof, which led it to mint 120, 000 wETH. Jump Crypto later replaced the stolen 120, 000 ETH from its own reserves, and the bridge was restored within 24 hours.
That recovery mattered. It also underscored the uncomfortable truth that a bailout is not a security model. It is damage control with a balance sheet.
Burn-and-mint: cleaner, but not automatically safer
Burn-and-mint is usually a cleaner model for assets like stablecoins. The original token is burned on the source chain, and a native version is minted on the destination chain.
Circle’s Cross-Chain Transfer Protocol, or CCTP, uses this approach for USDC and supports over a dozen chains. The appeal is obvious. Users receive native USDC on the destination chain, rather than a wrapped token whose value depends on the bridge staying honest and solvent.
The key question is still verification. The destination chain has to know the burn really happened before it mints anything new. In CCTP, Circle’s attestation system is what proves the burn occurred.
That is a better trust model than “some wrapped token somewhere says so, ” but it does not make the system magic. The operational setup still has to be correct, keys still have to be protected, and the control plane still has to survive abuse.
Liquidity pool bridges: fast, but capital hungry
Liquidity pool bridges use pre-funded token pools on multiple chains. Instead of minting a wrapped asset, the bridge pays out from liquidity that already exists on the destination chain.
That makes transfers fast. The user does not have to wait for a long finality and verification process to finish before receiving funds.
Examples include Stargate, built on LayerZero, and Across Protocol. The upside is speed and a smoother user experience. The downside is capital efficiency. Someone has to lock up real value in those pools so the system can settle instantly.
That means thin liquidity can become a bottleneck, while thick liquidity requires a lot of idle capital. Speed is nice. Paying for it is less fun.
Intent-based transfers: solve first, settle later
Intent-based systems go a step further. Instead of forcing the protocol itself to move assets across chains, a solver or relayer fulfills the user’s request from its own inventory and gets reimbursed later.
In plain English: a solver is an entity that fronts the liquidity or execution so the user gets paid quickly, then settles behind the scenes.
Across Protocol and UniswapX’s cross-chain mode are examples of this model. The user gets a fast outcome; the solver takes on execution risk and arbitrage-style responsibility for making the transfer work.
This can be elegant, especially for good routes with healthy liquidity. It can also get messy when liquidity is thin, routing is awkward, or no solver wants the trade. The UX is better, but the system still depends on economic incentives doing their job.
Why bridges keep getting wrecked
Bridge hacks are rarely one-dimensional. Sometimes the flaw is bad code. Sometimes it is weak signer independence. Sometimes it is a bad initialization step. Often it is a system that claimed one trust model while actually relying on something much weaker.
Ronin is the big example of that failure mode. On March 23, 2022, the bridge connecting Ethereum to the Ronin sidechain was hit for $624 million, including 173, 600 ETH and 25.5 million USDC. Ronin had nine validator nodes, and any five could authorize a withdrawal.
Sky Mavis controlled four of those nine nodes. A fifth validator had been granted temporary permission that was never revoked. That is the kind of operational mess that turns a multisig from a security measure into expensive theater.
The exploit was not discovered for six days. The FBI later attributed the attack to North Korea’s Lazarus Group.
Harmony Horizon suffered a similar fate. In June 2022, attackers compromised the private keys of two out of five validators and drained $100 million. Security researchers had already criticized the two-of-five threshold before the attack. They were right. A threshold is only as strong as the independence of the keys behind it.
Nomad, hacked on August 1, 2022, lost approximately $190 million. Its optimistic verification model assumed messages were valid unless someone challenged them during a 30-minute fraud proof window. The core failure came from initialization with a trusted root of 0x00, which meant the bridge effectively started from a broken assumption. White-hat hackers later returned about $36 million in recovered funds.
The common thread is painfully clear: bridge verification code is high-value attack surface, and bad assumptions can collapse the whole design.
What optimistic verification actually means
An optimistic bridge accepts messages by default and gives others a window to challenge them with a fraud proof. If nobody challenges the claim in time, the message is treated as valid.
That approach can work. It reduces friction and can be cheaper than constantly proving everything upfront. But if the trusted starting state is wrong, or the challenge logic is broken, the system can fail in a hurry.
Nomad showed exactly how ugly that can get. A bridge that assumes correctness until challenged is only as good as its initialization, its monitoring, and its challenge mechanism. Miss one of those, and the “optimistic” part becomes a polite word for “hopeful and vulnerable.”
What stronger bridge security looks like
There are stronger approaches, but they come with real costs.
Light client bridges verify the source chain’s consensus directly rather than trusting a committee of external signers. A light client is a lightweight verifier that checks enough of the source chain to know whether a message is legitimate. It is much closer to “trust the math, not the committee.”
The drawback is computation. Verifying Ethereum consensus on another chain is expensive, and that cost shows up in gas fees and implementation complexity. In other words, better security is often slower and more expensive to deploy.
Zero-knowledge proof, or ZK, verification is pushing that model forward. A ZK proof can compress a large verification process into one succinct proof that another chain can verify efficiently. Projects including Succinct Labs, Polymer, and Lagrange are building ZK-verified bridges. Some projects already operate on mainnet with proving times under 30 seconds, according to the material.
That is encouraging, but not a free pass. ZK systems still need prover infrastructure, careful implementation, and a security model that can survive real-world pressure. The crypto industry loves to chant “trust the math” as if the math is the only thing that can fail. It is not.
How to think about bridge risk before using one
No single bridge is best for every token, chain, or transfer size. A route that is fine for a small test can be a bad idea for a large transfer. Security should come before convenience, even if the UI is shiny and the fees are tempting.
Before using a bridge, check a few basics:
- What verification mechanism does it use?
- How independent are the validators or guardians?
- What does the audit history look like?
- How much value does it hold relative to its security budget?
- Is there a canonical bridge for the chain, especially for rollups like Arbitrum, Optimism, or Base?
- Can you test with a small amount first?
A canonical bridge is the official bridge recommended by the chain or rollup team. That does not make it magically invincible, but it usually means fewer extra trust assumptions than a third-party route.
Bridge aggregators like Li.Fi, Socket, and Bungee can help compare routes, but aggregation is not a security guarantee. It just means someone else is picking among the available options. You still need to know what that option is actually trusting.
There is also a boring but necessary reality check: not every loss comes from the bridge contract itself. Wallet compromise, phishing, bad approvals, and sloppy operational security still take users out every day. A secure bridge cannot save someone who signs away their keys like a sleep-deprived intern at a bad startup.
Why the safer path is often the less convenient one
The bridge industry keeps running into the same tradeoff: stronger security usually means more cost, more complexity, or more latency. That is why weak models keep getting used. Users want speed, protocols want adoption, and attackers want the path with the least resistance and the most value.
Bridges are necessary because blockchains are isolated by design. That isolation protects sovereignty, but it also creates friction. The challenge is to build interoperability without turning the bridge into a giant theft machine.
The long-term answer probably looks less like “a trusted committee with a logo” and more like cryptography doing the heavy lifting. Light clients and ZK proofs point in that direction. They are not perfect, and they are not cheap, but they are far more credible than pretending a few signatures can safely secure billions.
Crypto does not need more glossy promises. It needs fewer stupid trust assumptions and more systems that can survive contact with reality.
Ripple’s Game-Changer: Zero-Knowledge Proofs to and Ripple Unveils XRP Ledger Privacy Upgrade with both point to the same basic truth: zero-knowledge tech is moving from theory into practical infrastructure, and payment rails are one of the most obvious places to use it.
That matters because the bridge problem is not just about moving tokens. It is about proving things across systems without handing over the keys to the kingdom.
Coinbase Pushes Zero-Knowledge Proofs to Overhaul Outdated Bank Secrecy Act is another reminder that ZK proofs are not only a crypto-native curiosity. They also have real privacy and compliance applications outside the usual token circus.
Key questions and takeaways
-
Why do cross-chain bridges get hacked so often?
They concentrate value and rely on a verification step that can be broken, misconfigured, or manipulated. When the bridge’s trust assumptions are weak, the damage can be massive. -
Are multisig bridges safe?
Only if the signers are truly independent and the threshold is sensible. Ronin and Harmony showed that a weak signer set can fail spectacularly. -
What is the strongest bridge model today?
Light client and ZK-verified bridges are generally the strongest trust-minimized options because they rely more on cryptography than on a small committee of signers. -
Are wrapped assets always a bad idea?
No. Wrapped assets can be useful and necessary, but they inherit bridge risk. If the bridge fails, the wrapper can lose confidence and drift from parity. -
Should users default to canonical bridges?
Usually yes, especially for rollups like Arbitrum, Optimism, and Base. Canonical bridges are generally safer because they avoid some extra trust layers, though they are not risk-free.
