Anatomy of a bridge hack: why crypto's largest losses keep coming from cross-chain

In the entire catalogue of crypto security incidents, no category comes close to bridges. The single largest exchange breach in history is Bybit at $1.46B, and the largest DeFi protocol breach is Euler at $197M. The largest bridge breaches are Ronin at $625M, Poly Network at $611M, BNB Bridge at $586M, Wormhole at $326M, and Multichain at $231M. Adding Nomad, Harmony Horizon, Qubit, Heco, and Orbit Chain takes the total over $3 billion. Cross-chain is, by a wide margin, the most expensive design pattern in the history of the industry.

This is not a coincidence. Bridges concentrate two properties that, taken together, are catastrophic: they hold enormous amounts of value, and they require a non-blockchain consensus mechanism to validate cross-chain messages. Every bridge in production is, in effect, a custodian — and a custodian whose security is bottlenecked by something other than the blockchain it serves.

This post is a structural account of how bridge breaches happen. The aim is not to catalog every incident, but to make the four failure modes legible enough that you can predict the next one. They are: signer compromise, message-verification bugs, trusted-root corruption, and mint/burn invariant breaks.

The architecture, briefly

Almost every bridge in production maps to roughly the same architecture:

1. Source chain: a vault contract that holds the original asset (USDC on Ethereum, say).
2. Off-chain validator set: a group of nodes — multi-sig, MPC, or proof-system operators — that watch the vault and produce attestations.
3. Destination chain: a mint contract that accepts the attestation and issues a wrapped asset (USDC.e on Avalanche, say).

The reverse path goes through the same machinery, with the wrapped asset burned on the destination and the original released on the source.

The trust assumption is the validator set. If they collude, fail, or get compromised, the bridge fails. Every architectural innovation in the bridge space since 2021 has been an attempt to weaken or generalize this trust assumption — but no production bridge has ever been able to eliminate it. The four failure modes below are the four ways the assumption has actually broken.

Failure mode 1: signer compromise

This is the simplest and the most expensive. The bridge requires N-of-M signatures; an attacker compromises N or more signers; the attacker signs whatever they want, mints whatever they want, and walks away.

The canonical case is Ronin Network. The Sky Mavis-operated bridge for Axie Infinity required 5-of-9 signatures from a validator set that included four Sky Mavis nodes and one allow-listed third party (Axie DAO). The attacker, attributed to North Korea's Lazarus Group, compromised four Sky Mavis signers through a spear-phishing attack on a Sky Mavis employee — and obtained the Axie DAO signature through a leftover whitelist permission that Sky Mavis had never revoked. The bridge dutifully accepted the 5-of-9 signed withdrawal and minted 173,600 ETH and 25.5M USDC to the attacker. Loss: $625M.

Harmony's Horizon bridge was 2-of-5; both required signers were compromised. BNB Chain is a partial case — the validator set wasn't compromised, but a bug in the IAVL proof verifier let the attacker forge a valid-looking message without controlling any signers.

The defensive lesson is brutally direct: the security of the bridge is the security of the signing keys, full stop. Every operational practice that protects a signing key — air-gapped machines, hardware security modules, blind-signing protections, rotation policies, geographic separation — applies. Most bridges that have been compromised in this category were running multi-sig setups that, by the time the incident happened, had had stale signer lists, single-machine signing setups, or social-engineering surface areas that a competent attacker could find.

This is also the category that has shifted most. The Bybit incident is structurally a signer-compromise breach, but the technique is new: the attacker compromised the signing UI (Safe{Wallet}) rather than the signing keys. The signers signed exactly what they were shown. They were just shown the wrong thing. As bridges harden their key custody, expect more attacks at the UI/tooling layer, not the cryptography layer.

Failure mode 2: message-verification bugs

In this category, the bridge contract accepts a forged proof. The cryptography is sound; the implementation that checks the cryptography is not.

The cleanest example is Wormhole. The bridge accepted "verified" guardian payloads — but the function the contract used to verify them, verify_signatures, was a Solana program that itself relied on the caller to do the verification. The attacker called the function with an unverified payload, the contract trusted that the verification had been done because the call succeeded, and the attacker minted 120,000 wETH on Solana out of thin air. Loss: $326M.

BNB Chain was a similar shape at the IAVL proof layer: an attacker forged a Merkle proof by exploiting how the verifier handled non-existent leaves. The proof was technically valid by the verifier's rules; it just shouldn't have been.

