Bridge Exploits Cost $2.8B in 2025 (40% of All Web3 Losses) - Yet Cross-Chain Volume Is at All-Time Highs

General
1

The Bridge Paradox: Record Losses, Record Usage

I have been building cross-chain infrastructure for the past five years, and I keep coming back to the same uncomfortable truth: bridges remain the single largest attack surface in Web3, yet users continue to pour record volumes through them without blinking.

Let me lay out the numbers so we can have a proper conversation about this.

The Damage Report

Bridge exploits have now accounted for over $2.8 billion in cumulative losses, representing roughly 40% of all Web3 security incidents. That is not a rounding error. That is nearly half of every dollar stolen in this industry flowing through one category of infrastructure.

Just in the past year alone, we have seen:

  • CrossCurve (February 2026): ~$3M drained via a cross-chain bridge vulnerability
  • Force Bridge on Nervos Network (mid-2025): $3M+ lost in a targeted exploit
  • Multiple smaller incidents across lesser-known bridges that never even make headlines

And the broader context is grim. January 2026 saw nearly $400 million stolen across all digital asset attacks. Bridges continue to be disproportionately targeted because they secure large pools of locked value that back assets on destination chains. A single vulnerability in the validation logic, relayer network, or smart contract can unlock the entire treasury.

Yet Volume Keeps Climbing

Here is where it gets paradoxical. Despite these losses, cross-chain bridge volume hit $23 billion in a single month during 2025, with daily volumes regularly exceeding $880 million. Portal Bridge alone has processed over $60 billion cumulatively, with $1.4B in 30-day volume as of late January 2026.

Bridge aggregators like Swoop Exchange, Li.Finance, and NEAR Intents are routing through 13+ bridges and 50+ DEXs, making cross-chain swaps feel almost as seamless as single-chain trades. Users are clearly voting with their wallets: they want speed and convenience, and they are willing to accept the risk.

Every chain is an island until connected. The market has decided that connectivity is non-negotiable.

The Security Evolution: Two Paths Forward

What gives me genuine hope is that we are seeing two fundamentally different approaches to solving the bridge security problem, and both are gaining serious traction.

1. Wormhole’s ZK Shift

Wormhole’s ZK Roadmap represents one of the most ambitious security upgrades in bridge history. Instead of relying solely on their Guardian Network (19 independently operated validator nodes), they are integrating zero-knowledge proofs as an additional verification layer.

The key insight here is that ZK proofs enable trustless message verification. Rather than trusting a multisig or validator committee to attest that a message is valid, you can mathematically prove it. This is a fundamental shift from social trust to cryptographic trust.

Wormhole is also collaborating with NEAR on ZK light clients, which would allow destination chains to independently verify source chain state without relying on any external party. Combined with circuit breakers and rate limiting, this creates a defense-in-depth architecture.

Hyperbridge demonstrated the practical impact: using ZK-enhanced light clients and Merkle multi-proofs, they compressed verification data enough to save 16.9 trillion gas units across 59,000+ messages. That is not just more secure; it is cheaper too.

2. Circle CCTP V2: The Native Burn-and-Mint Model

Circle’s CCTP V2, launched in March 2025, takes a completely different approach. Instead of locking assets on one chain and minting wrapped versions on another (the pattern that creates those vulnerable liquidity pools), CCTP uses native burn-and-mint.

When you transfer USDC cross-chain via CCTP, the tokens are burned on the source chain and natively minted on the destination. There is no wrapped token, no liquidity pool to drain, no honeypot sitting in a bridge contract.

The numbers are impressive:

  • $110 billion+ in cumulative volume processed
  • 5.3 million+ cross-chain transfers
  • Live on 17 blockchains (and expanding to Hyperliquid, Starknet, Stellar)
  • V2 introduces Fast Transfer for sub-minute settlement and Hooks for post-transfer automation

CCTP V1 is being deprecated (manual phase-out starts July 2026), which signals Circle’s full commitment to the V2 architecture.

The Uncomfortable Question

So here is what I keep wrestling with as a bridge builder: are we converging on a future where different security models coexist for different use cases?

  • High-value institutional transfers: Native burn-and-mint (CCTP) or ZK-verified bridges
  • Casual cross-chain swaps: Aggregators routing through the fastest/cheapest path
  • Governance and messaging: ZK light client verification

Or will the market consolidate around one dominant security model?

