TL;DR

  • It does not move anything: it locks value on one chain and creates a claim on the other, with a messaging layer attesting that the two events correspond. Everything interesting, and everything dangerous, lives in who verifies that attestation.
  • Every canonical failure compromised the attestation layer, keys or verification code, rather than the chains' consensus: five keys for Ronin, two of five for Harmony, a forged proof for BNB Bridge, a signature-check bug for Wormhole, and an accept-anything root for Nomad. Over 1.8 billion dollars was attacked through the middle; the realised losses, after freezes and recoveries, exceeded 1.2 billion.
  • Because it is the one component that must be cheap, fast and flexible, so designers repeatedly chose small committees and complex bespoke code over the expensive option of inheriting chain security, and both choices concentrate failure. The honeypot then guarantees the weakest choice gets found.
  • Two families genuinely change the geometry: trust-minimised verification, light clients and zero-knowledge proofs that make lying as hard as breaking the source chain, and intent-based settlement, which shrinks or removes the pooled honeypot entirely. Everything else improves the odds without changing the shape.
In one block

A cross-chain bridge is an interoperability system that moves value or messages between blockchains that cannot read each other. Typical designs lock assets in a contract on the source chain and mint a representation on the destination, with a verification layer, validators, a multisig, a light client or a proof system, attesting that the lock really happened.

How does a bridge actually move value between chains?

Quick answer

It does not move anything: it locks value on one chain and creates a claim on the other, with a messaging layer attesting that the two events correspond. Everything interesting, and everything dangerous, lives in who verifies that attestation.

No token ever travels. In the dominant lock-and-mint design, you deposit assets into a bridge contract on the source chain; a message crosses to the destination chain; a contract there mints a wrapped representation for you. Coming back, the wrapped token is burned and the original is released from the lock. Variants exist, burn-and-mint for native multichain tokens, and liquidity-network designs where pools on both sides swap rather than wrap, but the invariant holds: some component must convince the destination chain that something really happened on the source chain.

That component is the verification layer, and its design space is a ladder of trust. At the weak end, a single operator or small committee simply signs messages saying "the deposit happened", and the destination contract believes any correctly signed message. In the middle, larger validator sets, threshold schemes and optimistic designs with fraud windows raise the cost of a lie. At the strong end, the destination chain verifies the source chain directly: a light client checks source-chain consensus proofs on-chain, or a zero-knowledge proof attests to source-chain state, so lying requires breaking the source chain itself.

Now add the honeypot. A successful bridge's lock contracts accumulate the largest static pool of value in the ecosystem: at their peaks, individual bridges held billions. So the structure of the problem is a vault whose combined contents dwarf any single protocol, guarded by a mechanism chosen from a menu where the cheap options are weaker than either chain it connects. The economics practically write the attack calendar: strike the attestation layer, mint or release without a real deposit, and the pool pays out.

The chains' consensus layers are almost never the point of failure. In the canonical bridge disasters, the blockchains validated exactly what their rules required, honestly recording what the compromised middle showed them; the operational exception proves the rule, since BNB Smart Chain had to be deliberately paused by its validators to contain the damage.

Figure from Why Cross-Chain Bridges Keep Getting Hacked
Figure 1. Lock-and-mint bridging: the pooled vault and the verification layer between two chains.

What do the biggest bridge hacks have in common?

Quick answer

Every canonical failure compromised the attestation layer, keys or verification code, rather than the chains' consensus: five keys for Ronin, two of five for Harmony, a forged proof for BNB Bridge, a signature-check bug for Wormhole, and an accept-anything root for Nomad. Over 1.8 billion dollars was attacked through the middle; the realised losses, after freezes and recoveries, exceeded 1.2 billion.

Ronin, March 2022, about 624 million dollars, remains the definitive case. The bridge serving the Axie Infinity ecosystem was secured by nine validator keys, any five sufficient. The attackers, later attributed by US authorities to North Korea's Lazarus Group, obtained four keys through a compromised operator and a fifth from a gas-payer arrangement that had never been decommissioned after a favour months earlier. Five signatures later, the pool was gone, and nobody noticed for six days until a user found withdrawals failing. Lessons stacked three deep: a 5-of-9 committee guarded two-thirds of a billion dollars; operational sprawl left a stale key live; and monitoring was so thin that a nine-figure theft aged nearly a week.

