Bridges
In one line
Section titled “In one line”A bridge is a pair of contracts, one on each chain, plus something off-chain that tells chain B what happened on chain A. That “something” is the whole security model.
Why it exists
Section titled “Why it exists”Chains cannot see each other. Ethereum has no idea what happened on Arbitrum or on Solana. As soon as there was more than one chain worth using (L2s from 2020 onwards, see Basics), people needed to move assets between them, and every bridge had to answer one question: who is allowed to say “it was locked over there”?
That is why bridges top every list of the largest hacks. A bridge is a message bus where whoever forges a message gets paid, and the vault behind it holds everything that was ever bridged.
How it works
Section titled “How it works”Lock and mint, the classic design:
- The user deposits 100 USDC into the bridge vault contract on chain A. The vault holds the real USDC and emits an event.
- Off-chain verifiers watch chain A, see the event, and sign a message: “100 locked for this user”.
- Someone delivers the signed message to the bridge minter contract on chain B.
- The minter checks the signatures and mints 100 wrapped USDC (wUSDC) to the user on chain B.
- To go back, the user burns the wUSDC on chain B, the verifiers attest the burn, and the vault on chain A releases the real USDC.
Three places to attack, as the figure shows:
- The vault. Drain it and every wrapped token on the other side is worth nothing.
- The verifiers. Steal enough keys, or poison the RPC nodes they read from, and they sign a lie.
- The minter’s check. Find a way to pass verification without valid signatures, and you mint without a lock.
Compare
Section titled “Compare”Bridge designs
Section titled “Bridge designs”| Design | How it works | What you hold on chain B | Risk you carry | Example |
|---|---|---|---|---|
| Lock and mint | Lock on A, mint a wrapped copy on B, burn to go back | A wrapped IOU | Bridge risk forever: a hack years later still wipes out the wrapped token | Most third-party bridges |
| Burn and mint | The issuer itself burns on A and mints on B | The native token | The issuer’s attestation service. No wrapped copy, no vault to drain. Prefer it for stablecoins | Circle’s CCTP for USDC |
| Liquidity / intents | A market maker pays you on B from its own funds right away and gets repaid on A later | The native token | Solver and settlement risk for minutes, not vault risk for years | Across-style bridges |
| Rollup canonical bridge | The L2’s own bridge back to Ethereum | The L2’s canonical token | The rollup’s proof system. Optimistic rollups make withdrawals wait about 7 days for fraud proofs | Arbitrum, Optimism, Base native bridges |
Who decides “it was locked”
Section titled “Who decides “it was locked””This is the real question. Weakest to strongest:
| Verification | How it works | Fails when | Example |
|---|---|---|---|
| Small multisig | M of N known keys sign each message. | M keys are stolen, often from one organisation. | Ronin 5 of 9, Harmony 2 of 5 |
| Single verifier | One service attests; cheap and fast. | That one service or its RPC is compromised. | KelpDAO, 1-of-1 DVN |
| Several independent verifier networks | Messages need several separate networks to agree (LayerZero DVNs, Chainlink CCIP plus a risk network). | They share infrastructure, code or an operator. | Configurable; Kelp is reported to have downgraded |
| Optimistic | Messages pass unless someone proves fraud in a window. | Nobody watches, or the check itself is broken. | Nomad (bad root) |
| Light client / ZK proof | Chain B verifies chain A’s consensus or a proof of it. | A bug in the verifier code. | IBC, ZK light clients |
DVN stands for decentralised verifier network, LayerZero’s name for a verifier.
Incidents
Section titled “Incidents”Loss figures are approximate, at the time of the attack.
| Incident | Loss | What broke | Lesson |
|---|---|---|---|
| Poly Network, 2021 | about $611M | A cross-chain message could call the function that replaced the verifier keys. | Messages must never reach admin functions. (Funds returned.) |
| Wormhole, 2022 | about $325M | Signature verification on Solana accepted a spoofed system account, so fake signatures passed. | The check that mints is the crown jewel; fuzz and formally verify it. |
| Ronin, 2022 | about $625M | 5 of 9 validator keys, most held by one company, one through a fake job offer. Noticed six days later. | Key diversity across organisations; outflow alerts in minutes. |
| Harmony, 2022 | about $100M | 2 of 5 multisig keys stolen. | A 2-of-5 is not a security model for nine figures. |
| Nomad, 2022 | about $190M | An upgrade marked the zero root as trusted, so any message passed. Hundreds copied the first attacker’s transaction. | Review upgrades and initial values like code; invariant tests. |
| Multichain, 2023 | about $126M | “MPC” keys effectively controlled by one person, who was detained. | MPC with one human behind every share is a single key. |
| Orbit Chain, 2024 | about $81M | 7 of 10 multisig keys compromised. | Same as Ronin. |
| KelpDAO, 2026 | about $292M | Single verifier; its RPC was poisoned to attest a fake message. | Independent verifiers on independent infrastructure. |
What breaks
Section titled “What breaks”| Symptom | Cause | Check |
|---|---|---|
| More wrapped tokens exist on B than are locked on A | A forged message minted without a lock | cast call $WRAPPED "totalSupply()(uint256)" --rpc-url $RPC_B against cast call $TOKEN "balanceOf(address)(uint256)" $VAULT --rpc-url $RPC_A |
| The vault empties in a few transactions | Verifier keys or the minter’s check were compromised | Outflow alert against a baseline; rate limit on releases |
| A wrapped token trades far below the native one | The market doubts the vault | Compare the vault balance with the wrapped supply as above |
| A message was accepted that no honest verifier signed | Verification can be skipped (zero root, spoofed account) | Invariant test: “no mint without a valid proof”, run on every upgrade |
| A verifier attested an event that is not on chain A | Its RPC was poisoned | Verifiers on independent RPC; compare block hashes across providers. See Chain mechanics. |
| A bridge admin function was called by a bridge message | Messages can reach admin functions | Allowlist what a message may call; separate admin path with a timelock |
Controls for anything that operates or depends on a bridge:
- Rate limits per time window on what the bridge can release.
- A delay plus manual review above a threshold.
- Several independent verifiers on separate infrastructure and separate keys.
- A reconciliation job that checks “minted on B ≤ locked on A” every block and pages on drift.
- A pause switch. See Defence stack.
- Treat bridged tokens as a riskier collateral class than native ones.
What to evaluate before accepting a bridge’s tokens as collateral: who attests the lock, how many independent parties on how much separate infrastructure, whether releases are rate limited and delayed, who can upgrade the bridge contracts and with what timelock, and whether the issuer offers a burn-and-mint path instead.
Keywords
Section titled “Keywords”bridge, cross-chain, lock and mint, burn and mint, wrapped token, wUSDC, bridge vault, minter, verifier, attestation, guardian, validator set, multisig bridge, DVN, decentralised verifier network, LayerZero, Chainlink CCIP, risk management network, CCTP, Circle, intents, solver, Across, canonical bridge, rollup bridge, optimistic bridge, fraud window, light client, ZK light client, IBC, zero root, message forgery, rate limit, release delay, reconciliation, pause, Poly Network, Wormhole, Ronin, Harmony, Nomad, Multichain, Orbit Chain, KelpDAO, rsETH.