Why Cross-Chain Bridges Keep Getting Drained (And Whether You Need One)

Cross-chain bridges are the single most lucrative target in crypto. In 2022 alone, bridge exploits drained roughly $2 billion, about 69% of all funds stolen from DeFi that year, and the cumulative total across reported bridge incidents now sits well above $2.5 billion. The honest summary: bridges get drained because of their trust assumptions, not just bad code. A bridge has to convince a chain that something happened on a different chain it cannot see. Whatever you trust to make that claim, validators, a multisig, a committee of signers, is the thing an attacker goes after. This post leads with the decision most teams skip: do you even need a bridge, and which trust model fails how.

How do cross-chain bridges actually get drained?

A bridge does one hard thing: it makes chain B believe a deposit happened on chain A. Chain B has no native way to verify chain A, so the bridge inserts an authority that attests to it. That authority is the attack surface. Drain a bridge and you are almost always doing one of three things: you steal the keys that authorize withdrawals, you trick the verification logic into accepting a message that was never valid, or you exploit the economics of a liquidity pool that fronts the funds. The amounts are enormous because a bridge concentrates the locked value of everything that ever crossed it into one contract. There is no per-user blast radius. There is one honeypot.

That framing matters because it tells you where to look. The smart contract code can be flawless and the bridge can still be drained if the off-chain signers are compromised (Ronin). The signers can be honest and the bridge can still be drained if the on-chain verification has a hole (Wormhole, Nomad). You are securing two systems, not one, and most post-mortems trace back to the trust model the team chose at the start.

Three failures dissected: Ronin, Wormhole, Nomad, what each one teaches

Ronin (~$625M, March 2022). The largest bridge hack to date. Ronin used nine validators and required five signatures to approve a withdrawal. The attacker obtained five keys: four were controlled by Sky Mavis, and a fifth came from an Axie DAO validator whose access had been granted earlier and never revoked. With five of nine, the withdrawals were perfectly valid by the bridge's own rules. The code did exactly what it was told. Lesson: an external validator set is only as secure as its key management and its honesty threshold. Five signers is not decentralisation; it is a five-person single point of failure. The breach went unnoticed for six days because no one was watching the signer set.

Wormhole (~$325M, February 2022). A pure verification flaw. Wormhole relied on a set of off-chain "guardians" whose signatures authorize minting on the destination chain. The Solana-side contract used a deprecated instruction to check that signatures had been verified, but it never validated that the signature-verification program was the real one. The attacker supplied a spoofed account, passed the check in a different context, and minted 120,000 wETH with nothing backing it. Lesson: the signers were honest; the on-chain code that trusted them was not careful. A signature scheme is only as good as the contract that checks it.

Nomad (~$190M, August 2022). An optimistic bridge whose verification was effectively switched off by a routine upgrade. Nomad's Replica contract initialised its trusted root to 0x00, the same value an unproven message carries, so every message with an empty proof was treated as already proven. A user sent 0.01 WBTC and pulled out 100. The exploit needed no skill: people copied the working transaction, swapped in their own address, and resubmitted it. It became a crowdsourced free-for-all with hundreds of wallets draining the bridge in hours. Lesson: optimistic and fraud-proof designs put the entire security model in one verification check. Break that check and there is no fallback.

The real question: do you even need a bridge?

Most teams reach for a bridge before they ask whether they should. The cheapest bridge to secure is the one you never build. Before you accept the liability, run three questions:

• Can you stay single-chain? If your users and liquidity live on one chain, a bridge adds an attack surface for a problem you do not have. Pick the right chain and stay there.
• Can you use a canonical / native bridge? Most L2s ship an official bridge maintained by the chain team, secured by the chain's own proof system. It is slower and less flexible than a third-party bridge, but you inherit the chain's security instead of underwriting your own. This is the right default for almost everyone moving assets to and from an L2.
• Do you actually need to move assets, or just messages? Many "we need a bridge" requirements are really "we need to read state from another chain." That is a smaller, cheaper problem than locking and minting value.

