How Crypto Bridges Get Hacked: A Post-Mortem of Eight Incidents

By Nika, NodeTimes newsroom.

Bridges get hacked because they answer a question that no chain can verify on its own: did something really happen on the other chain? Every large bridge loss comes down to that question being answered wrongly, by a compromised key, a forged proof, an off-chain service that was fed false data, or a permission that was never revoked. The amounts differ; the failure class does not.

The pattern behind every large bridge loss

A bridge holds value on one chain and releases an equal amount on another, so its correctness depends on a cross-chain invariant rather than on a single contract. When the invariant breaks, the assets released on the far side have no backing upstream.

Cross-chain invariant: the accounting rule that assets released on the destination chain must equal assets burned or locked on the source chain. Merkle proof: the compact evidence that a transaction was included in a block, which a bridge checks before it releases funds. DVN (Decentralized Verifier Network): an off-chain service that watches one chain and attests to a message so the other chain can act on it.

Almost every incident reduces to one of four classes of failure:

• Key compromise: the attackers hold enough validator keys to sign a fraudulent withdrawal.
• Verification-path bug: the contract accepts an attestation it should have rejected.
• State-as-data: an off-chain verifier is fed false source-chain data by poisoned infrastructure.
• Operational debt: a permission, allowlist or default that should have been closed months earlier.

The terminology of the wider stack stays in the blockchain glossary; this section carries only what the argument needs.

The incidents, and the code that failed

The figures below come from public exploit trackers and from incident reports. The Loss column records what was taken at the moment of the incident, not what a project ultimately lost; where sources disagree on a sum, the table carries one figure rather than a range.

Three rows deserve a longer read, because each one is a lesson the industry has already paid for.

Ronin is the operational-debt case. Nine validators could sign, five signatures were required, and Sky Mavis operated four of them. The fifth was reachable through a delegation the Axie DAO had granted during a transaction surge; the delegation was meant to be temporary, but the allowlist was never revoked, so compromising the operator's own systems was enough to reach the quorum.

KelpDAO is the same failure one layer lower down. The bridge required a single verifier. The intrusion began about six weeks earlier: a developer was socially engineered, session keys were taken from the operator's RPC cloud, and those keys let the attackers replace the node software on two internal hosts the verifier read from. They knocked a third, external host offline to force a failover onto the poisoned pair, and the verifier then signed an attestation describing a burn that had never happened.

No signing key was compromised, no contract contained a bug, and every on-chain transaction was individually valid. The bridge was paused within the hour, which blocked a follow-up attempt to release another 40,000 rsETH, but the first release was already gone.

Verus-Ethereum is the value-binding case. About $11.6 million left the bridge after a forged cross-chain transfer message, and the proceeds were later swapped into roughly 5,402 ETH. About 75% of that, some 4,052 ETH, came back to the project within days, after it offered a 1,350 ETH bounty that the attacker kept. The reported root cause is not a signature or a key failure but a missing check that the amount locked on the source side matched the amount paid out on Ethereum: the cryptographic proof of inclusion was valid, and the economic claim it carried was not.

Why "audited" does not mean safe

A smart contract audit reviews the code path and, by construction, cannot see the infrastructure that decides what the code is told. That gap is where the largest state-as-data loss came from: KelpDAO.

• Audits cover contracts, not the RPC endpoints, signer sets or operator hygiene underneath them.
• Assumptions are what fail: a verifier that trusts its data source is only as honest as that source.
• Economic design amplifies a code bug: when a signature check is wrong, the loss equals whatever the bridge can mint.
• The two most recent incidents pull in opposite directions. KelpDAO came from infrastructure and left the contract untouched; Verus came from a validation gap in bridge code. Hardening one of those does not harden the other.

The practical test is blunt: ask which entities could falsify the message your contract accepts, and whether any of them were inside the audit scope. User-facing fraud is a different problem with a different playbook, covered in the main threats in crypto.

What actually reduces the risk

The controls that map onto those failure classes are operational before they are cryptographic, and each one can be checked today.

1. Require M-of-N attestation from independent operators, not N-of-N from one vendor's stack.
2. Diversify the data sources a verifier reads from, and alert when they disagree instead of failing over silently.
3. Monitor the invariant itself: match every release against a burn, and alert on the first unmatched event.
4. Test updates with fail-closed cases; Nomad's zero root was accepted because nobody tried the empty-message case.
5. Review delegations and allowlists on a schedule; every temporary permission stays a permanent risk until it is revoked.
6. Cap the value a single message can release, so a bug costs a fraction rather than the whole escrow.
7. Keep the ability to pause, and confirm who can execute that pause at three in the morning.

None of these controls is exotic, and none of them depends on a new cryptographic primitive. What they depend on is treating a bridge as two systems and a contract between them, rather than as a contract alone.

A verification checklist for anyone using a bridge

Run these five checks before trusting a bridge with value, and write the answers down with the date.

• Count the verifiers: how many independent attestations are required, and who operates them?
• Map the data path: which RPC endpoints and providers feed the verifier, and what happens on failover?
• Read the change log: when was the last configuration change, and was a temporary permission revoked afterwards?
• Check the invariant monitoring: can the bridge itself detect a release with no matching burn, and how fast?
• Check the exit: what is the maximum value one message can release, and who can pause the bridge?

The answers change over time; the questions do not, which is why the date on an answer matters as much as the answer. How a single endpoint becomes a trust boundary is the subject of the breakdown of blockchain RPC.

Frequently asked questions

What is the largest crypto bridge hack ever?

Ronin Bridge remains the largest recorded bridge loss at about $624 million in March 2022, ahead of Poly Network at $611 million and the BNB Bridge at about $586 million.

Note what the ranking hides: Ronin was a key-management failure, Poly Network an access-control failure, and they share nothing except the size of the number.

Are bridges still being hacked?

Yes, and the vector has moved: the largest recent loss came not from a contract bug or a stolen key but from poisoned RPC infrastructure.

The follow-up attempt in that incident was blocked by a pause, which is the control that decided the final size of the loss.

What is a 1-of-1 DVN configuration and why is it dangerous?

It means one verifier is sufficient to release funds, so the entire security budget of the bridge collapses into the infrastructure of a single operator.

A multisig with one required signer is a single signature with extra steps, and the same logic applies to any bridge whose quorum threshold is one.

Do audits prevent bridge hacks?

No, but the failures differ: KelpDAO came from infrastructure outside the audited boundary, while Verus was a missing validation inside the contract, so both an audit and an infrastructure review are required.

Audits remain necessary; what is missing is an infrastructure-layer review held to the same standard.

What should a user do to reduce exposure?

Treat bridged assets as credit risk rather than as a deposit: prefer routes with several independent verifiers, limit the amount held in any wrapped asset, and check whether the bridge publishes invariant monitoring.

That is a risk-reduction heuristic rather than a guarantee; every bridge on the list above carried real liquidity and real users until the day it did not.