The Verus-Ethereum bridge was marketed as the first non-custodial, trustless bridge in the industry. Three years after launch, attackers drained $11.58 million from it.

Three days earlier, THORChain halted all trading after a vault compromise drained over $10.7 million in protocol-owned funds across Bitcoin, Ethereum, BSC, and Base. User balances, THORChain said, were untouched.

The bridge problem isn't bugs - it's architecture

Then there's April, when DeFi lost more than $600 million across nearly 30 incidents, including the KelpDAO bridge exploit - $292 million stolen not from a smart contract bug, but from a single misconfigured bridge setting.

The tally is climbing. But I'm less interested in the scorecard than in the pattern underneath it.

The word that doesn't mean what you think

Cross-chain bridges are how crypto assets move between blockchains that don't natively talk to each other. You lock something on one chain, and a wrapped version appears on another. The bridge's job is to verify that the original asset really was locked, before releasing the equivalent on the other side.

That verification step is where everything falls apart.

In the KelpDAO case, the bridge was built on LayerZero, a messaging protocol that connects chains. LayerZero recommends using multiple decentralized verifiers to confirm cross-chain messages - like having several independent witnesses before you trust a document. KelpDAO configured it with one. One of one. A single point of failure dressed up in decentralized branding.

LayerZero had warned against this setup. KelpDAO used it anyway. Attackers - later attributed to North Korea's Lazarus Group by Chainalysis - exploited the single verifier, and the bridge released $292 million to an attacker-controlled wallet.

No bug. Just a design choice that concentrated all risk into a single key.

The Verus-Ethereum bridge is a different architecture - it uses cryptographic proofs and witness validators rather than LayerZero - but the structural question is the same: who really controls the gate? The bridge claimed trustlessness. The exploit suggests otherwise.

Why this keeps happening

Here's the uncomfortable part. Bridge exploits aren't rare accidents that happen when code is bad. They happen because bridge architecture forces a trade-off that nobody wants to admit out loud: you can have fast, cheap cross-chain movement, or you can have genuinely distributed verification. You can't reliably have both.

Multi-verifier setups are slower and more expensive to operate. Single or lightweight configurations are convenient. So protocols choose convenience, call it decentralized, and build $10 million, $100 million, $292 million of risk on top of a single key.

That's not a coding problem. It's an incentive problem. The protocols that sit between chains profit from making movement feel effortless. Verification that actually takes time and resources - distributed verification that requires multiple independent actors - gets in the way.

THORChain's architecture is worth mentioning here because it's different. THORChain operates through a network of operator nodes running vaults. The compromised vault drained protocol's own assets, not user deposits. That's a material distinction. In bridge exploits, the funds that vanish are usually locked user assets - your deposited ETH, your bridged tokens. THORChain's design insulated users even though the protocol itself took a $10 million hit. The operator network structure meant the damage was contained to the protocol's own reserves.

THORChain has since opened a $10 million compensation portal for affected counterparties. Whether that fully resolves the trust question remains to be seen.

The number the market ignores

DeFi has lost roughly $770 million to hacks in 2026 alone. April was the worst month in crypto history for exploits. May is already past $20 million before the Verus drain. The total industry figure - including centralized exchange breaches and token scams - exceeds $10 billion according to some trackers.

But the real number to watch isn't the total. It's the fact that bridges remain the most expensive failure point, consistently, year after year. They hold the most value precisely because they sit at the seams between chains - the plumbing nobody thinks about until it breaks.

The market treats each exploit as an isolated incident and moves on. Liquidity returns. Users bridge again. The same architecture stays in place.

What would actually fix this?

I don't have the answers, but I think the fix requires admitting something the industry prefers not to: the current bridge model is structurally incomplete. A bridge that can be operated with a single verifier and marketed as "trustless" isn't trustless. It's trust-minimized in the way that matters least - the code looks clean, but the key management concentrates all the risk.

Some teams are exploring more cryptographically verifiable models - lightweight client proofs that don't rely on a verifier network at all - but they're slower, more complex, and haven't gained mainstream traction. Others are building compositional safety layers, like reactive contract frameworks, that can auto-pause bridge activity when anomalies are detected. Those are useful insurance policies, but they don't solve the underlying architecture problem.

The question for anyone holding crypto across chains is simpler: do you trust the bridge, or do you trust the configuration the bridge is running on? If the answer to both is "I don't know," the $11.58 million in Verus and the $292 million in KelpDAO might start to feel less like bad luck and more like what the model was always priced to deliver.

I'll be watching whether the Verus team publishes a technical postmortem. That detail - whether the breach came from a compromised key, a flawed proof verification, or a configuration oversight - would tell us whether this is the same family of problem as KelpDAO, or something structurally different. Until then, the bridge problem remains what it's always been: a gap between the architecture DeFi promises and the single points of failure it actually runs on.