Why Cross-Chain Bridges Keep Getting Hacked

A bridge works by locking assets on one chain and minting equivalent representations on another. To release the locked assets, the bridge must verify that the representations on the destination chain were burned.

This verification requires trust. Specifically, it requires that someone (or some system) watching both chains can attest that the burn happened and authorize the release. This is the security bottleneck — and it is typically a multisig wallet controlled by a small number of keys.

The Ronin bridge was controlled by a 5-of-9 multisig. Sky Mavis (the Axie Infinity developer) controlled 4 keys, and a single entity called the Axie DAO controlled a fifth key that had been given to Sky Mavis for emergency use and never revoked. An attacker compromised Sky Mavis keys and the Axie DAO key in a single social engineering attack. That is $625M gone from a 5-of-9 that was effectively a 5-of-5 with centralized key management.

Nomad ($190M) failed differently — a smart contract bug in the message verification logic. An update to the contract introduced a flaw where any message could be proven valid. One attacker found this, other actors saw the exploit transactions in the mempool and copied them to extract more funds. It became a chaotic free-for-all rather than a single coordinated attack.

Wormhole ($320M) was a Solana-specific smart contract vulnerability. The bridge contract failed to verify a guardian signature correctly due to a Solana SDK API change. An attacker minted 120,000 wETH on Solana without depositing the equivalent ETH — effectively counterfeiting $320M of bridged assets.

These are three completely different attack vectors — social engineering of key holders, copy-paste exploit after contract bug discovery, and cryptographic verification failure — all resulting in nine-figure losses. The common thread is that bridges require external trust at the verification layer, and every trust assumption is an attack surface.

The most secure bridge architectures increase the cost and difficulty of compromising the verification layer.

Decentralized validator sets: instead of a 5-of-9 multisig, verification is performed by a large, economically staked validator set where compromising a majority requires attacking many independent parties with significant financial skin in the game. This is the model Axelar and LayerZero use.

Light client verification: instead of relying on off-chain validators, the destination chain runs an on-chain light client of the source chain and verifies state transitions cryptographically. This is the approach IBC (Inter-Blockchain Communication) uses in the Cosmos ecosystem and what we built into L1X's cross-chain architecture. No external validators to compromise — the verification is embedded in the protocol itself.

ZK bridges: use zero-knowledge proofs to verify source chain state transitions on the destination chain without running a full light client. zkBridge, Succinct Labs, and others are building this. It is computationally expensive today but eliminates the external trust assumption entirely.

For bridges that must rely on validator sets or multisigs in the near term, the minimum risk mitigation measures are: large multisig sets (at least 7-of-11 or larger) with diverse key holders across different organizations and geographies, hardware security modules for key storage, regular key rotation with documented procedures, and circuit breakers that pause the bridge if unusual outflow patterns are detected.

Value limits matter enormously. A bridge that caps daily outflow at $10M cannot lose $600M in a single attack. Rate limiting and withdrawal delays (allowing time for off-chain monitoring to catch anomalies) should be standard for all bridges holding significant value.

Formal verification of the bridge smart contract logic — using tools like Certora Prover or Dafny — is now feasible for bridge contracts and should be considered for high-value bridges.

If you are building a product that requires cross-chain functionality, the bridge you use is a critical dependency risk. Before integrating any bridge, understand: who controls the verification layer, what the multisig configuration is, whether there is a bug bounty program, whether there have been audits (and by whom), and what the TVL and historical security record looks like.

For new protocols, consider whether cross-chain is actually required or whether it can be deferred until the security landscape matures. The protocols that have avoided bridge exploits are mostly the ones that have not built bridges.

For infrastructure projects where cross-chain is the core value proposition, investing in a protocol-level security model (light client verification or ZK bridges) rather than validator multisigs is worth the additional development cost. The alternative is building a product where a single social engineering attack can destroy user trust permanently.