Cross-chain bridges were among the largest sources of crypto losses in 2022, accounting for approximately 69% of stolen funds during that year [Chainalysis, 2022]. Bridge exploits caused approximately $2 billion in losses during 2022. Many of these incidents resulted not from broken cryptographic primitives, but from contract-validation failures, concentrated validator control and unsafe upgrade procedures.
Asset bridges commonly lock or burn value on a source chain and release or mint corresponding value on a destination chain. General messaging bridges verify and execute arbitrary cross-chain instructions. Every one of these handoffs presents a distinct attack surface.
For developers building anything that needs to move value or data across chains, including real-world asset transfers that increasingly depend on this exact infrastructure, understanding exactly how the biggest bridge hacks worked at the code level is the fastest way to avoid repeating them.
This article dissects three of the largest cross-chain exploits in DeFi history and extracts the design lessons that carry over directly into building safer infrastructure.
What A Bridge Is Actually Made Of
While not all bridges use a lock-and-mint architecture (some rely on burn-and-mint, liquidity networks, native asset transfers, message-passing systems, or light-client verification), a common lock-and-mint bridge model relies on three core components:
- Source-chain custody or burn mechanism: Smart contracts on the source chain that hold or destroy user assets.
- Cross-chain verification or messaging layer: Off-chain nodes, oracles, validators, or light clients that attest to source events and relay messages.
- Destination-chain minting, release or execution mechanism: Contracts on the destination chain that release/mint assets or execute arbitrary instructions.
Every major bridge exploit targets the logic connecting these three pieces, most often the signature verification or consensus step that's supposed to prove a lock event actually happened before the destination chain mints anything.
Poly Network: Unsafe Cross-Contract Invocation and Privilege Escalation
In August 2021, an attacker drained roughly $610 million from Poly Network across Ethereum, Binance Smart Chain, and Neo—one of the largest crypto exploits recorded at the time. Unsafe handling of a user-controlled method identifier allowed the attacker to invoke a privileged validator-management function through a function-selector collision [Kudelski Security].
Poly's architecture contained an EthCrossChainManager contract and an EthCrossChainData contract (which stored the Keeper validator public keys). The manager contract was allowed to call privileged functions on the data contract.
The manager exposed verifyHeaderAndExecuteTx, which allowed users to specify a target contract and method name. The attacker identified that the method string f1121318093 produced the selector 0x41973cd9, colliding with putCurEpochConPubKeyBytes, a privileged function used to overwrite Keeper keys. By submitting this payload, the attacker updated the Keeper keys to their own address and authorized fraudulent withdrawals.
Most of the assets were subsequently returned, although this does not change the severity of the underlying access-control failure.
Ronin Network, A Temporary Permission That Was Never Revoked
The March 2022 Ronin Network exploit lost 173,600 ETH and 25.5 million USDC, worth roughly $568 million at the time, and unlike Poly Network, it wasn't a smart contract bug at all. It was a failure of validator decentralization and operational hygiene.
Ronin's bridge required 5 of its 9 validator signatures to approve any withdrawal. Sky Mavis, the company behind the bridge, directly controlled 4 of those validators. A fifth signature came from Axie DAO, a separate Axie DAO validator. In late 2021, Axie DAO granted Sky Mavis temporary permission to sign transactions on its behalf to handle a traffic spike, which severely weakened the practical independence of the validator set.
The event resulted from a chain of operational and architectural failures: compromised validator private keys, concentrated entity ownership, an outdated signing permission, unsafe RPC access, and inadequate real-time monitoring. The numerical threshold appeared distributed (5-of-9), but the effective control structure allowed one compromised organization to reach the required quorum.
The exploit went undetected for six days, only discovered when a user's own withdrawal request failed.
Nomad Bridge, One Bug And Hundreds Of Copy Paste Attackers
In August 2022, a routine contract upgrade to Nomad's Replica contract accidentally set the bridge's trusted root, the reference value used to validate Merkle proofs for incoming messages, to 0x00. The bridge's process() function was supposed to check every incoming message's proof against this root before accepting it.
During an upgrade, the zero root was marked as acceptable in Nomad's Replica contract. Because unproven messages also resolved to a default zero value in the contract’s confirmation mapping, the validation logic treated arbitrary messages as proven.
Once discovered, copycats reused publicly visible calldata, replaced the recipient address, and submitted new transactions that the faulty validation logic accepted. Over $190 million was drained in a self-propagating mob attack before the bridge was paused.
The Three Exploits Compared
Incident | Primary Failure Class | Initial Entry Point | Privilege Obtained |
Poly Network | Contract access-control and arbitrary-call validation | User-controlled method input | Validator set overwrite (putCurEpochConPubKeyBytes) |
Ronin Network | Key compromise and effective validator concentration | Exposed RPC backdoor / Sky Mavis compromise | 5-of-9 signature threshold (via active Axie DAO grant) |
Nomad Bridge | Upgrade initialization and message-proof validation | Routine contract upgrade | Acceptance of unproven messages |
Design Lessons That Generalize Beyond Any One Hack
Each of these exploits looks different on the surface, but the underlying lessons apply directly to anyone building cross-chain infrastructure today, including the compliance-aware transfers real-world asset platforms increasingly require.
- Avoid user-controlled function names or selectors for privileged cross-contract execution. Use explicit allowlists, typed calls, and narrowly scoped entry points. Security-critical actions like updating validator keys must be gated behind multi-signature approval and timelocks.
- Enforce strict lifecycle and scoping controls on operational access. Any temporary permission must include automatic expiry, least-privilege scope, periodic access reviews, on-chain permission registries, real-time revocation alerts, separate emergency credentials, and hardware-backed key storage.
- Qualify trust assumptions in light-client verification. Light-client verification can reduce reliance on a separate validator committee, although it introduces its own implementation, consensus-verification, finality-handling, and relayer-availability risks
- Build real-time monitoring, not just point-in-time audits. Ronin's six-day detection gap is the clearest evidence that an audit passed once is not the same as a system being watched continuously. Tracking anomalous patterns, like unusual pre-withdrawal contract calls or sudden concentration of validator signing activity, catches attacks in progress rather than after the fact.
- Implement concrete upgrade-security controls. Updates to validation logic require atomic initialization, initializer protection, simulation against historical message payloads, storage-layout validation, independent code review, timelocked deployment, canary limits, post-upgrade withdrawal caps, and emergency pause authority.
Comprehensive Monitoring and Additional Threat Vectors
Real-time observability must track explicit operational anomalies, including:
* Unusually large or rapid repeated withdrawals
* Sudden concentration of validator signatures or validator key changes
* Contract upgrades, root or checkpoint changes
* Minting that exceeds locked collateral or supply discrepancies across chains
* Delayed finality and paused-chain conditions
Core Bridge Invariant: Bridges must enforce at the contract and monitoring level that the value minted or released on destination chains never exceeds the verified value locked or burned on source chains.
Broader Cross-Chain Attack Vectors
Beyond the case studies presented, bridge architectures must defend against:
* Replay attacks and cross-chain ID mismatches
* Blockchain reorganizations and finality rollbacks
* Relayer censorship and upgrade-key compromise
* Wrapped-asset insolvency and missing execution rate limits
What This Means For Cross-Chain RWA Transfer Specifically
Real-world asset platforms moving tokenized treasuries, equity, or credit across chains inherit every one of these risks and add a compliance dimension on top. Cross-chain RWA systems may also need to preserve transfer restrictions, investor eligibility, jurisdictional rules, and asset-control records across chains. Compliance enforcement can be handled via permissioned token standards (e.g., ERC-7518/DyCIST), identity registries, transfer restriction modules, attestation frameworks, or allowlisted wallet modules.
None of that compliance layer matters, though, if the underlying transport is vulnerable to the same three failure modes above: a collidable privileged function, an unrevoked permission, or a validation check that silently breaks during a routine update.
The Pattern Underneath All Three Hacks
Breaking cryptography wasn't required for any of these three exploits. Poly Network exploited a hash collision within a system that was working exactly as coded, just coded with too much trust in a user-supplied parameter. Ronin exploited a temporary human decision that outlived its purpose. Nomad exploited a null value that a validation check should never have accepted as legitimate.
Bridge security depends on application-layer code, off-chain operators, and operational controls in addition to the security of the connected base layers. Treating access control, permission lifecycles, and validation logic with extreme rigor is the only way to ensure cross-chain infrastructure remains resilient.
Related Articles
- Consensus, Custody and Cryptographic Architecture, A Technical Reference
- Oracle Design and Data Integrity, How Price and Asset Feeds Are Secured and How They Fail
- Smart Contract Audit Methodology, Static Analysis, Formal Verification and Coverage Gaps
- Evaluating Cryptographic Claims in Whitepapers Against Verifiable On-Chain Evidence