Wormhole, February 2022, about 326 million dollars, was a verification bug: the Solana-side contract could be fed a spoofed attestation because a deprecated signature-check path remained callable, letting the attacker mint 120,000 wrapped ETH against no deposit. The backing investor recapitalised the hole within days, which saved users and set an uncomfortable precedent about how such holes get filled.

Nomad, August 2022, about 190 million dollars, is the farce in the genre: an initialisation left a zero value marked as a trusted root, so practically any message replayed with edited recipient fields would pass. Once the first attacker demonstrated it, hundreds of copycats simply modified the calldata, a crowd-sourced looting of a vault whose door verified nothing.

Harmony Horizon, June 2022, about 100 million dollars: a 2-of-5 multisig, two compromised keys, no further commentary required. BNB Bridge, October 2022: a flaw in IAVL Merkle proof verification allowed a forged proof of a deposit that never occurred, and about 570 million dollars in BNB was minted against it. The response separates attempted theft from realised loss: validators synchronously paused BNB Smart Chain for around five hours, most of the minted value was frozen on-chain and later dealt with, and BNB Chain put the unrecovered amount at over 100 million dollars. The pause saved most of the money and made a second point for free: a chain that can be halted by coordinated validators is telling you something about where its decentralisation actually sits.

Chainalysis measured the era: roughly 2 billion dollars attacked across bridges in 2022, the majority of stolen-funds activity that year, with nation-state actors responsible for the largest share. The pattern in one sentence: consensus held, middles fell, and what was saved was saved by freezes rather than by the bridges themselves.

Figure from Why Cross-Chain Bridges Keep Getting Hacked
Figure 2. The five canonical bridge failures and the layer each one broke. BNB Bridge value is the minted amount; most was frozen after a coordinated pause.

Why is the verification layer structurally the weakest link?

Quick answer

Because it is the one component that must be cheap, fast and flexible, so designers repeatedly chose small committees and complex bespoke code over the expensive option of inheriting chain security, and both choices concentrate failure. The honeypot then guarantees the weakest choice gets found.

Consider what the verification layer is asked to do: observe one chain, convince another, quickly, for arbitrary assets, across heterogeneous consensus designs, upgradeably, at low cost. Full light-client verification, running one chain's consensus rules inside another, was for years computationally expensive on-chain, especially toward chains with heavy signature loads. So the industry reached for committees: a set of known validators watches the source chain and signs attestations. Committees are fast and cheap, can support multiple chains wherever the verification and signature scheme is implemented, and are secured by their signing threshold together with their verifier code and operational design; in the canonical failures the binding constraint was simply the number of keys an attacker had to gather, which history prices at somewhere between two and five.

The committee inherits every classic key-management failure: keys on internet-connected machines, social engineering of operators, stale arrangements never revoked, insufficient signer diversity so one compromised organisation yields multiple keys. These are the same failure modes this cluster's institutional custody article treats as solved problems, and bridges repeatedly shipped without the solutions. Where verification is code instead of keys, bespoke proof-checking contracts, the complexity is severe, the attack surface novel, and, as Wormhole and BNB Bridge showed, a single overlooked path equals the whole pool.

Governance adds a quieter single point of failure: most bridges are upgradeable, so whoever controls the upgrade keys controls, transitively, every locked asset. An impeccable verification design behind a 2-of-3 admin multisig is a 2-of-3 bridge wearing a costume.

And the honeypot dynamics close the loop. Value concentrates in the winning bridges; the winning bridges become the highest-value static targets in crypto; the most capable adversaries, including state-sponsored groups with patience and social-engineering depth, allocate accordingly. A DeFi protocol's exploit pays out its own TVL; a bridge exploit pays out everyone's. The pool is the prize, and the pool is exactly what the dominant architecture requires.

This is the structural sense of the article's title: bridges keep getting hacked because the dominant design concentrates maximal value behind minimal verification, and every incremental patch leaves that geometry intact.

Do newer designs actually fix the problem?

Quick answer

Two families genuinely change the geometry: trust-minimised verification, light clients and zero-knowledge proofs that make lying as hard as breaking the source chain, and intent-based settlement, which shrinks or removes the pooled honeypot entirely. Everything else improves the odds without changing the shape.