Build a custom bridge only when you have a specific reason the canonical and established third-party options cannot serve, and only with eyes open about the audit and operational cost. A bridge is not a feature you ship and forget. It is a contract holding everyone's money, watched by everyone with an incentive to break it.

Bridge trust models and how each one fails

Every bridge picks a trust model. The model decides who you are trusting and therefore how you get drained. This is the comparison to have before you write a line of code.

Native / light-client verification is the most secure because it removes the human trust set entirely: the destination chain checks the source chain's consensus proof itself. It is also the most expensive to build and run, which is exactly why teams talk themselves into a multisig and end up on this list. Wormhole's flaw sat in the gap between a signer model and the contract verifying it; see our note on gas cost trade-offs across L1 and L2 for why the cheap option is rarely cheap in the end.

A pre-launch bridge security checklist

Short, decision-oriented, and ordered by what actually saves you. If you cannot answer the first three, you are not ready to launch.

1. Name your trust model out loud. Write down exactly who can authorize a withdrawal and what it takes to compromise them. If the answer is "five keys," treat it as a five-person single point of failure.
2. Audit both layers together. On-chain verification and off-chain signers are one system. Wormhole and Nomad were on-chain bugs; Ronin was off-chain. Audit the seam, not just the contracts.
3. Revoke aggressively. Ronin fell partly on a stale permission no one removed. Inventory every key and grant, and expire access by default.
4. Monitor the signer set and balances in real time. Ronin ran for six days unnoticed. You need alerting on every withdrawal and every signer change, with a human on call.
5. Build a pause / circuit breaker. A rate limit or a global pause turns a total drain into a contained incident. Nomad had no brake once the first transaction worked.
6. Cap and rate-limit withdrawals. The honeypot is the problem. Caps shrink the prize and buy you time to react.
7. Plan the upgrade path. Nomad's bug arrived in a routine upgrade. Treat every bridge upgrade as a fresh audit, not a patch.

"A bridge is a contract holding everyone's money, watched by everyone with a reason to break it. The cheapest bridge to secure is the one you never build."

Q&A: canonical bridge or third-party bridge?

Default to the canonical bridge when you are moving assets to and from an L2. You inherit the chain's own security and proof system instead of underwriting a separate trust set. Third-party bridges win on speed, on chains a canonical bridge does not connect, and on UX features the official bridge lacks, but you are now trusting that operator's model on top of your own chains. Pick a third-party bridge for what it uniquely gives you, not because it was the first result.

Q&A: is a multisig enough to secure a bridge?

A multisig is a starting point, not a security model. Ronin was a multisig: five of nine, and it lost $625M because five keys were reachable. A multisig only helps if the keys are genuinely independent, held by parties who cannot collude, with hardware custody and revocation discipline. The moment one entity controls a quorum, the multisig is theatre. If your bridge holds meaningful value, a multisig should be one layer with caps, monitoring, and a pause behind it, not the whole defence.

Q&A: do audits guarantee a bridge is safe?

No. An audit reduces the chance of a code bug; it does not change your trust model. Nomad's fatal value was introduced after audits, in an upgrade. Wormhole was audited. An audit is a snapshot of one version of one layer. It cannot certify that your five signers will stay honest or that your next upgrade will not reintroduce a hole. Treat audits as necessary and insufficient. See our pre-audit security checklist for what to do before and after one.

Q&A: should a startup build its own bridge?

Almost never. The teams on the loss leaderboard were not careless amateurs; they were funded teams with audits and engineers. A bridge concentrates risk that scales with everything that crosses it, and it demands 24/7 monitoring and an incident response plan from day one. If you are a startup, stay single-chain or use a canonical bridge until a bridge is genuinely your product and not a feature. When it is unavoidable, scope it as the highest-risk thing you will ship and resource it accordingly. See our blockchain engineering service for how we scope this, and the glossary for the terms above.