Home › Bridge Risks

Bridges: Crypto's Most-Attacked Surface

If you hold any wrapped, bridged or cross-chain version of an LST or LRT, the bridge securing it is almost certainly the weakest part of your stack. More dollars have been stolen from bridges than from any other class of DeFi protocol — and the largest 2026 incident, the KelpDAO exploit, was a bridge failure.

Guide 11 min read Updated April 2026

Why bridges exist

Most blockchains can't talk to each other. Ethereum has no idea what happened on Solana; Polkadot has no idea what happened on Bitcoin. Bridges are the protocols that move value or messages from one chain to another by some mechanism — locking assets on one side and minting representations on the other, attesting events to a destination chain, or relaying arbitrary messages.

For a staker, bridges show up everywhere: an LST native to Ethereum is bridged to L2s for DeFi use; a Cosmos asset is bridged to Ethereum to access deeper liquidity; an LRT mints across 20+ chains. The convenience is real. So is the trust assumption you've added.

Bridge architectures

Almost all production bridges fall into one of these patterns. They differ in where they place the trust assumption.

Lock-and-mint

Most common pattern

Source-chain contract locks the asset; a verifier set tells the destination chain to mint a wrapped version. Burn-the-wrapped to unlock the original. Trust: the verifier set.

Medium-high trust

Burn-and-mint

Native multi-chain tokens

The token exists natively on every chain; transferring burns on source and mints on destination. Used by USDC's CCTP, OFTs, and most modern LST/LRT bridges. Trust: still the verifier set.

Medium-high trust

Liquidity-network (atomic swap)

e.g. THORChain, Connext

No wrapping. Liquidity providers on each chain swap user funds. Trust: LP solvency + protocol consensus, but no minted IOUs to inflate.

Lower mint risk

Optimistic bridges

e.g. Nomad, Across

Messages assumed valid unless challenged within a window. Fast UX, but window must be long enough for honest watchers to act. Trust: at least one honest watcher.

Medium trust

Light-client / ZK bridges

e.g. zkBridge, Succinct, IBC, Polymer

Destination chain verifies proofs of source-chain consensus directly. Cryptographic, no human committee. Trust: the source chain's consensus + circuit correctness.

Lowest trust (in theory)

External-validator bridges

e.g. Wormhole guardians, Axelar validators

A separate validator network signs cross-chain messages. Trust: that validator set's threshold and key security.

Medium-high trust

Configurable verifiers (DVNs)

e.g. LayerZero v2, Hyperlane ISMs

Each application picks its own verifier set, threshold, and executor. Powerful, but exposure depends entirely on the chosen config — this is what failed in the KelpDAO exploit.

Trust = whatever app chose

Multi-sig / federated bridges

Older or "centralized" bridges

A small group of signers (often a 5-of-9 multisig) approves transfers. Easy to ship; one of the most-exploited categories historically. Trust: those signers personally.

High trust

Trust models, plainly

Every bridge boils down to one question: who decides whether a cross-chain message is real?

  • Cryptographic — math decides. ZK and light-client bridges. The trust is in code and the source chain's consensus.
  • Economic — a bonded validator set decides, and stands to lose a bond if wrong. Most modern bridges aspire to this.
  • Reputational — a multisig of named entities decides. Their reputations are the trust.
  • Optimistic — a single proposer claims, and any honest party can challenge. Trust shifts from "many" to "at least one".
Read the docs, not the marketing

Many bridges advertise their maximum security mode while shipping with much weaker defaults. LayerZero supports multi-DVN setups; KelpDAO ran 1-of-1. Wormhole supports 13-of-19 guardians; some integrations sit behind smaller subsets. Always check what the application actually configured.

Historical bridge exploits

By aggregate dollars, bridges are the largest source of crypto theft. A non-exhaustive Hall of Shame:

