Skip to content

Bridges

Blockchains are isolated systems. Your ETH on Ethereum cannot natively talk to Solana, and your SOL cannot interact with Arbitrum. Cross-chain bridges attempt to solve this by enabling asset transfers between networks—but they do so by introducing trust assumptions that have cost users billions.

TL;DR

  • Bridges connect isolated blockchains, enabling asset transfers between networks
  • Most bridges use a "lock and mint" model: lock tokens on Chain A, mint wrapped tokens on Chain B
  • Bridges are honeypots—$2.8B+ stolen since 2022, accounting for 69% of DeFi hacks in peak years
  • Trust varies: validator bridges require trusting a committee; native verification is most trustless
  • Private key compromise (not smart contract bugs) is the leading attack vector
  • When using a bridge, you're trusting: the validators, the smart contracts, and the wrapped token's backing
  • Canonical bridges (run by L2s themselves) are generally safer than third-party bridges

What Is a Bridge?

A cross-chain bridge is infrastructure that transfers assets or data between two blockchains that cannot otherwise communicate. Think of it as a courier service: you give your ETH to the courier on Ethereum, and they hand you an equivalent receipt (wrapped ETH) on Arbitrum.

The problem: you have to trust the courier.

flowchart LR
    subgraph Ethereum
        A[User Wallet]
        B[Bridge Contract]
    end

    subgraph Validators/Relayers
        C[Verification Layer]
    end

    subgraph Solana
        D[Bridge Contract]
        E[User Wallet]
    end

    A -->|1. Lock ETH| B
    B -->|2. Emit Event| C
    C -->|3. Verify & Relay| D
    D -->|4. Mint wETH| E

Figure 1: Simplified bridge flow showing lock on source chain and mint on destination chain.

How Bridges Work

The Three Mechanisms

MECHANISM PROCESS REVERSING EXAMPLE
Lock & Mint Lock original on Chain A, mint wrapped on Chain B Burn wrapped, unlock original Wormhole, most bridges
Burn & Mint Burn native on Chain A, mint native on Chain B Same process in reverse Circle CCTP (USDC)
Lock & Unlock Lock on Chain A, unlock from liquidity pool on Chain B Same process in reverse Across Protocol

Step-by-Step: Lock and Mint

  1. Initiate - User calls bridge contract on source chain with tokens to transfer
  2. Lock - Bridge contract locks tokens, removing them from circulation
  3. Verify - Validators/relayers confirm the lock transaction occurred
  4. Relay - Proof of lock is transmitted to destination chain
  5. Mint - Bridge contract on destination mints equivalent wrapped tokens
  6. Receive - User receives wrapped tokens on destination chain

The wrapped token (wETH, wBTC) is an IOU. Its value depends entirely on the bridge's ability to honor redemptions.

Trust Spectrum

Bridges exist on a spectrum from fully trusted (you trust a company) to trust-minimized (you trust math and code). No bridge is fully trustless—there's always some trust assumption.

TYPE TRUST MODEL SECURITY EXAMPLES
Centralized/Custodial Trust the operator completely Lowest—operator can rug Exchange bridges (deposit on Coinbase, withdraw on Base)
Federated/Validator Trust majority of validator set Medium—requires collusion Wormhole, Multichain
Optimistic Trust that 1 honest watcher exists Higher—fraud proofs Across, Connext
Native/On-Chain Trust source/destination chain security Highest—no new assumptions Cosmos IBC, Rollup bridges
ZK-Verified Trust math (cryptographic proofs) Highest (theoretical)—few production implementations zkBridge (experimental)

Verification Methods

External Verification (Most Common)

A committee of validators attests to cross-chain events. Security depends on honest majority assumption. If attackers compromise enough validators (or their keys), funds are gone.

Optimistic Verification

Assumes transactions are valid unless challenged. Watchers monitor for fraud and can block malicious transactions within a challenge window. Only requires one honest watcher.

Native Verification

Uses the destination chain's own consensus to verify source chain state. No additional trust assumptions beyond the chains themselves. Cosmos IBC is the canonical example.

The Graveyard: Major Bridge Hacks

BRIDGE DATE LOSS ATTACK VECTOR
Ronin Mar 2022 $625M 5 of 9 validator keys compromised via social engineering
Wormhole Feb 2022 $321M Smart contract bug—forged signatures to mint unbacked tokens
Nomad Aug 2022 $190M Smart contract bug—anyone could pass validation
Harmony Horizon Jun 2022 $100M 2 of 5 multisig keys compromised
Multichain Jul 2023 $126M CEO's keys compromised/extracted
Orbit Chain Jan 2024 $81M 7 of 10 signer keys compromised
Ronin (again) Aug 2024 $12M Upgrade bug in vote threshold logic (proxy initialization failure)

Proxy Contract Vulnerabilities

Many bridge exploits involve Proxy Contract bugs, especially uninitialized implementations and upgrade logic failures. The Ronin 2024 exploit resulted from skipping proxy initialization during an upgrade. See Proxy Contracts & Upgradeability for technical details on these vulnerabilities.

Pattern: Private key compromise dominates. Social engineering, insider threats, and operational security failures—not code exploits—are the primary attack vectors.

Risks

For Users

RISK DESCRIPTION
Bridge insolvency If bridge is hacked, your wrapped tokens become worthless IOUs
Censorship Validator sets can refuse to process your transactions
Stuck funds Bridge goes offline, your assets are locked indefinitely
Smart contract bugs Code vulnerabilities can drain locked funds
Wrapped token depeg Market loses confidence, wrapped token trades below backing

For the Ecosystem

RISK DESCRIPTION
Contagion Bridge hack impacts all chains it connects
Fragmented liquidity Same asset exists as multiple wrapped versions
Trust consolidation Few bridges handle most volume—single points of failure

What to Watch For

When evaluating a bridge:

  • ☑ Native/canonical bridge run by the L2 team
  • ☑ Large, distributed validator set (not 5-of-9)
  • ☑ Time-tested with significant TVL over years (Lindy Effect)
  • ☑ Bug bounty program and regular audits
  • ☑ Transparent incident response history
  • ☑ Insurance or recovery fund for exploits
  • ☒ Small multisig (less than 7 signers)
  • ☒ Unknown or anonymous validator set
  • ☒ No audit history
  • ☒ New bridge with high yield incentives (often masks risk)
  • ☒ Single point of failure (one company controls keys)

Practical Guidance

  1. Use canonical bridges when possible - Arbitrum's bridge, Optimism's bridge, Base's bridge. They inherit L1 security.

  2. Minimize bridge exposure - Don't leave large amounts in wrapped tokens. Bridge, use, bridge back.

  3. Check wrapped token backing - Is the bridge's locked collateral verifiable on-chain?

  4. Diversify bridge risk - If you must hold wrapped assets, don't rely on a single bridge.

  5. Watch for red flags - Sudden TVL drops, validator disputes, delayed transactions.

References

Changelog

DATE AUTHOR NOTES
2026-01-04 Artificial. Generated by robots.
2026-01-08 Denizen. Reviewed, edited, and curated by humans.