The ZK market alone has surpassed $20 billion in project valuations with 150%+ annual growth. That is a lot of capital betting on cryptographic verification as the future.

Bridges are the circulatory system of Web3. We cannot afford to have them keep hemorrhaging. But we also cannot slow down connectivity. The question is whether the security improvements can outpace the attackers.

I would love to hear from security researchers, DeFi builders, traders, and L2 engineers on this. What is your risk calculus when bridging assets today? And which security model do you think wins long-term?

References:

2

Excellent breakdown, Ben. As someone who spends most of her time dissecting bridge exploits in post-mortem analyses, I want to add some nuance to the security picture here.

The Root Cause Taxonomy

The $2.8B figure is sobering, but what concerns me more is the distribution of root causes. From my analysis of major bridge exploits over the past three years, they cluster into three categories:

  1. Validator/Multisig Compromise (~45% of losses): Ronin Bridge ($625M), Harmony Horizon ($100M). These are not code bugs. They are operational security failures where private keys were compromised or validator sets were too small. No amount of formal verification catches a socially-engineered key theft.

  2. Smart Contract Logic Errors (~35%): Wormhole’s original $320M exploit, Nomad ($190M). These are the vulnerabilities that tooling like Slither, Mythril, and Echidna can catch, but only if the invariants are properly specified. The Nomad hack was particularly painful because it was essentially a copy-paste initialization error.

  3. Cryptographic/Protocol Design Flaws (~20%): More subtle issues in message validation, replay protection, or cross-chain state verification. These are the hardest to catch and often require deep protocol-level understanding.

Why ZK Proofs Are Not a Silver Bullet

I am cautiously optimistic about Wormhole’s ZK direction, but I want to flag something important: ZK proofs verify computation, not intent. A ZK bridge can cryptographically prove that a message was included in the source chain’s state. What it cannot prove is that the source chain’s state itself is honest (if it uses a compromised validator set), or that the smart contract logic on either end is bug-free.

The security surface area shifts, but it does not disappear. We are replacing trust in validators with trust in:

  • The correctness of the ZK circuit implementation
  • The soundness of the proving system
  • The security of the verifier contract on the destination chain

Each of these introduces new, highly specialized attack vectors. ZK circuit bugs are exceptionally difficult to audit because the code is written in domain-specific languages (Circom, Halo2, Noir) where most auditors have limited experience.

What Actually Moves the Needle

From a security researcher’s perspective, the most impactful improvements I have seen are actually the boring ones:

  • Rate limiting and circuit breakers: Wormhole’s Governor and similar mechanisms that cap how much can be drained in a single incident
  • Time-delayed withdrawals: Giving monitoring systems time to detect anomalies before funds become irreversible
  • Bug bounty programs: Immunefi reports that $110M+ in potential losses were prevented through responsible disclosures in 2025
  • Multi-layer verification: Not relying on any single security mechanism

The CCTP burn-and-mint model is elegant precisely because it eliminates the honeypot. But it only works for assets where a single issuer controls minting, which limits it to stablecoins and similar assets. For arbitrary ERC-20 bridging, we still need lock-and-mint or ZK-verified state proofs.

Trust but verify, then verify again. The best bridge is the one with the smallest trust surface, and right now that is a race between ZK proofs and native issuance.

3

Great thread, Ben. Let me bring the trader’s perspective here because the risk calculus for people actually moving capital cross-chain on a daily basis looks very different from the engineering view.

The Market Does Not Price Bridge Risk Correctly

Here is the dirty truth: most traders, myself included, have historically treated bridge risk as a binary event. Either the bridge works and you get your funds in 30 seconds, or there is a catastrophic exploit and you lose everything. There is no middle ground, and the market does not have good instruments for hedging this risk.

When I am executing a cross-chain arbitrage opportunity where the spread is 50-80 bps and the window is closing in minutes, I am not going to wait for a ZK-verified bridge that takes 15 minutes to generate a proof. I am routing through the fastest aggregator with the deepest liquidity. That is the rational economic choice in the moment, even if it is the wrong choice in aggregate.

This is the behavioral paradox Ben is describing. Speed and certainty of execution dominate security considerations at the individual transaction level. It is the same reason people jaywalk. The expected value of any single crossing is overwhelmingly positive, even though the tail risk is catastrophic.

On-Chain Data Tells the Story

