Anatomy of cross-chain bridge exploits

A cross-chain bridge has to convince one blockchain that something happened on another. Neither chain can observe the other directly, so every bridge relies on a verification step: a set of signers, a light client, an optimistic challenge period or a cryptographic proof. Whatever value the bridge holds is protected by that step and by the code around it.

Bridge incidents have been among the largest losses in the industry. This analysis groups well-documented public incidents by which part of the verification path failed, using the projects’ own reports and published technical analyses, and draws out what each failure class implies for design and review. The incident details below are summaries of those sources, which are listed in the bibliography.

Why bridges concentrate risk

In the common lock-and-mint design, assets deposited on a source chain are held in escrow, and a wrapped representation is minted on the destination chain. The escrow accumulates the value of every outstanding wrapped token, so a single flaw can release all of it. Wrapped tokens are also used as collateral elsewhere, which spreads the consequences of a bridge failure to protocols that never interacted with the bridge directly.

The ethereum.org overview of bridges describes the basic trade-off: trusted bridges depend on an external set of operators, while trust-minimised bridges depend on the correctness of on-chain verification of the other chain’s consensus. Each moves the risk rather than removing it.

A reference model of a bridge

The model has five stages: a deposit on the source chain, observation and attestation off-chain, verification of the attestation on the destination chain, decoding and execution of the message, and release of the asset. Failure can occur at any of them. The four failure classes below cover the incidents we examine; they are not an exhaustive taxonomy.

Failure class 1: the keys

When verification consists of checking that a threshold of known signers approved a message, the bridge is exactly as secure as the keys. Two incidents illustrate how that threshold has been met by an attacker.

Ronin (March 2022). According to Ronin’s community alert, the bridge required five of nine validator signatures. The attacker obtained five validator private keys: four belonging to Sky Mavis and one to the Axie DAO validator. The Axie DAO had allowlisted Sky Mavis to sign on its behalf in November 2021; the arrangement was discontinued in December 2021 but the access was never revoked. The withdrawals were valid by the bridge’s rules, and the breach was discovered six days later. The threshold was subsequently raised to eight of nine.

Harmony Horizon (June 2022). Published analyses report that the bridge’s multisig required only two of five signatures, and that the attacker obtained and decrypted two keys despite passphrase and key-management protections. The project later raised the threshold to four of five.

The common lessons are about independence. A threshold of five of nine provides little protection if one organisation can produce five signatures, and a threshold of two of five is low however the keys are held.

Failure class 2: verification code

When the keys are sound, the code that checks their signatures, or checks a proof, becomes the target.

Wormhole (February 2022). Wormhole’s incident report describes how the attacker bypassed guardian signature verification in the Solana program: its verify_signatures function did not assert that the account supplied as the instructions sysvar really was that sysvar, so the attacker passed a crafted look-alike. With verification bypassed, the attacker had the program accept a message authorising the mint of 120,000 wrapped ether on Solana without a corresponding deposit. The failure is an instance of a Solana-specific class, missing account address checks, discussed in our Solana primer.

BSC Token Hub (October 2022). Technical analyses of the incident describe a flaw in the IAVL Merkle proof verification used by the bridge between BNB Beacon Chain and BNB Smart Chain: the verifier did not include one attribute of a path node when recomputing the root, so a proof could be modified to carry a forged payload and still verify against a legitimate root. The attacker, who first registered as a relayer, used forged proofs to have the bridge release two million BNB.

Verification code is cryptographic plumbing written in an ordinary programming language, and it fails in ordinary ways: an unchecked account, an ignored field, a library function used outside its assumptions.

Failure class 3: configuration and upgrades

Nomad (August 2022). Nomad’s root cause analysis attributes the incident to an implementation bug that caused the Replica contract to fail to authenticate messages properly. The widely reported mechanism is that an upgrade initialised the contract so that the zero hash was treated as a trusted root; because messages that had never been proven also mapped to the zero value, any message passed the check. Once the first exploit transaction was public, many other addresses copied it with their own recipient.

The lesson is that verification is not only code but state. A correct verifier initialised with the wrong trusted root, validator set or threshold is an incorrect verifier. Upgrades and initialisation transactions deserve the same review as the contracts they configure.

Failure class 4: message handling

After verification, a handler decodes the message and acts on it. Errors here include accepting the same message twice, failing to bind a message to the destination chain or contract, decoding fields ambiguously, and letting a message call arbitrary targets with the bridge’s privileges. These failures do not require breaking the verification layer at all. Replay and domain binding are covered in detail in signature replay across EVM chains, and the cross-chain message replay case study walks through a worked example.

Five incidents side by side

One control appears in every row: limiting how much can leave the bridge in a given period. It does not prevent any of the failures, but it caps the damage of all of them.

Containment: limiting what one failure can take

Because every verification design has failed somewhere, mature bridges add defences that assume verification might be wrong. Rate limits bound outflow per asset and per window. Large transfers can be delayed and held for review. Independent watchers can compare messages on the destination chain with events on the source chain and pause the bridge if a message has no matching deposit. Each of these turns a total loss into a partial one, and gives a human time to act.

1// Illustrative outflow limiter for the release side of a bridge.2// A failure upstream (keys, verification, configuration) can still release funds,3// but only up to a bounded amount per window, which buys time to respond.4contract ReleaseLimiter {5    uint256 public immutable capacity;      // max tokens released per window6    uint256 public immutable refillPerSec;  // capacity / window length7    uint256 public available;8    uint64  public lastUpdate;9 10    function _consume(uint256 amount) internal {11        uint256 elapsed = block.timestamp - lastUpdate;12        available = Math.min(capacity, available + elapsed * refillPerSec);13        lastUpdate = uint64(block.timestamp);14        if (amount > available) revert RateLimited(amount, available);  // queue for review instead15        available -= amount;16    }17}

Conclusions

The public record shows bridges failing at every stage of the verification path: the signer keys, the code that checks signatures and proofs, the configuration that tells that code what to trust, and the handlers that act on verified messages. No verification design is immune, and each one shifts risk to a different component.

The consistent lesson is defence in depth around verification: independent signers, reviewed configuration, fuzzed verifiers, strict message binding, and outflow controls that assume all of the above might fail.

Recommendations

The Arbalest Bridge and Axeline Bridge research assessments apply these questions to two bridge designs modelled by Quantix researchers.