Auditing a Cross-Chain Bridge in 2026: The Failure Modes Behind the Biggest Exploits
Ronin lost about $624 million in March 2022, and its bridge contracts worked exactly as written. An attacker took over five of the nine validators and signed the withdrawals. Through October 2026, no bridge has lost more.
That is the trap in scoping a bridge smart contract security audit like any other review. Most quotes cover one repository at one commit, and on a bridge, the repository is only part of the attack surface. Signers, relayers, key custody, and the contracts on the other chain are excluded unless the scope names them.
This is a map for the team approving that scope. It sorts ten exploits into five failure modes, names the audit activity that tests each one, and gives you a checklist for your next vendor call. For the general boundaries, read our buyer’s guide to smart contract audit scope.
Scope the trust model, not the repository.
Key Takeaways
- Five of the ten cross-chain bridge hacks in this article were key or operational failures, with no contract flaw reported.
- A key risk with cross-chain bridges is concentrated trust, since five compromised validators were enough to release about $624 million at Ronin.
- Ten cross-chain bridge hacks from 2021 to 2026 reduce to five failure modes: signer compromise, message verification, initialization and upgrades, access control, and accounting.
- Scope a bridge audit to the trust model, not the repository, and treat every mid-audit change as new code, since Nomad’s $190 million flaw arrived that way.
Table of Contents
- What “Bridge Smart Contract Security Audit” Actually Means in 2026
- The Five Failure Modes Behind the Biggest Bridge Exploits
- How We Audit a Cross-Chain Bridge (Methodology)
- What a Bridge Audit Should Cover: The Scope Checklist
- Red Flags in a Bridge Audit Report
- Code Audit vs. Operational Security Review vs. Continuous Monitoring
- What Drives Bridge Audit Timeline and Cost
- Conclusion
- FAQs
What “Bridge Smart Contract Security Audit” Actually Means in 2026
A bridge smart contract security audit is a review that examines the contracts on each chain, tests the message verification between them, and maps the off-chain signers and relayers. It is a review of every trust boundary, not a line-by-line read of one repository.
What are cross-chain bridges? They are systems that move assets or messages between chains, built from contracts on each chain plus off-chain actors. As of October 2026, ethereum.org’s bridge documentation defines lock and mint as locking assets on the source chain and minting equivalent tokens on the destination chain. The return leg is burn and release. A liquidity network mints nothing and swaps against pooled funds.
An audit of that system covers the source and destination chain contracts, the message layer between them, the signers or provers that attest to each message, and the upgrade keys that can change any of it. A bridge releases funds on one chain because of a message about another, so the review follows that message from deposit to release. Every hop is in scope.
The difference between a bridge audit and a standard smart contract audit is that a bridge audit also reviews the off-chain signers, relayers, and message proofs that connect the two chains. If the basics are new to you, start with what a smart contract audit is.
Three trust models, three different audits
A bridge’s trust model is who or what attests that an event happened on the source chain. That attester sits at the center of how cross-chain bridges work. A user locks or burns an asset on one chain, the attester confirms the event to the other chain, and the destination contract mints or releases the asset. The table sets out the three models, where each has failed, and what an audit concentrates on.
| Trust model | Who attests | What must be trusted | Where it has failed | What the audit concentrates on |
|---|---|---|---|---|
| Externally verified | A multisig, an MPC group, or an outside validator set | A threshold of honest signers who keep their keys | Ronin, Harmony Horizon, Multichain, Orbit Chain, Kelp DAO | Multisig threshold, signer independence, and control of the validator set |
| Optimistically verified | An updater, unless a watcher challenges it in the fraud window | One honest watcher online | Nomad | Fraud window length and how trusted roots are initialized |
| Natively verified | A light client or a validity proof checked on-chain | Correct proof verification code | BSC Token Hub | Proof checks against malformed input, and light client updates |
Externally verified bridges concentrate risk in keys, and a code review alone does not cover key custody. Ask who holds the keys.
The Five Failure Modes Behind the Biggest Bridge Exploits
Ten bridge exploits, most of them among the largest on record, reduce to five repeatable failure modes. The table sorts each cross-chain bridge hack by what failed. Losses are approximate US dollar values at the time of the exploit, taken from the linked write-ups.
| Exploit | Date | Approximate loss | Failure mode | Root cause | Catchable by a contract-only audit? |
|---|---|---|---|---|---|
| Ronin | Mar 2022 | $624 million | Key and signer compromise | Five of nine validators compromised | No |
| Harmony Horizon | Jun 2022 | $100 million | Key and signer compromise | Two keys of a 2-of-5 multisig compromised | No |
| Multichain | Jul 2023 | $126 million | Key and signer compromise | The CEO alone held the MPC keys | No |
| Orbit Chain | Dec 2023 | $81.5 million | Key and signer compromise | Signer keys reported compromised after a firewall was weakened | No |
| Kelp DAO | Apr 2026 | $292 million | Key and signer compromise | Compromised RPC nodes fed forged data to a 1-of-1 verifier | No |
| Wormhole | Feb 2022 | $326 million | Message verification | The Solana signature check accepted a fake account | Yes, with the Solana contract in scope |
| BSC Token Hub | Oct 2022 | $586 million minted, $127 million moved out | Message verification | A forged proof of deposit passed verification | Only with the proof library in scope |
| Nomad | Aug 2022 | $190 million | Initialization and upgrade | An upgrade trusted a zero root, so every message passed | Yes, if mid-audit changes are reviewed |
| Poly Network | Aug 2021 | $611 million | Access control | A cross-chain message could change the bridge’s public keys | Yes |
| Verus-Ethereum | May 2026 | $11.58 million | Accounting | Ethereum payout was never checked against the source amount | Yes |
1. Key and signer compromise (Ronin, Harmony Horizon, Multichain, Orbit Chain, Kelp DAO)
The Ronin bridge hack needed no contract flaw, because the attacker obtained enough signing keys to approve withdrawals. Ronin ran nine validators with a threshold of five, and four belonged to one company. Harmony Horizon sat behind a 2-of-5 multisig, Multichain’s CEO alone held its MPC keys, Orbit Chain’s loss was attributed to compromised signer keys, and Kelp DAO relied on a single verifier, which was deceived through compromised RPC nodes.
The check here is an operational review, not a code review. It covers the signer count and multisig threshold, where the keys are stored, who holds them, how they rotate, and whether one organization controls a quorum. Only the threshold and the signer addresses live on-chain. Count the organizations, not the signers.
2. Message verification flaws (Wormhole, BSC Token Hub)
A message verification flaw means that the bridge accepts a message or a proof it should reject. In the Wormhole bridge exploit, according to Wormhole’s incident report of February 2022, the signature verification code in its core Solana contract let an attacker substitute a fake account for the one proving that signatures were checked. On BSC Token Hub, BNB Chain’s October 2022 Ecosystem Update says that the attacker forged a proof in a common library and withdrew 2 million BNB.
Here, the auditor forges messages on purpose, mutating every field, replaying old signature sets, and feeding malformed input to the proof verification code. A verifier that was never attacked in testing has not been tested.
3. Initialization and upgrade errors (Nomad)
The Nomad bridge exploit came from a routine upgrade that left the contract trusting a default value, so every message passed as proven. Nomad’s root cause analysis dates the faulty change to May 26, 2022, during the audit period, and says that it reached production in an upgrade on June 21, 2022. Nomad had an audit. The flaw entered the code while that audit was under way.
The audit activity is to review every initializer and every upgrade path, treat any mid-audit change as new code, and pin the report to the deployed commit. An audit covers a commit, not a product.
4. Access control and privileged call paths (Poly Network)
An access control failure on a bridge is a cross-chain message reaching a function that only an owner should call. At Poly Network in August 2021, a crafted message made the bridge’s manager contract call the data contract that stores the bridge’s public keys, and the attacker installed a key of their own.
The test is to list every function a cross-chain message can call and every function that can change signers, then show that the lists never overlap. For the standard treatment, our scope guide explains how an audit reviews access control and privilege.
5. Accounting, replay, and finality assumptions (Verus-Ethereum)
This class of failure takes three forms: minted supply that exceeds locked collateral, a message replayed on a second chain, and a deposit credited before the source chain reaches finality. The core invariant of lock and mint is that tokens minted on the destination never exceed tokens locked on the source. In May 2026, the Verus-Ethereum bridge verified every signature and still paid out an estimated $11.58 million because nothing checked the payout against the amount committed on Verus.
The auditor writes that invariant as a test and attacks it with random call sequences, the method that Foundry’s invariant testing guide documents. Nonce and chain ID checks provide replay protection, and a simulated reorg of the source chain tests finality.
How We Audit a Cross-Chain Bridge (Methodology)
In seven steps, a cross-chain bridge audit maps the trust model, tests message verification, reviews each chain’s contracts, fuzzes the invariants, and checks upgrades, signers, and emergency controls. That sequence answers how to audit cross-chain smart contracts, and each step names the failure modes it addresses.
- Trust model mapping: threat modeling that records who attests to each message and what must be trusted. Sets the scope for all five modes.
- Message layer review: message forgery tests against the verification code. Tests for message verification flaws.
- Per-chain contract review: each chain’s contracts in their native language, plus differential testing across chains. Tests for access control failures.
- Invariant and fuzz testing: the supply invariant, attacked with random call sequences. Tests for accounting, replay, and finality mistakes.
- Upgrade and admin review: every initializer, upgrade key, and timelock. Tests for initialization and upgrade errors.
- Signer set review: signer count, multisig threshold, and validator set control. Tests for the on-chain half of signer compromise.
- Pause and rate limit review: whether a pause guardian and a rate limit cap the loss when other controls fail. Limits damage from all five modes.
We open the scope conversation with three questions: which contracts and code version need review, what other systems they depend on, and who can change settings, move funds, or update the code. On a bridge, the answers are the trust model. Ask for the trust assumptions in writing, and read each finding against the code version it covers.
Key custody, relayer infrastructure, and monitoring sit outside a code audit by default. Name them in the scope conversation if you need them reviewed.
What a Bridge Audit Should Cover: The Scope Checklist
A blockchain bridge audit should cover nine components, and a quote that names fewer has left the rest out of scope. Each row gives the test, the exploit it maps to, and a question to ask on a sales call.
| Component | What gets tested | Exploit it maps to | Question to ask your auditor |
|---|---|---|---|
| Source chain contracts | Deposit, lock, and burn logic, and emitted events | None here | Which source events can release funds elsewhere? |
| Destination chain contracts | Mint and release logic, and every callable function | Poly Network | Can a message reach a function that changes a signer? |
| Message format and verification | Signature and proof checks against forged input | Wormhole, BSC Token Hub | Did you submit forged messages, and where are the tests? |
| Signer set and threshold | Signer count, multisig threshold, and validator set control | Ronin, Harmony Horizon, Kelp DAO | How many organizations must be compromised to sign a withdrawal? |
| Relayers | Altered, withheld, and replayed messages | None here | What happens when a relayer alters a message? |
| Upgrade keys and timelocks | Initializers, upgrade paths, and the timelock delay | Nomad | Does the commit you reviewed match what is deployed today? |
| Pause and rate limits | Pause guardian powers and withdrawal caps | Ronin, unnoticed for six days | If signers are compromised tonight, what caps the loss? |
| Token accounting | Minted supply against locked collateral | Verus-Ethereum | Is the supply invariant a test, and what did fuzzing find? |
| Chain-specific behavior | Finality, reorg depth, and runtime differences | Wormhole, on its Solana side | Who on your team has audited each runtime? |
A vendor that cannot answer a question is not covering that row. If your bridge spans more than one runtime, read how Solana, Move, and EVM audits differ.
Red Flags in a Bridge Audit Report
The scope section of a bridge audit report tells you more than its findings list. Five red flags matter most.
- Scope lists one chain’s contracts only: the message layer and the other chain were never read.
- No statement of trust assumptions: if the report never says who attests to messages, nobody mapped the trust model.
- Signers and keys marked out of scope without comment: that exclusion leaves out the failure mode behind Ronin and Kelp DAO, so it deserves a paragraph, not a footnote.
- No invariant tests: without a tested supply invariant, the accounting was only read.
- Audit predates the latest upgrade: the Nomad bridge exploit ran through a change made after Nomad’s audit began.
One red flag is worth a question. Three mean that you need a new scope.
Code Audit vs. Operational Security Review vs. Continuous Monitoring
A code audit, an operational security review, and continuous monitoring are three separate purchases, and a cross-chain security audit quote usually includes only the first.
| Question | Code audit | Operational security review | Continuous monitoring |
|---|---|---|---|
| What it covers | Contract code, message verification, and upgrade logic at one commit | A key ceremony review, plus key storage, signer independence, and relayer access | Live transactions, signer changes, and supply against collateral |
| Failure modes addressed | Modes 2 to 5, plus signer thresholds | Mode 1, key and signer compromise | None, but it limits damage from all five |
| When it happens | Before launch and after every upgrade | Before launch, then on a schedule | Continuously, from launch |
| Who does it | An audit firm | A key management specialist | Your team or a monitoring provider |
| What it leaves open | Stolen keys and anything changed after the commit | Flaws in the code | Root causes, which it does not fix |
Any code audit, ours included, is a point-in-time review of one commit, so on the day you upgrade, the report describes code you no longer run.
If you integrate a third-party bridge or messaging layer, the provider’s audits cover its contracts, not your settings. LayerZero’s documentation says that each application configures its own verifier threshold, and Halborn traced Kelp DAO’s loss on LayerZero to a 1-of-1 verifier configuration. A cross-chain security audit of an integration starts with what you configured.
What Drives Bridge Audit Timeline and Cost
A cross-chain bridge audit takes longer and costs more than a single-chain audit of the same size, and three things move the quote: the number of chains, the trust model, and the lines of code. A bridge is two or more codebases, often in different languages, plus the off-chain layer between them.
The trust model is the second driver. A natively verified design adds proof verification code that needs specialist review, and an externally verified one adds the signer set. Lines of code scale the quote as on any audit. The timeline follows the same three drivers, and every change after the commit freeze adds a re-review.
A blockchain bridge audit quote given before a scoping call is a guess. Ask what the quote assumes about each driver, and compare scope, not totals. Our smart contract audit page lists what to bring to that first conversation.
Conclusion
Five of the ten bridge exploits reviewed here were key or operational failures. The other five, the Wormhole bridge exploit and Nomad’s among them, hit code that a scoped audit tests directly. Map the trust model. Test the message layer. Audit the keys. Re-audit every upgrade.
If you want a scoped plan for your bridge smart contract security audit, book a free 30-minute bridge security call. We’ll map your trust model, list the failure modes in scope, and send a written scope.
FAQs
What is a bridge smart contract security audit?
A bridge smart contract security audit is a review of every component that moves assets between chains. It covers the contracts on each chain, the message verification between them, and the signers, relayers, and upgrade keys. It is broader than a standard audit because much of the risk sits off-chain.
Do rollups need cross-chain bridges?
Yes. Every rollup relies on a bridge to move assets between itself and its settlement chain. The canonical rollup bridge inherits security from the rollup’s proof system, while third-party bridges add their own signers or liquidity pools. Each added bridge is a separate trust assumption and needs its own review.
How do cross-chain bridges work?
Cross-chain bridges lock or burn an asset on one chain and mint or release it on another. An attester, such as a validator set, a multisig, an optimistic updater, a light client, or a validity proof, confirms the source event to the destination chain. That attester is the trust model.
What is the biggest risk with cross-chain bridges?
Concentrated trust is the biggest risk. On an externally verified bridge, a small set of signers controls all locked funds, and on other designs, one verification function does. Ronin, Harmony Horizon, Multichain, Orbit Chain, and Kelp DAO each lost funds through keys, signers, or one verifier, with no contract flaw reported.
How do validators work in cross-chain bridges?
Validators watch the source chain and attest that a deposit happened. When enough of them sign to meet the threshold, the destination contract releases funds. If an attacker controls that many keys, the bridge approves forged withdrawals, which is how the Ronin bridge hack took about $624 million in March 2022.
What are relayers in cross-chain bridges?
Relayers carry messages from one chain to another. In a sound design, a relayer cannot forge a message, because the destination contract verifies it. An audit tests that assumption by submitting altered and replayed messages through the relayer path and confirming that message verification and replay protection reject every one.
How long does a bridge audit take, and what does it cost?
A bridge audit takes longer and costs more than a single-chain audit of the same size. It covers two or more codebases plus the off-chain layer. Three things drive the quote: the number of chains, the trust model, and the lines of code. Expect a firm figure after a scoping call.
Would an audit have prevented the Ronin or Nomad hacks?
A contract-only audit would not have prevented Ronin’s loss. It came from stolen validator keys, which sit outside the code. The Nomad bridge exploit came from a change made while Nomad’s audit was under way, so an audit happened, and the flaw still shipped. Scope the keys, and review every later change.