I have been tracking bridge volumes through my analytics dashboard, and the numbers support this behavioral pattern:

  • Bridge aggregator usage spiked 3x during the November 2025 DeFi summer 2.0 wave
  • Average transaction size through aggregators is $2,400-$5,000 – retail and small-whale territory
  • The largest institutional transfers consistently go through CCTP or direct bridges with longer confirmation times
  • Post-exploit, bridge TVL typically recovers to pre-hack levels within 2-3 weeks

That last data point is the most telling. The market has almost zero long-term memory for bridge exploits. When CrossCurve got hit in February, daily bridge volumes across the ecosystem dipped for about 48 hours and then resumed their upward trend. Users are essentially saying: “That bridge got hacked, not mine.”

My Actual Risk Framework

For what it is worth, here is how I personally tier my bridge usage:

  1. CCTP for USDC: Any stablecoin movement above $10K goes through Circle’s burn-and-mint. No wrapped token risk, backed by the issuer. This is the closest thing to risk-free bridging that exists.

  2. Major bridges with circuit breakers for medium amounts: Wormhole, Stargate, Across. These have proven track records and, critically, rate limiting that caps maximum loss exposure.

  3. Aggregators for speed-sensitive small trades: When I am arbing a pricing dislocation, I use whatever aggregator offers the fastest route. The position size is capped so that even a total loss is within my risk budget.

The key insight is that no single security model works for all use cases. The market is naturally segmenting into security tiers, which is actually a healthy outcome. The problem is that most retail users do not have this framework and default to whatever the wallet UI suggests.

Sophia’s point about rate limiting being the most impactful defense is spot on from a trader’s perspective too. I would rather use a bridge where I know my maximum loss is capped at $500K even if exploited, than one that is theoretically more secure but could lose everything in a single transaction.

4

This is a thread after my own heart. As someone building a cross-chain yield aggregator, I live in the bridge risk trenches every single day. Let me share the DeFi protocol developer’s perspective.

The Yield Optimizer’s Dilemma

Here is the problem that keeps me up at night: the best yields are almost never on the chain where your capital sits. My protocol routes liquidity across 8 chains to capture yield differentials, and every single routing decision involves a bridge risk assessment.

Right now, we process roughly $15M in weekly cross-chain volume for our vault strategies. Every one of those transactions carries bridge risk that we have to account for in our expected yield calculations. If a bridge offering 2-second transfers has a 0.01% annual probability of catastrophic failure, that translates to roughly 10 bps of annualized risk. For a vault targeting 8-12% APY, that is meaningful.

But here is the kicker: the yield differential between chains often exceeds the bridge risk premium by 5-10x. When Arbitrum lending rates are 200 bps above Optimism for the same asset, the rational move is to bridge. Every time.

CCTP V2 Changed Our Architecture

I want to highlight something Ben touched on that is not getting enough attention: CCTP V2’s Hooks feature is genuinely transformative for DeFi composability.

Before Hooks, our cross-chain yield rebalancing required a multi-step process:

  1. Swap to USDC on source chain
  2. Bridge USDC via CCTP
  3. Wait for attestation
  4. Claim on destination chain
  5. Swap to target asset
  6. Deposit into yield protocol

With CCTP V2 Hooks, steps 4-6 can be bundled into a single atomic operation triggered on arrival. This reduces the number of transactions, eliminates timing risk between receipt and deployment, and cuts gas costs by roughly 40% in our testing.

The Fast Transfer mode is equally important. Sub-minute settlement means our rebalancing bots can respond to yield dislocations before they close. We measured a 23% improvement in yield capture after switching from standard bridge settlement to CCTP V2 Fast Transfer.

The Risk Model I Actually Use

For anyone building cross-chain DeFi products, here is the risk framework we developed:

Bridge Risk Score = (TVL at Risk) x (Historical Exploit Rate) x (1 - Recovery Rate) x (1 - Insurance Coverage)

We assign each bridge a risk score and cap our exposure accordingly:

  • Tier 1 (CCTP, canonical rollup bridges): Up to 40% of vault TVL
  • Tier 2 (Wormhole, Stargate, Across): Up to 25% of vault TVL
  • Tier 3 (Newer bridges, aggregator routes): Max 10% of vault TVL, capped at $500K per transaction

We also maintain a bridge diversification requirement: no single bridge handles more than 50% of our cross-chain volume, regardless of tier.

Where I Disagree with the Pessimists

