SolutionsProductsAuditsBlogContactRequest an Audit
Blog$292 Million Gone in 46 Minutes. Kelp DAO's Bridge Had One Verifier.
$292 Million Gone in 46 Minutes. Kelp DAO's Bridge Had One Verifier.
hack-analysis9 min readApril 18, 2026
0xTeam Author
Share

$292 Million Gone in 46 Minutes. Kelp DAO's Bridge Had One Verifier.

LayerZero's documentation said to use multiple DVNs. Kelp used one. The attacker compromised it, forged cross-chain messages, and drained 116,500 rsETH — triggering $6.6B in contagion across DeFi.

Two weeks after Drift. Same month. Different attack vector. Bigger number.

On April 18, the largest DeFi hack of 2026 happened — not through a smart contract bug, not through social engineering, not through a compromised key. Through a single checkbox that was never ticked.

Kelp DAO's cross-chain bridge ran with one verifier confirming every transaction. LayerZero had warned them to use multiple. The documentation said to use multiple. The integration checklist said to use multiple. Kelp used one. The attacker compromised that one. And walked out with $292 million in rsETH.

What Kelp DAO Was and Why It Mattered

Kelp DAO is a liquid restaking protocol. Users deposit staked ETH — stETH, cbETH — and receive rsETH in return. rsETH earns rewards and can be used across other DeFi applications.

The critical detail: rsETH was deployed across more than 20 networks — Base, Arbitrum, Linea, Blast, Mantle, Scroll. LayerZero's OFT standard handled the cross-chain movement. The bridge held the ETH reserves backing every wrapped version of rsETH on every L2.

That bridge was the single point of failure for the entire protocol. When it was drained, every holder of rsETH across 20+ networks faced the same question instantly: is there anything backing my token?

How the Attack Worked

LayerZero uses DVNs — Decentralized Verifier Networks — to confirm whether a cross-chain message is legitimate before the destination chain releases funds. The security of the bridge depends entirely on the DVN configuration.

Kelp's bridge ran a 1-of-1 DVN configuration. One verifier. No redundancy. No consensus required.

  1. Compromise the RPC nodes: The attacker targeted two of the RPC nodes used by LayerZero's DVN to read chain state. With those nodes compromised, the DVN could be fed false data about what was happening on the source chain.
  2. DDoS the clean servers: The remaining uncompromised verification servers were taken offline through a distributed denial-of-service attack. The DVN's failover logic kicked in — and failed over to the already-compromised nodes.
  3. Forge the cross-chain message: With the DVN now operating entirely on attacker-controlled nodes, the attacker sent a fabricated cross-chain message. The compromised DVN confirmed it as legitimate. LayerZero's protocol had no way to know — it worked exactly as designed.
  4. Drain the bridge: The forged message instructed the bridge to release 116,500 rsETH to an attacker-controlled address. First transaction at 17:35 UTC. Emergency pause at 18:21 UTC. 46 minutes. $292 million. Two follow-up attempts for another $100M were blocked by the pause. Total losses would have been $391M.

The Blame Game — LayerZero vs Kelp

LayerZero's Position

Kelp chose the 1-of-1 DVN configuration. LayerZero's integration checklist explicitly recommends multi-verifier setups. LayerZero communicated this directly to Kelp. The core protocol worked correctly. Every application running multi-verifier configurations was completely unaffected. Going forward, LayerZero will refuse to sign messages for any project running single-verifier config.

Kelp's Position

LayerZero's DVN failover logic should not have routed to compromised nodes. A properly designed failover system would have halted rather than degraded to a compromised state. The failover behavior — not the configuration choice alone — was the failure.

Both positions have merit. Together they expose the real problem: when modular infrastructure allows flexible security configurations, "flexible" means teams can configure themselves into catastrophic single points of failure — and the infrastructure provider cannot stop them.

What Actually Failed — The Real List

Single Verifier by Choice

A 1-of-1 DVN is architecturally equivalent to a 1-of-1 multisig with no timelock. The documentation said not to do this. Kelp did it anyway.

No Minimum Security Standard Enforcement

LayerZero allowed Kelp to deploy with a configuration the documentation described as insecure. A protocol that permits single-verifier configurations in production without a hard block accepts that its most insecure integrations define its worst-case risk.

Failover That Degraded Instead of Halting

DVN failover logic that routes to unverified nodes instead of stopping is a vulnerability by design. Take down the honest nodes. DDoS the rest. Own the verification layer. This attack vector only exists because failover was designed to continue at all costs.

Bridge as Concentrated Risk

The entire cross-chain reserve — backing rsETH on 20+ networks — sat in one contract. One exploit location. Total blast radius across the entire ecosystem.

No Circuit Breaker on Anomalous Volume

116,500 rsETH moved in a single transaction — 18% of total supply. A circuit breaker pausing on single-transaction movements above a threshold would have stopped this. The pause came 46 minutes after the fact.

What Should Have Been Built

  • Multi-DVN requirement: Require consensus across at least 3 independent DVNs. An attacker needs to compromise all of them simultaneously. The attack vector disappears.
  • Halt, don't degrade: When quorum cannot be established across clean nodes, the correct behavior is to stop — not route through whatever infrastructure is available.
  • Circuit breaker on volume: Any single transaction representing more than 5% of bridged supply triggers an automatic pause and alert. 46 minutes becomes 46 seconds.
  • Split reserves: Reserve assets backing cross-chain tokens should not sit in a single bridge contract. Distribute the single point of failure.
  • Collateral risk modeling: Lending protocols accepting rsETH as collateral should model what happens to their protocol if the rsETH bridge is drained overnight. That model should inform caps and collateral factors.

LayerZero said the protocol worked correctly. Kelp said they followed the available guidance. Nine other protocols said they were just using available collateral. And $292 million was still stolen, $6.6 billion in TVL disappeared in a day, and rsETH holders across 20 networks went to sleep not knowing if their tokens had anything underneath them.

Everyone followed the rules. The rules were not enough. The bridges are where the money is. They are also where the security standards are the most inconsistently applied. That combination is not an accident waiting to happen. It is happening, systematically, every month.
++
Worried? Get your security audit done today.

Don't launch vulnerable code. Our team will review your smart contracts and deliver a full audit report within 48 hours.

Request Audit

Tags

hack-analysisDeFiSecurityWeb3

Get Audited

Protect your protocol before attackers do. Request a full smart contract audit from 0xTeam.

Request Audit
© 0xTeam space 2026. All rights reserved.