The verification family attacks the "minimal verification" half. A light-client bridge runs the source chain's consensus verification inside a destination-chain contract, so an attestation is checked against real consensus data rather than a committee's word; the IBC protocol connecting Cosmos-family chains is the longest-running production example. Zero-knowledge proofs extend the idea to chains where on-chain verification was previously too heavy: a succinct proof that the source chain finalised a given state can be verified cheaply. These designs remove the committee, and they do not remove risk wholesale: the verifier contract can carry bugs, upgrade and governance keys can override it, and data availability, finality assumptions and liveness remain live engineering problems. What they change is the class of failure required, from stealing a handful of keys to breaking verification code or governance, which is a genuinely higher bar rather than an absolute one.

The intent family attacks the "maximal value" half. In intent-based designs, a user expresses an outcome, asset X on chain B, and competing solvers front their own liquidity on the destination within seconds, then settle against the user's source-chain deposit through the system's verification path. The user's exposure drops to a single fill window rather than a perpetual claim on a giant pool; the solver, a professional taking a professional risk, carries the settlement exposure and prices it. Standards such as ERC-7683 formalise the pattern across EVM chains. The design does not abolish verification, settlement still needs truth, and settlement layers can still concentrate exposure; what it removes, in designs where user funds are genuinely never pooled, is the resting honeypot that made Ronin-scale single events possible. The claim to verify for any specific system is exactly that: where value sits, for how long, and behind what.

The composite picture since 2022 supports cautious optimism: bridge losses have fallen from their dominance of theft statistics, through some mix of hardened committees, monitoring, architectural migration and attackers finding softer targets in operational key compromise. Optimism, with a caveat the incident record insists on: several "next-generation" bridges of 2021 also described themselves as having solved bridge security.

For a user, the ladder compresses into questions. What verifies a crossing: committee, optimistic window, light client, proof? How many keys, held by whom, is the committee, and who can upgrade the contracts behind what delay? Is value pooled, and how much, or filled by solvers? How long has the design run, at what value, through what audits? And, always available: does this crossing need to happen at all, or is the asset's native chain, or a centralised venue's internal transfer with its own distinct risks, the smaller total exposure? The pillar's principle applies verbatim: every design relocates risk rather than removing it, and the skill is knowing where yours went.

Frequently asked questions

Are crypto bridges safe to use?

Safety varies by architecture more than by brand. A crossing verified by a light client or validity proof removes the external committee, though it still carries verifier-implementation, upgrade, data-availability and liveness risk; a crossing verified by a small committee is as safe as a handful of keys; an intent-based fill limits your exposure to a settlement window. Check what verifies the crossing, who can upgrade it, and how much value rests in the pool, and keep any single crossing small relative to what you can afford to have stranded or lost.

If both blockchains are secure, how can the bridge be hacked?

Because the bridge is a third system standing between them. Each chain honestly executes the instructions it is shown; the bridge's verification layer is what decides which instructions get shown. Compromise that layer, five keys at Ronin, a proof bug at BNB Bridge, and both chains faithfully record the theft. The chains' security was never the question.

What was the single most common root cause in the big bridge hacks?

Compromised or insufficient attestation: either too few keys (Ronin's five of nine, Harmony's two of five) or broken verification code that accepted messages it should have rejected (Wormhole, Nomad, BNB Bridge). Over 1.8 billion dollars across the five canonical cases was attacked through those two doors, with realised losses above 1.2 billion after freezes, while the chains' consensus rules operated as designed.

Do wrapped tokens carry bridge risk even after I receive them?

Yes. A wrapped token is a claim on assets locked in the bridge; if the lock is drained, the claim can lose backing regardless of when you crossed. Holding a bridge's wrapped assets is an ongoing credit exposure to that bridge's security, which is worth remembering when a wrapped balance sits untouched for months.

Is it safer to move funds through an exchange instead of a bridge?

It exchanges one risk for another: a centralised venue's custody, solvency and account security replace the bridge's verification layer, and this academy's articles on exchange account security and institutional custody cover that side. For large transfers, some professionals prefer venue rails precisely to avoid pooled bridge exposure; the honest framing is choosing which failure modes you are equipped to survive, never a free lunch.

Sources and further reading

Key references for this article, current as of July 2026. Volatile figures are re-checked at each quarterly review.

Quick quiz: did it stick?

A few questions to check the fundamentals landed. Answers with explanations follow, and nobody is grading you except your future portfolio.

1/5 question
What does a lock-and-mint bridge actually transfer between chains?

Was this helpful?