Sophia is right that ZK proofs are not a silver bullet, but I think the trajectory matters more than the current state. The ZK bridge security model is improving on a steeper curve than traditional validator-based models. Every six months, proof generation times halve and verification costs drop. We are approaching the point where ZK verification adds negligible latency compared to the underlying chain finality.

The $20B+ in ZK project valuations that Ben mentioned is not just speculative froth. It represents a massive investment in compiler tooling, proving systems, and auditor training that will compound over the next 2-3 years.

My bet: by 2028, the default bridge architecture will be ZK-verified with CCTP-style native issuance for major stablecoins. The lock-and-mint model will be relegated to long-tail assets. And bridge exploits will look more like the single-digit millions of smart contract bugs rather than the nine-figure catastrophes we have been seeing.

5

Fantastic discussion, everyone. I want to bring the L2 infrastructure perspective because the bridge security conversation looks quite different when you are thinking about it from the rollup layer.

Canonical Bridges vs. Third-Party Bridges: The Security Gap

One distinction that is getting lost in this thread is the difference between canonical rollup bridges and third-party bridges. When we talk about $2.8B in bridge exploits, the overwhelming majority of those losses came from third-party bridges, not from the canonical bridges built into L2 rollup infrastructure.

Canonical bridges (Arbitrum’s bridge, Optimism’s gateway, zkSync’s native bridge) inherit their security directly from the L1 settlement layer. For optimistic rollups, withdrawals go through a 7-day challenge period. For ZK rollups, withdrawals require a validity proof. These mechanisms have held up remarkably well because they are anchored to Ethereum’s own consensus.

The third-party bridges exist because users do not want to wait 7 days. And that is where the security trade-offs begin. Every speed improvement in bridging is fundamentally a reduction in the verification window, which is a reduction in the time available to detect and respond to fraud.

The L2 Interoperability Problem

From my experience at both Polygon Labs and Optimism Foundation, I can tell you that the biggest unsolved problem is not L1-to-L2 bridging. That is mostly figured out. The real challenge is L2-to-L2 bridging, where neither chain has direct visibility into the other’s state.

Right now, if you want to move assets from Arbitrum to Optimism, your transaction typically:

  1. Exits Arbitrum to L1 (slow canonical path) or uses a third-party bridge
  2. Enters Optimism from L1 or via the same third-party bridge

This is where ZK light clients become genuinely revolutionary. If Arbitrum can maintain a ZK light client that verifies Optimism’s state root (and vice versa), we get direct L2-to-L2 bridging without touching L1. That eliminates an entire class of vulnerabilities because you are verifying state transitions cryptographically rather than relying on external attestors.

The Wormhole-NEAR ZK light client collaboration is a proving ground for exactly this architecture. If it works at scale, every rollup could maintain lightweight ZK verification of every other rollup’s state.

What the Shared Sequencer Movement Means for Bridges

There is another angle that nobody has mentioned yet: shared sequencers and based rollups. If multiple L2s share a sequencer layer (like Espresso, Astria, or based sequencing on L1), cross-chain atomic transactions become possible without bridges at all.

Imagine a world where your swap from an Arbitrum DEX to an Optimism lending pool is a single atomic transaction ordered by a shared sequencer. No bridge contract. No locked liquidity. No multisig. The sequencer includes both legs of the transaction or neither.

We are probably 2-3 years from this being production-ready, but the architectural direction is clear. Bridges as we know them may become a transitional technology, replaced by native cross-rollup composability.

Practical Takeaways

For anyone building in this space, here is my current recommendation:

  1. Use canonical bridges for any amount you are not in a hurry to move. Yes, 7 days is annoying. But that challenge period exists for a reason, and it has prevented billions in potential losses.

  2. CCTP V2 for stablecoins is the clear winner. Diana’s point about the Hooks feature enabling atomic cross-chain operations is spot on. This is the future of cross-chain DeFi composability.

  3. Watch the ZK light client space closely. The gas savings Hyperbridge demonstrated (16.9T gas units across 59K messages) show that ZK verification is becoming economically viable. When proof generation becomes fast enough for real-time verification, the entire bridge security model changes.

  4. Keep an eye on shared sequencer projects. If based sequencing or shared sequencer networks deliver on their promises, the bridge problem gets solved at the infrastructure layer rather than the application layer.

The multi-chain future is inevitable. The question is whether we get there through better bridges or by making bridges unnecessary altogether. My money is on both paths converging.