How a bridge gets compromised
A cross-chain bridge is a vault on one chain with a mint authority on another. The vault holds value. The mint authority creates derivative value backed by the vault. Every bridge exploit ends one of two ways: the vault gets drained without burning the derivatives, or the mint authority gets compromised and the derivatives no longer correspond to the vault.
Over two and a half billion dollars has been lost to bridge exploits since 2021. The pattern catalog below is what those exploits had in common.
The four bridge architectures
Bridges differ in how the mint authority is established and who can change it.
Lock-and-mint with a trusted validator set. A multisig or threshold-signature validator set signs that funds were locked on chain A; the bridge contract on chain B mints the derivative. The trust is in the validator set. Ronin Bridge was this architecture. Harmony was this architecture.
Lock-and-mint with a light-client proof. Chain B verifies a Merkle proof against chain A's block headers, with no trusted intermediary. Mathematically stronger; harder to implement; the verification logic itself can be wrong. Nomad was this architecture, and the bug was in the verification logic.
Burn-and-mint between chains where both sides have authority. Each side trusts the other's bridge contract to verify its own state. Equivalent to lock-and-mint with mutual trust. Wormhole was approximately this architecture.
Atomic swaps and generalized message passing. LayerZero uses an oracle-plus-relayer trust model where security holds if the oracle and the relayer are genuinely independent. HTLC-based atomic swaps are trustless under timeout assumptions. Cosmos IBC uses light-client verification between chains. The category recombines the validator-set problem under different names where the trust model is not actually trustless.
Where each architecture leaks
Validator set compromise is the single largest category. Ronin Bridge lost roughly $625M when an attacker controlled five of nine validator keys, four through a vulnerability in the Sky Mavis software and one through a previously granted signing right that had not been revoked. Harmony lost roughly $100M when an attacker controlled two of five multisig keys. The pattern is consistent: a validator set of size N with threshold M < N where the attacker can compromise M keys.
Signature verification bugs. Wormhole lost roughly $325M when its bridge contract accepted an attacker-signed message because the signature-verification code path could be tricked into not actually verifying. The bug was in the implementation, not the design.
Proof-initialization replay. Nomad lost roughly $190M when a routine upgrade set the trusted Merkle root to a value that allowed any prior message to verify. The bug was a single deployment-time line. The exploit was open for anyone with eyes on it; over forty unrelated wallets participated.
Fork and reorganization attacks. A bridge that finalizes mints based on chain A's state assumes chain A is final. If chain A reorganizes, the mint exists without a corresponding lock. Few bridges enforce more than a fixed confirmation count. The right confirmation count depends on the chain.
Fee economics. Some bridges price withdrawals against assumptions about validator behavior under congestion. An attacker can exhaust validator capital and prevent honest withdrawals; the funds remain locked. This is less an exploit than a denial of service that converts into a withdrawal-rate exploit.
Case anatomies
The case literature is the reference.
Ronin Bridge (March 2022, ~$625M). Validator threshold five of nine. Attacker compromised a Sky Mavis RPC node that had been granted a temporary signing role; the role had not been revoked. The attacker forged withdrawal messages and signed them with five valid keys.
Wormhole (February 2022, ~$325M). A signature-verification bug in the Solana program failed to validate the sysvar account used to confirm guardian signatures. The attacker passed a fake guardian set to a function that accepted unsigned set-update messages. The fix was small; the impact was the second-largest bridge exploit on record.
Nomad (August 2022, ~$190M). An upgrade set the trusted root to a sentinel value the contract treated as "valid for any message." Anyone who noticed could call process() with arbitrary payload and mint to themselves. The exploit was visible on-chain; one wallet drained funds first; many others joined.
Harmony (June 2022, ~$100M). Two of five multisig keys compromised; the public post-mortem stops short of confirming the vector.
Multichain (July 2023, ~$126M). The CEO held the keys. The CEO was arrested. The funds moved. The post-mortem was thin; the trust model was opaque before the exploit and remained opaque after.
Ronin re-exploit (August 2024, ~$12M, returned). Two years after the headline incident, an exploiter took roughly twelve million dollars through a separate validator weakness; the funds were returned after negotiation. The pattern: a bridge that shipped a fix is not a bridge that fixed its trust model.
Defensive design patterns
A bridge that wants to survive the patterns above implements a small set of defenses.
Validator-set threshold raised toward N, with key custody distributed across independent operators and HSM-backed signing. A 5-of-9 with all five keys in one company is a 1-of-1 in practice.
Light-client proofs over trusted multisigs, where the receiving chain supports them. The math is harder to attack than the operators.
Withdrawal time-locks on the receiving side, with a public dispute window. The cost is a few hours of latency on large transfers; the benefit is that an exploit-in-progress hits a wall.
Asymmetric mint authority with different signing schemes for mint and burn. An attacker who compromises the mint key cannot also forge the burn proof.
Per-chain emission caps and circuit breakers. A bridge that emits one hundred percent of its TVL into a sister chain in a single block should pause itself.
Cryptographic verification over validator sets. Recent designs (Succinct, Polyhedra) use ZK light clients to verify cross-chain state proofs cryptographically rather than relying on an off-chain validator set. The math is harder to attack than the operators. Adoption is uneven; the direction is established.
What we audit on a bridge
We audit the validator set explicitly: how it was bootstrapped, who holds the keys, how a key is rotated, what happens when one is lost. We pressure-test the verification logic for every message path. We model fork and reorg scenarios. We map the mint authority and check whether emission is bounded.
We treat a bridge audit as an architecture audit first, a code audit second. The largest losses came from architecture decisions that the code faithfully implemented.
The deliverable is the audit report described in our methodology.
What clean means
A clean bridge audit means the validator set and the verification logic are sound under the threat model the operators stated. It does not mean the operators will not lose the keys. We say that explicitly.