DateTargetLossRoot cause
Mar 2022Ronin Bridge (Axie)$625M5-of-9 validator keys compromised; 4 controlled by Sky Mavis. Lazarus Group attribution.
Feb 2022Wormhole$326MSmart-contract bug in signature verification on the Solana side allowed forged guardian signatures.
Aug 2022Nomad$190MMisconfigured initialization marked an empty root as valid; anyone could replay messages with their own address.
Sep 2022Wintermute (BNB cross-chain)$160MVulnerability in BSC's cross-chain bridge proof verification; forged proof minted BNB.
Jul 2023Multichain$126MCentralised key custody; sole CTO disappeared, contracts drained.
Jun 2022Harmony Horizon$100M2-of-5 multisig keys compromised. Lazarus Group attribution.
Aug 2021Poly Network$611MBug in cross-chain manager allowed attacker to assign themselves keeper privileges. Funds returned.
Apr 2026KelpDAO · LayerZero$292M1-of-1 DVN; verifier RPC nodes compromised, fake burn message accepted, unbacked rsETH minted. Full case study →

The pattern is striking: in nearly every case the smart contract worked, but the verification or key infrastructure failed — multisigs compromised, guardian keys leaked, RPC feeds poisoned, initialization misconfigured.

Why bridges get hit so often

  1. They concentrate value. A bridge's contract holds the entire wrapped supply. One compromise = nine-figure prize.
  2. The attack surface spans off-chain infrastructure. Validator nodes, RPC providers, key custody — all things smart-contract audits don't see.
  3. They sit at the integration boundary. Each chain has its own quirks; differences in finality, signature schemes, replay protection or initialization rules create gaps.
  4. Mistakes look identical to legitimate operations. A successfully-forged bridge message is, by definition, indistinguishable from a real one until someone checks the source chain.
  5. State-level adversaries are interested. The Lazarus Group alone is associated with multiple bridge exploits worth more than $1.5B combined.

How to evaluate a bridge

If you're holding any bridged token — or considering one — work through this:

  1. Architecture. Light-client / ZK > bonded validators > optimistic > reputational multi-sig. All else equal.
  2. Verifier set composition. How many independent parties? Are they geographically and operationally diverse? Are their public keys unique to this role?
  3. Threshold. 1-of-1 is unacceptable for any meaningful TVL. 2-of-3, 3-of-5 still concentrated. Look for thresholds where compromising a majority is expensive.
  4. RPC / infrastructure diversity. Verifiers reading the same RPC provider have correlated failure modes. The KelpDAO incident exploited exactly this.
  5. Pre-crime / circuit-breakers. Some bridges (Chainlink CCIP, LayerZero with pre-crime) sanity-check messages against expected token flows before delivering.
  6. Timelocks on mint/redeem. A 24h delay turns most bridge attacks from "$300M stolen" into "$300M frozen and recovered".
  7. Per-window throughput caps. Caps on how much value can flow per hour limit blast radius.
  8. Audit and operational track record. Multiple firms, recent re-audits, public bug bounties, and an actual incident-response history.
  9. Application-level configuration. Most modern bridges (LayerZero, Hyperlane, Wormhole) let each application customise. The bridge brand is not the security model — the chosen config is.
  10. Insurance / cover. Some bridges purchase or self-insure cover for users. Note the cap and trigger conditions.

Practical advice for stakers

  • Know which version of your token you're holding. Native stETH on Ethereum and bridged stETH on an L2 are not the same asset. The L2 version is a wrapped IOU governed by a bridge.
  • Avoid bridged-LST collateral on lending markets unless you trust the bridge. A bridge mint exploit can liquidate your position before you can react. Aave's rsETH freeze in April 2026 was the right call — but only available to people in lender-controlled markets.
  • Don't loop bridged LRTs. The KelpDAO incident showed how looped, bridged LRT positions amplify a verifier compromise into total liquidation.
  • Prefer canonical or chain-secured bridges where possible. Native rollup bridges (Optimism, Arbitrum, etc. for L1↔L2) are secured by the rollup itself, not an external committee.
  • Pay attention to per-app configuration. "It's on LayerZero" tells you almost nothing. "It's on LayerZero with a 3-of-5 DVN, including Polyhedra and Google Cloud, with a 12-hour timelock and pre-crime checks" is a security statement.
  • Diversify across architectures, not brands. Holding bridged tokens across two LayerZero integrations is correlated risk. Holding one through LayerZero and one through a ZK bridge is not.
Bottom line

If you wouldn't trust your stake to a 1-of-1 multisig run by a single ops team's RPC infrastructure, you shouldn't trust it to a 1-of-1 DVN running on the same RPC infrastructure. The structure is identical; the marketing is different.