Why Crypto Bridges Get Hacked

More value has been lost to bridge exploits than to any other category of crypto hack. Ronin ($625M), Wormhole ($320M), Nomad ($190M), Harmony Horizon ($100M) — over $2.5 billion in a single 18-month stretch from early 2022 to mid-2023. And unlike exchange hacks, these weren't mostly phishing or social engineering. They were structural vulnerabilities built into how bridges work.

The pattern isn't bad luck. It reflects something specific about what bridges have to do.

What a Bridge Actually Does

When you "send" assets from Ethereum to Arbitrum, or from Ethereum to Solana, you're not really moving anything. Each blockchain is a closed system — Ethereum doesn't natively know what's happening on Solana, and Solana doesn't natively know what's happening on Ethereum.

A bridge solves this coordination problem by standing in the middle. The basic mechanic: you lock your asset on the source chain (it gets deposited into a smart contract vault), and the bridge mints a synthetic representation of that asset on the destination chain. To go back, you burn the synthetic, and the bridge releases the original.

This means bridges are custodians. At any given moment, they're holding billions of dollars in locked assets on one side, with only software logic deciding when those assets can move. That's the attack surface.

Where the Vulnerabilities Come From

Bridge exploits cluster around three distinct failure modes.

Smart contract logic errors. Bridges are large, complex systems. They process incoming messages from other chains, verify that those messages are legitimate, and execute transfers based on that verification. Every verification step is code, and code can be wrong.

The Wormhole hack is the clearest example. Wormhole is a bridge between Ethereum and Solana. Its Solana-side contract required a set of "guardian" signatures before minting wrapped tokens. An attacker found a flaw: the contract was calling a deprecated Solana system instruction that didn't actually verify signatures the way it appeared to. The attacker spoofed a valid guardian set, tricked the contract into minting 120,000 wETH it had no right to mint, and withdrew the corresponding ETH from the Ethereum side. $320 million, one transaction.

The Nomad exploit was different in character but similar in category. During a contract upgrade, a developer initialized a critical parameter incorrectly — setting a "trusted root" to zero. This meant the bridge would treat any message as valid, regardless of origin. When someone noticed, it didn't stay a sophisticated exploit for long. Anyone could copy the transaction, change the recipient address, and receive funds. It became a free-for-all.

Validator or key compromise. Many bridges use a federated model: a set of trusted parties (validators, guardians, or signers) must attest that a lock happened on the source chain before the destination chain will mint. This simplifies the technical problem but concentrates trust.

Ronin, the bridge for Axie Infinity's game, used nine validators with a 5-of-9 threshold. An attacker — later attributed to North Korea's Lazarus Group — compromised five private keys. Four via an initial network breach; one via a separate key held by the Axie DAO that had been handed off to Sky Mavis months earlier but never revoked. With five keys, the attacker could authorize withdrawals unilaterally. $625 million. The breach went undetected for six days.

The core vulnerability: the security of the bridge was exactly as strong as the weakest combination of private keys. Not the cryptography — the operational security of the people holding the keys.

Cross-chain oracle problem. This is the underlying issue that makes all of the above harder to solve. Blockchains are isolated systems. Chain A cannot natively verify what happened on Chain B. Bridges have to introduce some trust mechanism to bridge that gap — whether it's a multisig, a set of watchers, or an optimistic assumption — and every trust mechanism is an attack target.

The clearest framing: bridge security is almost always weaker than the security of the chains it connects.

Why the Dollar Amounts Are So Large

Bridge vaults aggregate value. When a bridge has $2 billion in locked ETH, that's a single contract address. Finding one flaw means access to the entire pool. Compare that to attacking individual wallets — same effort, much smaller payout per target.

There's also an asymmetry in audit difficulty. Multi-chain logic is genuinely harder to reason about than single-chain logic. Code running on two different virtual machines, coordinating via message-passing, with different timing assumptions on each side — that's a large attack surface, and auditors miss things.

What's Changing

The industry has moved in three directions since the 2022 wave.

Native/canonical bridges. For L2s like Arbitrum, Optimism, and Base, the canonical bridge is part of the rollup protocol itself. Trust assumptions derive from Ethereum's security, not a separate validator set. These bridges are slower (7-day withdrawal windows for optimistic rollups) and less convenient, but structurally more secure. Most large-scale bridge exploits have hit third-party bridges, not canonical rollup bridges.

ZK-based cross-chain messaging. The most promising technical direction is using zero-knowledge proofs to let one chain cryptographically verify the state of another. Instead of trusting validators, the destination chain verifies a succinct proof that a specific event happened on the source chain. Projects including Succinct, zkBridge, and Polymer are building this infrastructure. It's still early — the proofs are expensive to generate, and the systems haven't been battle-tested at scale — but it's the direction with the best theoretical security properties.

Longer audit cycles and formal verification. More bridge teams are investing in formal verification (mathematically proving correctness of contract logic) before deployment. Not universal, and not a guarantee, but the standard has risen since 2022.

What hasn't changed: bridges built on multisig validator sets remain common, remain valuable targets, and remain as secure as the operational security practices of the signers.

Confirmation and Invalidation

Confirmation that ZK bridges are the right direction: Sustained, exploit-free track records from ZK-based bridge deployments over 12–24 months. Declining dominance of multisig-based bridges in total value locked.

Invalidation of the ZK approach: A flaw in a ZK proof system itself — the prover or verifier — leading to a large exploit. That would be a significant setback for the whole technical direction. Or continued large-scale exploits despite ZK adoption, suggesting the attack surface lies elsewhere.

Timing

Now: Bridge risk is live and ongoing. Multisig and validator-based bridges remain the dominant design. Before using any bridge, the validator set, multisig threshold, and audit history are the load-bearing questions.

Next: ZK-based messaging systems moving from testnet to mainnet (12–24 months). The canonical L2 bridge model is already the default for Ethereum rollups.

Later: Cross-chain communication secured at the protocol layer rather than via bridge middleware. Still multi-year out, and requires coordination across many independent chains.

Boundary

This covers why bridges are structurally vulnerable — the mechanism, the failure modes, and the historical record. It doesn't cover the security properties of any specific bridge in use today, nor does it constitute advice about which bridges to use or avoid.

The bridge design space is evolving. The historical pattern — complex multi-chain code holding large pools of assets — remains the clearest explanation for why the losses have been so large.