The one-sentence version
Two blockchains cannot see each other. The typical mechanism of a cross-chain bridge is: lock your assets on Chain A, and mint an equivalent amount of "wrapped tokens" on Chain B. The problem lies in: how does Chain B confirm that the assets were actually locked on Chain A? Who performs this "confirmation" and how they verify it constitutes the entire security of the bridge. Cross-chain bridges are the most devastating category of systems in cryptocurrency history: Ronin ($620 million), Wormhole ($320 million), Nomad ($190 million)... The reasons vary, but the essence is the same: massive amounts of capital are locked in one place, while the verification component is much weaker than the chain itself.
This article has three layers:
- Layer 1: The Intuition: Consignment shops and claim tickets
- Layer 2: Real-World Use: Three representative incidents
- Layer 3: Verification models, engineering details, and what users should watch out for
Layer 1: The Intuition
1.1 Consignment shops and claim tickets
You deposit a box of gold at a consignment shop in City A, receive a claim ticket, and then use this ticket in City B to exchange it for items of equal value.
The problem is: how does City B know this claim ticket is authentic?
- If "City B trusts 3 out of 5 notaries," then stealing 3 notary seals allows someone to issue claim tickets out of thin air;
- If City B's verification process has a bug, any piece of paper can serve as a claim ticket;
- Meanwhile, in City A's consignment shop, the gold of everyone is piled up.
1.2 Why they are particularly attractive to thieves
| Feature | Consequence |
|---|---|
| Highly concentrated assets | Hundreds of millions or even billions of dollars are locked in a single contract |
| Verification is usually weaker than the chain itself | A chain has thousands of validators, while a bridge may only have a few signers |
| Involves two chains and two sets of code | The attack surface is doubled, with more edge cases |
| Upgradable with administrators | Administrative privileges themselves become a target for attack |
Layer 2: Real-World Use
| Event | Loss | Reason |
|---|---|---|
| Ronin (March 2022) | Approx. $620 million | The bridge was controlled by 9 validator nodes, requiring 5 signatures. The attacker (later attributed by the US Treasury to the North Korean Lazarus Group) obtained the private keys of 4 nodes through social engineering, and used a previously authorized but never revoked signature permission to obtain the 5th. The theft was only discovered nearly a week later. |
| Wormhole (February 2022) | Approx. $320 million | The Solana-side contract, when verifying "Guardian signatures," called a deprecated system function that did not check the caller's origin. The attacker forged the verification result and minted 120,000 wETH out of thin air. |
| Nomad (August 2022) | Approx. $190 million | During a contract upgrade, the root of trust was initialized to 0, causing any message to be treated as verified. After the first attacker succeeded, hundreds of addresses copied his transaction, only changing the recipient address—"everyone rushed in to grab it." |
These three events correspond to three types of failure: key management, signature verification code, and upgrades and initialization.
Layer 3: Principles and Engineering
3.1 Verification Models
| Model | Who confirms "Assets were actually locked on Chain A" | Trust Assumption |
|---|---|---|
| Multi-sig / Committee | A group of signers | Signers above the threshold are honest and their private keys are secure |
| MPC / Threshold Signature | Same as above, but synthesizes a single signature | Same as above (see "Engineering Pitfalls of MPC Wallets") |
| Optimistic Verification | Defaults to trust, sets a challenge period; anyone can report fraud | At least one honest observer exists during the challenge period |
| Light Client / Zero-Knowledge Proof | The contract on Chain B directly verifies Chain A's block headers and consensus (or its ZK proof) | Only trusts the two chains themselves |
| Native Bridge (e.g., official L2 bridges) | Guaranteed by the L2's proof system | As secure as the L2 itself |
The further down you go, the closer you get to being "as secure as the chain itself," but the implementation becomes more complex and the cost higher.
3.2 Engineering details
- Signer De-correlation: Use different organizations, different regions, different infrastructures, and different operators to avoid a situation like Ronin, where 4 out of 5 signers were controlled by the same entity;
- Temporary permissions must expire and be revoked: Ronin's 5th signature came from a "temporary" authorization; the principle of least privilege directly determines success or failure here (see "Least Privilege and Key Management");
- Messages must be replay-protected: Every cross-chain message must carry a unique nonce, source chain ID, and target chain ID, and processed records must be kept (see "Signature Login and Replay Protection");
- Upgrades and initialization must be audited: The lesson from Nomad is that a seemingly harmless operation like "setting a value to 0" can invalidate all verifications (see "Upgradable Contracts and Admin Private Keys");
- Rate limiting and circuit breakers: Automatically pause if outflows exceed a certain threshold within a unit of time (see "Fail-closed"), turning the worst-case scenario from "everything stolen" to "only a portion stolen";
- Real-time monitoring: Ronin's theft was only discovered nearly a week later because no one was monitoring large outflows from the bridge.
3.3 What users should watch out for
- The "wrapped tokens" on a bridge (e.g., USDC.e on a certain chain) are only valuable as long as the bridge is secure. If the bridge is hacked, the wrapped tokens may instantly depeg;
- Prioritize using official native bridges or cross-chain methods provided by the asset issuer themselves (e.g., the native cross-chain protocol of a stablecoin issuer);
- Do not store large amounts of assets in a bridge for long periods;
- Before crossing chains, confirm that the recipient address on the target chain is indeed under your control (the same contract wallet address may not exist on another chain; see "EOA vs. Smart Contract Wallets").
Summary
| Layer | Key points |
|---|---|
| Essence | One chain must trust what happened on another chain; the verification component is the security |
| Why it attracts thieves | Concentrated funds; verification is weaker than the chain; dual-chain code; upgradability |
| Three types of failure | Key management (Ronin), Signature verification (Wormhole), Initialization (Nomad) |
| Defense | Signer de-correlation; expiring temporary permissions; Light Client / ZK; Rate limiting and monitoring |