Cross-Chain Bridges — Why They Keep Getting Hacked and What Fixes Actually Work

The cross-chain bridge is one of the most important — and most dangerous — pieces of infrastructure in the blockchain ecosystem.

In 2022 alone, bridge hacks accounted for over $2 billion in losses. The Ronin bridge (Axie Infinity's sidechain) lost $625 million. Wormhole lost $320 million. Nomad lost $190 million. These were not edge cases or exotic attacks on obscure protocols. They were attacks on some of the most heavily used infrastructure in DeFi.

The pattern has continued. Bridge security remains the single largest source of catastrophic losses in the web3 ecosystem. Understanding why requires being precise about what bridges actually do — and why the security problem is genuinely hard.

## What Bridges Actually Do

A blockchain bridge allows assets to move between blockchains that cannot natively communicate. If you hold ETH on Ethereum and want to use a DeFi protocol on Solana or Arbitrum, a bridge is how you get there.

The basic mechanism: you lock (or burn) assets on the source chain, and an equivalent amount is minted (or released) on the destination chain. The bridge must somehow verify that the lock or burn actually happened — without the destination chain having native access to the source chain's state.

This verification problem is where the security vulnerabilities live.

## The Ronin Hack: Social Engineering at Scale

The Ronin bridge attack in March 2022 was, at root, a key management failure. Ronin used a *multisig* (multi-signature) validation model: 9 validator nodes had to sign off on large withdrawals, and an attacker needed control of 5 of them to execute a fraudulent transaction.

The attacker, later attributed by the US Treasury to Lazarus Group (a North Korean state-sponsored hacking organization), obtained private keys for 5 of the 9 validators. Four were compromised through a sophisticated phishing operation against Sky Mavis employees. The fifth — a validator node run by Axie DAO — had been granted temporary signing authority months earlier for a specific operational purpose and never had that authority revoked. The attacker found a 5-of-9 majority in a validator set that its operators believed was more secure.

The technical lesson: multisig security is only as strong as the operational security of each key holder. The numbers were adequate on paper; the practice was not.

## Wormhole: The Verification Bypass

The Wormhole hack in February 2022 was architecturally different — a smart contract vulnerability rather than a key compromise.

Wormhole's design required that cross-chain messages be validated by a set of "guardians" (trusted validators) who sign off on messages. A wrapped token minting operation on Solana required a valid guardian signature. The attacker found a way to spoof a valid guardian signature — exploiting a bug in how Wormhole's Solana program verified the signature, specifically a failure to check the `sysvar` account's legitimacy. The program accepted a fabricated guardian signature as valid, allowing the attacker to mint 120,000 wETH on Solana without depositing equivalent ETH on Ethereum.

Jump Crypto, which had acquired Wormhole, replenished the stolen ETH within hours. But the technical architecture had a fundamental flaw: the signature verification code was not correct.

## Nomad: The Initialization Bug

The Nomad attack in August 2022 was arguably the most embarrassing — not because it was sophisticated, but because it was so simple that hundreds of opportunists could replicate it once the initial exploit was public.

Nomad's optimistic bridge design relied on a "root" value to verify the validity of messages. During an upgrade, the root was initialized to `0x00` — the zero hash — which was inadvertently accepted as a valid root by the verification logic. This meant any message could be validated as legitimate if it referenced the zero root. Once one attacker discovered this, the exploit was so simple that a wave of copycats replicated it within the same block, draining the bridge in what became known as a "free-for-all" hack.

## Trusted vs. Trustless Bridge Architecture

The three hacks illustrate different failure modes, but they share a common structural characteristic: they relied on *trusted components* — human validators, external key holders, or initialized state that could be manipulated.

The fundamental division in bridge architecture is between:

**Trusted bridges** — rely on a set of validators or a multisig to attest to cross-chain state. Faster and cheaper to operate, but security depends on the honesty and operational security of the validators.

**Trustless (or trust-minimized) bridges** — use cryptographic proofs that the destination chain can verify natively, without relying on external validators. Light client bridges implement a simplified version of the source chain's consensus logic on the destination chain, allowing the destination to independently verify that a transaction was finalized.

Light client bridges are significantly more secure in principle. They're also significantly more expensive to operate: running an Ethereum light client on Solana requires executing Ethereum consensus verification logic on Solana's VM, which is computationally intensive and expensive in gas.

## LayerZero and Chainlink CCIP: The Current Approaches

**LayerZero** takes a hybrid approach: it separates the oracle (which delivers the block header) from the relayer (which delivers the transaction proof), requiring both to collude to execute a fraudulent transaction. The security model is "assume that the oracle and relayer don't collude" — stronger than a single-validator model, but still trust-dependent. LayerZero's ultra-light node design keeps costs manageable while providing a modular security model where applications can choose their oracle/relayer combinations.

**Chainlink CCIP** (Cross-Chain Interoperability Protocol) uses Chainlink's existing decentralized oracle network for cross-chain message verification, backed by a "Risk Management Network" of independent nodes that monitor for anomalous activity. The approach leverages Chainlink's existing decentralized validator set but remains fundamentally trust-dependent.

The industry has not yet deployed fully trustless light client bridges at scale for general-purpose asset transfers. The ZK proof compression approaches (using zero-knowledge proofs to verify source chain consensus cheaply on the destination chain) are the most promising direction — projects like Succinct Labs are working on this — but production deployment at scale remains a research frontier.

## Security Audit Limitations

The Nomad hack passed multiple security audits. The Wormhole vulnerability was in production code that had been reviewed. Audits are valuable — they catch many bugs — but they are not sufficient guarantees for bridge security.

The problem is combinatorial: bridge contracts interact with consensus logic, token standards, cryptographic primitives, and operational processes across multiple chains simultaneously. The attack surface is larger than a single-chain DeFi protocol, and auditors reviewing code at a point in time may not anticipate how initialization state changes interact with verification logic in edge cases.

This is worth noting because it suggests that the solution to bridge security is not primarily more audits — it's architectural change toward trust-minimized designs where the security does not depend on human or organizational honesty.

> **Key Takeaway:** Bridge security failures are not primarily caused by insufficient caution or inadequate funding. They reflect a genuine architectural challenge: verifying cross-chain state without shared consensus is hard, and the solutions that make verification cheap (trusted validators, multisigs) are the ones that keep getting exploited. The path forward — light client verification with ZK proof compression — is technically clear. Getting there is the work of the next several years.

Cross-Chain Bridges — Why They Keep Getting Hacked and What Fixes Actually Work

// COMMENTS

ON THIS PAGE