The defensive question for this category is "can a non-cryptographer reason about whether your verifier is actually verifying?" Most bridges of this type are implementing custom proof formats — light-client headers, Merkle proofs, threshold signatures over non-standard curves — and the implementations are sufficiently complex that ordinary auditing struggles to find subtle off-by-one or "trusted to validate but didn't" bugs. Formal verification helps here more than anywhere else in the architecture. The cost is that formal verification of a non-trivial verifier is itself a multi-month project, and most bridges have shipped before the verification could finish.

Failure mode 3: trusted-root corruption

This is the Nomad bridge case, and arguably the most embarrassing breach in DeFi history. The bridge stored a "trusted root" — a Merkle root representing the state of approved cross-chain messages. An initialization routine set the trusted root to 0x00, intending it to be a placeholder before the first real root was committed.

Because the bridge accepted any proof whose root was either the trusted root or a previously-confirmed root, and because 0x00 was now in the trusted-root set, every message hashed to a root of 0x00 (which any uninitialized message did) was valid. The first attacker noticed and drained a few million dollars. The transaction was public. Within four hours, a crowd of unrelated addresses copy-pasted the exploit transaction, replacing only the recipient, and drained the bridge of $190M in what became known as the "first decentralized robbery."

The structural lesson is narrower than it looks. The bug was specifically an initialization-vs-storage-default conflation: the contract treated an unset value as a valid value. The general lesson — never let an uninitialized slot represent "trusted" — sounds obvious in retrospect, but is exactly the kind of bug that survives audit because the test suite doesn't include "what happens when we deploy and don't initialize before someone deposits."

Failure mode 4: mint/burn invariant breaks

The fourth category is logic bugs in the mint or burn path that let an attacker either mint without a corresponding source-chain deposit, or burn less than the destination chain credited them with.

Qubit is a clear case. The QBridge accepted a "deposit" of 0 ETH on Ethereum, didn't reject the zero-value transfer, and credited the attacker with valid claim tokens on BSC. The attacker repeated the call and minted $80M in xETH. The bug was a missing check that the source-chain deposit was actually non-zero.

Multichain was a different shape: the MPC node that controlled the bridge's vaults was, by all available evidence, compromised in such a way that funds were moved out without the bridge contracts emitting any anomalous events. The exact cause has never been publicly confirmed; the CEO of the project was arrested in China shortly before the funds disappeared. Whether this is a signer compromise, a backdoor, or something else entirely is unresolved.

These breaches are the kind that the protocol cannot easily recover from, because the bridge's vault is now provably insolvent against the destination-chain supply. Every wrapped asset on the destination chain is, after the attack, a partial claim on a smaller-than-expected pool. The market discovers this within minutes; the wrapped asset depegs; users with positions in the wrapped asset realize permanent loss.

Why the pattern repeats

The thing that's notable about the bridge catalogue, when you read it end to end, is how few of these failures were novel. Signer compromise is well-understood. Message-verification bugs are a known auditing category. Mint/burn invariant breaks are exactly the kind of bug a property-based test should catch. The Nomad initialization bug is the kind of thing that every secure-deployment guide warns against in chapter one.

The reason bridges keep producing nine- and ten-figure losses is that they sit at the intersection of every hard problem in the field — cross-chain consensus, key custody, proof systems, multi-team coordination — while holding the kind of value that justifies any attacker spending months or years finding a way in. Lazarus alone has stolen north of $2 billion from bridges and exchanges; they have institutional, state-level patience and capability. Any architecture in this design space that hasn't been attacked yet has not been attacked yet.

If you're building one, the directly-actionable lessons are well-rehearsed:

• Treat signing infrastructure as the most-attacked component, because it is. Air-gap, blind-sign-protect, separate dev from sign, rotate, enforce hardware wallets that show the actual transaction.
• Verify your verifier. Formal verification is expensive; auditing a custom proof system without it is so risky that the industry's largest losses are in this category.
• Bound the blast radius. Per-block mint caps, rate limits on outflows, and circuit breakers that pause the bridge on anomalous activity all reduce the cost of an exploit even when one happens.
• Be honest with users about the trust model. Whatever the front-end says, the bridge is a multi-sig or a validator set. Users who don't know that are taking a different bet than the one they think they're taking.

If you're using bridges as a user, the lesson is shorter: don't keep more value bridged than you can afford to lose, and prefer native-asset venues over wrapped-asset venues for any position you're going to hold for more than a trade. The archive of bridge losses is the most efficient way to internalize why.