A chain bridge is a protocol that moves value or messages between two blockchains that have no way to verify each other. It is also the part of Web3 that loses the most money. Five of the ten largest losses on the rekt.news leaderboard are bridges, and Chainalysis found that bridge attacks accounted for 69% of all funds stolen in 2022.
Think of two countries whose courts do not recognise each other’s judgments. A contract between them is unenforceable, so both sides appoint a notary they agree to trust. The contract now works. The notary is also now the weakest thing in the arrangement, because neither legal system protects it.
That is a bridge. Every bridge design is a different answer to the question “who do we trust instead”, and almost every bridge hack is that answer turning out to be wrong.
Quick Answer
A chain bridge moves assets or data between two blockchains that cannot natively verify each other. Because neither chain can check the other, every bridge relocates that verification to a third party: a signer set, a relayer, or a verification contract. That third party holds the value of the whole bridge and is protected by neither chain’s consensus.
Last updated August 2026.
What is a chain bridge?
A chain bridge is a protocol that lets an asset or a message cross from one blockchain to another. Ethereum cannot read Solana’s state. Bitcoin cannot call an Arbitrum contract. Each chain only knows what its own validators have agreed on, and it has no native mechanism for believing anything else.
Bridges exist because the money does not respect that boundary. Liquidity sits on one chain and the application the user wants sits on another.
The vocabulary drifts a bit. ‘Chain bridge’, ‘cross-chain bridge’ and ‘blockchain bridge’ all mean the same thing. A cross-chain messaging protocol is the broader category: it moves arbitrary data, and moving tokens is one thing you can build on top of it. Most of the largest losses discussed below happened on token bridges built over a messaging layer, which is why the distinction matters when you are deciding what to put in scope for a review.
How a bridge actually moves an asset
Nothing physically crosses. There is no such thing as an ETH on Solana. What happens is that value is immobilised on one side and represented on the other, and there are three common ways to do it.
| Mechanism | Source chain | Destination chain | Where the risk sits |
|---|---|---|---|
| Lock and mint | Asset is locked in an escrow contract | A wrapped equivalent is minted | The escrow holds everything. Mint authority must be exclusive to the bridge |
| Burn and mint | Asset is burned | The native asset is re-issued | Supply integrity across both sides. A forged burn mints free tokens |
| Lock and unlock | Asset is locked | An equivalent is released from a liquidity pool | Pool depth, plus everything in row one |
In every case, one side has to be told what happened on the other. That message is the actual product. The tokens are downstream of it.
A user calls the bridge on chain A. The bridge immobilises the asset and emits an event. Something off-chain observes that event and attests to it. The bridge contract on chain B checks the attestation and releases the asset.
The whole security model lives in that third step. Who attests, how many of them have to agree, and what chain B’s contract actually verifies before it believes them.
Why bridges are the most exploited component in Web3
The reason is architectural, not incidental.
A lending protocol on Ethereum is defended by Ethereum. Its state is agreed by the whole validator set, and an attacker who wants to change it has to beat consensus. A bridge cannot borrow that defence, because the thing it needs to prove is a fact about a chain whose consensus this chain cannot see.
So the bridge appoints someone. That someone might be nine key holders, one verifier node, a light client, or a contract that checks signatures. Whatever it is, three things become true at once:
- It is worth the entire value locked in the bridge, which for a large bridge is hundreds of millions.
- It is not protected by either chain’s consensus, because it sits between them.
- Its failure is often invisible on-chain, because a forged message that passes verification looks exactly like a real one.
That last point is the one people underestimate. When the Ronin bridge was drained, nobody noticed for almost a week. The Halborn analysis records that the breach came to light six days later, when a user reported being unable to withdraw around 5,000 ETH. Every transaction the attacker submitted was valid by the bridge’s own rules.
Add the fact that bridges concentrate capital by design, and you get the loss distribution the leaderboard shows.
The biggest bridge losses, and the five failures behind them
Every loss figure and date below comes from the rekt.news leaderboard, except Verus, which is too recent to appear on it and is sourced to Merkle Science instead. The last column says which is which, because a table that silently mixes two compilers is worse than one that admits it.
| Incident | Date | Loss | What actually broke | Figure from |
|---|---|---|---|---|
| Ronin Network | 23 March 2022 | $624m | 5 of 9 validator keys compromised | rekt.news |
| Poly Network | 10 August 2021 | $611m | A crafted message reached a privileged keeper function | rekt.news |
| BNB Bridge | 6 October 2022 | $586m | A forged Merkle proof passed an incomplete verification | rekt.news |
| Wormhole | 2 February 2022 | $326m | A signature check read an account it never validated | rekt.news |
| KelpDAO | 18 April 2026 | $290m | A default 1-of-1 verifier configuration | rekt.news |
| Nomad Bridge | 1 August 2022 | $190m | An upgrade made every message valid by default | rekt.news |
| Verus | 18 May 2026 | $11.58m | Nobody checked that the two sides’ amounts matched | Merkle Science |
Five of these show distinct failure classes, and those five are dissected below. Poly Network and BNB Bridge are in the table for scale rather than as separate classes: both were on-chain verification and authorisation failures, the same half of the problem that Wormhole illustrates. Poly’s attacker reached a privileged keeper function through a crafted cross-chain message (Halborn), and BNB’s forged a Merkle proof against an incomplete IAVL verification (Immunefi).
The signer set is compromised
Ronin, March 2022. Ronin used nine validators and required five to approve a withdrawal. An attacker obtained five private keys, four from Sky Mavis and one from the Axie DAO, then signed two withdrawals draining 173,600 ETH and 25.5m USDC (Halborn).
No contract misbehaved. The bridge did precisely what it was built to do, for someone who had acquired the right to ask.
The on-chain verification is bypassable
Wormhole, February 2022. The Solana side used a deprecated instruction, load_instruction_at, to confirm that signature verification had run. That instruction did not check that the account handed to it was really the Instructions sysvar. The attacker supplied a fake one, the contract believed the signatures had been verified, and 120,000 wETH was minted without backing (Halborn).
This is a code bug, in the narrowest sense. A reviewer reading that function and asking “what validates this account?” finds it.
An upgrade changes what counts as valid
Nomad, August 2022. A routine upgrade initialised the trusted root to the zero hash, which made every message prove valid by default (Immunefi). Once the first attacker demonstrated it, anyone could copy the transaction and swap in their own address. The Block counted more than 300 addresses taking part within about an hour.
The deployed contracts had been reviewed. The initialisation value was set afterwards.
Value conservation is never checked
Verus, May 2026. On the night of 17 to 18 May, an attacker forged a cross-chain import that passed every cryptographic check while committing essentially nothing on the source chain. Both sides validated, and neither required that the amount committed on Verus match the amount paid out on Ethereum. The bridge released 1,625 ETH, 103 tBTC and 147,000 USDC, about $11.58m, against roughly $10 of fees. Merkle Science puts the missing check in checkCCEValues and the fix at around ten lines of Solidity.
Ten lines. This is the class that a careful manual review is best at, because the bug is not in any single function. It is in the relationship between two of them.
The trust configuration is a default nobody changed
KelpDAO, April 2026. Attackers compromised the RPC nodes that KelpDAO’s single LayerZero verifier depended on and fed it a fabricated cross-chain message. The verifier attested to it, the bridge released 116,500 rsETH, and roughly $292m left the system. Chainalysis reports the bridge ran a 1-of-1 DVN setup, and that Kelp has said this was the default configuration shipped for new deployments at the time it expanded to L2s. LayerZero attributed the operation to the Lazarus Group.
Nobody wrote a bad line of code. Somebody accepted a default.
On the numbers: the table uses rekt.news’s $290m for KelpDAO, while Chainalysis and OpenZeppelin both put it at approximately $292m. rsETH moved between the moment of the exploit and the moment of valuation, and both figures are right at their own timestamp.
What a security review looks for in a bridge
Reviewing a bridge is not the same as reviewing a lending market. The interesting bugs live in the seam between two deployments, and half of them are not in the Solidity at all. This is the list we work through.
- Value conservation across both sides: Does the amount credited on the destination provably equal the amount committed on the source? Is that check enforced in code, or assumed because both sides validate separately?
- Message uniqueness: Can a valid message be submitted twice, on the same chain or a different one? Is every processed message marked spent, and is the identifier derived from something an attacker cannot reuse?
- The verifier set and its threshold: How many signers, who holds the keys, where do they run, and is the threshold a deliberate choice or the value that shipped in the box?
- Signature and proof verification: Is every account, parameter and sysvar the verification path reads actually validated, rather than trusted because it arrived?
- Mint authority on the destination: Who can mint the wrapped asset, and is that authority exclusive to the bridge and revocable if it is not?
- Initialisation and upgrade paths: What does a fresh proxy initialise to? Can an upgrade or an admin call set a trusted root, an owner or a threshold to a permissive value?
- Finality and reorganisation assumptions: How many confirmations does the destination wait for, and what happens to a completed transfer if the source chain reorganises?
- Rate limits and circuit breakers: Is there a cap on how much can leave in one window, and can a human halt the bridge before the whole escrow is gone?
- Off-chain components in the trust path: Relayers, RPC endpoints, oracles and the machines they run on. What is the blast radius if one of them lies?
- Detection after deployment: Is there anything that notices an unbacked mint or a draining escrow in minutes, rather than in six days?
Items 1, 2, 4, 5 and 6 are code. A manual smart contract audit covers them, and Wormhole, Nomad and Verus are all in that half of the list. Items 3, 7, 8, 9 and 10 are architecture and operations, and they are where Ronin and KelpDAO sit.
What a code audit will not catch
Some of this, it will not.
After KelpDAO, OpenZeppelin published an analysis under the title “$292 Million Lost, Zero Bugs Found”. Their finding was that “the contracts performed exactly as written”, and that what failed was “not contract code, but part of the broader operational and integration setup around the bridge infrastructure”. Aave, which took the largest downstream hit, said the same about its own contracts.
They are right, and it is the most useful thing anyone published about that incident. A point-in-time code review of KelpDAO’s contracts would have come back clean, because the contracts were clean. The 1-of-1 verifier configuration was not in the code. It was in the deployment.
Two things follow for anyone running a bridge.
Scope the review to the system, not the repository. The verifier topology, the quorum, the RPC dependencies and the upgrade keys belong in scope alongside the Solidity. Our manual audits start at $5,000 and cover logic and economic risk rather than a rule-set pass, they include two rounds of fix verification, and for a bridge that means both deployments and the path between them. Every report we have published is on the audits page, including the findings we did not enjoy writing.
Then assume the review expires. Ronin’s keys were compromised long after its code was written. Nomad’s trusted root was set by an upgrade after review. A bridge changes its configuration more often than it changes its contracts, which is exactly why we argue that security is a process rather than an event and why audits age even when attackers do not. Continuous scanning on every commit catches the code half. Post-deployment monitoring with detectors tuned to your protocol’s own logic, rather than generic threshold alerts, is what shortens six days to six minutes.
The distinction we keep coming back to is the one in our piece on formal analysis: most serious Web3 failures are not obvious bugs. They are logic behaving correctly according to the code and incorrectly according to what anyone intended. Bridges are where that gap is widest, because the intent spans two systems and the code only ever sees one.
If you are building or running a bridge, the useful question is not whether your contracts are audited. It is which of the ten items above nobody currently owns.
Frequently asked questions
What is a chain bridge?
A chain bridge is a protocol that moves assets or messages between two blockchains that cannot natively verify each other. It works by immobilising value on the source chain and representing it on the destination chain, using a third party such as a signer set or a verification contract to attest that the source-chain event really happened.
Why are chain bridges the most exploited component in Web3?
Because a bridge cannot inherit either chain’s security. Neither chain can verify the other, so the bridge appoints a third party to do it, and that party holds the value of the whole bridge while being protected by neither consensus. Chainalysis found bridge attacks accounted for 69% of all funds stolen in 2022, and five of the ten largest losses on the rekt.news leaderboard are bridges.
What was the biggest bridge hack?
The Ronin Network bridge, drained of $624m on 23 March 2022 according to the rekt.news leaderboard. An attacker obtained five of the nine validator private keys required to approve a withdrawal, four from Sky Mavis and one from the Axie DAO, and the breach was not discovered for six days.
Are trustless bridges safer than trusted bridges?
Not automatically. A trustless bridge replaces human signers with code, which removes key-compromise risk and adds verification-logic risk in its place. Wormhole and Nomad both failed on verification logic rather than on compromised keys. The right question is not whether a bridge is trustless but what specifically it trusts and what happens when that thing is wrong.
Can a smart contract audit prevent a bridge hack?
It prevents some classes and not others. Missing value-conservation checks, replay bugs, unvalidated signature paths and unsafe initialisation are all findable in a code review. Compromised signer keys, default verifier configurations and dependencies on off-chain infrastructure are not, because they are not in the code. OpenZeppelin’s analysis of the KelpDAO exploit concluded that the contracts performed exactly as written.
How much does a bridge audit cost?
Fidesium manual audits start at $5,000, and a bridge is scoped on both deployments plus the messaging path between them rather than as a single codebase, so the scope is usually larger than a single-chain contract of the same line count. Scope, logic density and how much of the verification path is off-chain are what move the number.
What is the difference between a bridge and a cross-chain messaging protocol?
A cross-chain messaging protocol moves arbitrary data between chains. A token bridge is one application built on top of that capability. The distinction matters for security review, because when a token bridge is built over a third-party messaging layer, the trust assumptions of that layer, including its verifier quorum, belong in the scope of the review.
