What is Kelp DAO

Kelp DAO is a liquid restaking protocol built on EigenLayer. The mechanism works as follows: users deposit ETH or liquid staking tokens (stETH, ETHx) into the Kelp contract, which then delegates these assets to EigenLayer’s operator nodes for restaking—providing security to multiple AVSs (Actively Validated Services). In return, users receive rsETH as a receipt token. Unlike direct restaking on EigenLayer (where assets are locked), rsETH is liquid—it can be traded, used as collateral in lending protocols like Aave, and bridged across chains.

To enable this cross-chain liquidity, Kelp deploys rsETH on over 16 chains using LayerZero’s OFT (Omnichain Fungible Token) standard. When rsETH is bridged from Ethereum to an L2 chain, LayerZero’s DVN (Decentralized Verifier Network) validates the legitimacy of the cross-chain message. This bridge architecture is central to the narrative that follows.

Kelp was launched by Amitej Gajjala and Dheeraj Borra (formerly co-founder of Stader Labs) in December 2023, with peak TVL reaching $2.09 billion. Governance employs a 6/8 multisig with a 10-day contract upgrade timelock. The governance token KERNEL oversees three product lines: Kelp, Kernel, and Gain.

The Exploit Incident

On April 18, 2026, attackers drained 116,500 rsETH from Kelp DAO’s cross-chain bridge—worth approximately $292 million—making it the largest DeFi exploit to date in 2026. The root cause was not a smart contract vulnerability but a misconfiguration: a 1-of-1 DVN setup (i.e., only one validator node, requiring just one signature to approve) allowed the attacker to forge cross-chain messages using a single compromised node.

Twelve days earlier, on April 6, my open-source security audit tool had already flagged this attack vector.

Let me state clearly: this theft caused real financial losses for real people. Aave WETH depositors who had never touched rsETH had their funds frozen; multiple LPs across protocols were forced to bear bad debt they never consented to. This article analyzes what happened, what our tool captured—but the actual cost to users far exceeds any risk score.

The full report is hosted on GitHub, with immutable commit timestamps anyone can verify. Below, I’ll detail what we caught, what we missed, and what this means for DeFi security tooling.

46 Minutes, DeFi Shaken

At 17:35 UTC on April 18, the attacker breached the isolated DVN validator node and coerced it into "approving" a forged cross-chain message. LayerZero’s Endpoint detected the DVN approval and relayed the message via lzReceive to Kelp’s OFT contract—on Ethereum mainnet, the contract minted 116,500 rsETH. The message claimed equivalent assets were locked on other chains as collateral—assets that never existed.

Then followed a standard DeFi money-laundering flow:

46 minutes later, at 18:21, Kelp’s emergency pause multisig froze the contract. The attacker attempted two additional withdrawals (each ~40,000 rsETH, ~$100 million), both reverted—this pause successfully blocked another ~$200 million.

Yet the fallout was devastating. Aave V3 absorbed ~$177 million in bad debt. AAVE token dropped 10.27%. ETH fell 3%. WETH utilization on Aave instantly spiked to 100%, triggering mass withdrawals. Over 20 L2 chains saw their rsETH holdings become value-in-question assets overnight.

April 6: What the Report Caught

Early April, shortly after Drift Protocol lost $285 million on April 1, I developed an open-source Claude Code skill called crypto-project-security-skill—a framework for AI-assisted architectural risk assessment using public data (DeFiLlama, GoPlus, Safe API, on-chain verification). It is neither a code scanner nor a formal verification tool. Drift’s collapse made clear one truth: the largest losses don’t stem from code bugs—they come from governance flaws, configuration oversights, and architectural blind spots invisible to static analysis tools. So I built a specialized evaluator focusing on governance structure, oracle dependencies, economic mechanisms, and cross-chain architecture, comparing each protocol against known historical attack patterns (Drift, Euler, Ronin, Harmony, Mango).

On April 6, I conducted a full audit of Kelp DAO. The complete report is publicly available on GitHub, with verifiable commit timestamps.

The audit assigned Kelp a composite risk score of 72/100 (medium risk). Looking back, this score was too lenient—the unresolved cross-chain information gaps should have significantly lowered it. Even under medium risk, however, the report highlighted the very attack vector later exploited.

Below is a screenshot from the report’s “Information Gaps” section—specifically identifying the DVN configuration issue that became the root cause of the $292 million theft:

Figure caption: “Information Gaps” section from the April 6 report, explicitly naming opaque DVN configuration

Now, let’s map each finding to how it was actually exploited.

Findings 1: Opaque DVN Configuration (Warning Signal)

Report text: “LayerZero DVN configuration (validator sets and threshold requirements per chain) is not publicly disclosed.”

What actually happened: Kelp operated a 1-of-1 DVN configuration—one node, one point of failure. By compromising that single node, the attacker forged cross-chain messages. If the configuration had been 2-of-3 (industry minimum recommendation), the attacker would have needed to breach multiple independent validators simultaneously.

Let’s clarify: this was Kelp’s fault, not LayerZero’s. LayerZero provides infrastructure—the DVN framework. Each protocol chooses its own configuration: number of validators (1-of-1, 2-of-3, 3-of-5…), which nodes to use, and thresholds per chain. Kelp selected 1-of-1 when deploying its OFT bridge. LayerZero fully supports 2-of-3 or higher—Kelp simply didn’t activate it.

Analogy: AWS offers MFA (multi-factor authentication). If your account is compromised because you never enabled MFA, it’s your responsibility—not AWS’s. LayerZero provided the security mechanism; Kelp failed to use it.

Our report couldn’t confirm exact DVN thresholds (since Kelp never disclosed them), but we explicitly listed the lack of transparency as an unresolved information gap and risk item. Refusal to disclose itself is a red flag.

Findings 2: Single Point of Failure Across 16 Chains (Direct Hit)

Report text: “Single point of failure in LayerZero DVN could simultaneously impact rsETH on 16 supported chains.”

What actually happened: The forged message targeted Ethereum mainnet directly, triggering a cascading effect across all chains where rsETH was deployed. LayerZero proactively paused all OFT bridges originating from Ethereum. Over 20 L2 chains saw their rsETH holders suddenly unable to verify whether their tokens remained backed by collateral.

This exposes systemic risk in multi-chain deployments: rsETH circulates across Arbitrum, Optimism, Base, Scroll, and others, but all derive value from assets on Ethereum mainnet. Once the mainnet bridge was compromised, every L2’s rsETH lost its guarantee—holders couldn’t redeem or verify value. Lido’s earnETH (exposed to rsETH), Ethena’s LayerZero bridge—all were forced to halt. The blast radius extended far beyond Kelp itself.

Findings 3: Unverified Cross-Chain Governance Control (Related Issue)

Report text: “Governance control over LayerZero OFT configurations across chains is unverified—particularly whether such control resides within the same 6/8 multisig and 10-day timelock, or is managed by independent keys.”

What actually happened: DVN configuration clearly fell outside strict core protocol governance. If bridge configuration changes were governed by the 6/8 multisig + 10-day timelock, a 1-of-1 DVN setup would require 6 out of 8 signers to agree—making such a risky configuration unlikely to persist unnoticed.

This reveals a common governance blind spot: many protocols enforce strict multisigs and timelocks for core contract upgrades, but operational-level changes—bridge configurations, oracle parameters, whitelisting—are often controlled by a single admin key. Kelp’s core governance was industry-leading (6/8 multisig + 10-day timelock), yet these protections did not extend to its most critical attack surface: the cross-chain bridge.

Findings 4: Matched Ronin/Harmony Attack Pattern (Direct Hit)

Report text: “Most relevant historical precedents involve bridge security. Kelp’s LayerZero deployment across 16 chains introduces operational complexity similar to Ronin’s multi-chain architecture.”

What actually happened: The attack path perfectly mirrored the Ronin playbook—compromising bridge validators, forging messages, draining assets. Our tool’s attack pattern matching module correctly identified this as a high-risk vector by comparing protocol architecture to past attacks.

Historical context: In 2022, Ronin lost $625 million after 5 of 9 validators were compromised; the same year, Harmony’s Horizon bridge lost $100 million after 2 of 5 validators were breached. Kelp’s situation was worse—only one validator—reducing the attack barrier to its absolute minimum. The tool flagged this risk because it automatically compares protocol architecture to historical attack patterns, not just code.

Findings 5: No Insurance Pool (Amplified Losses)

Report text: “The protocol currently lacks a dedicated insurance pool or socialized loss absorption mechanism to cover forfeitures.”

What actually happened: Without an insurance reserve, the entire $292 million loss was absorbed by downstream protocols. Aave’s recovery fund covered less than 30% of its $177 million bad debt. LPs unrelated to Kelp’s bridge configuration bore the brunt of the damage.

The attacker used stolen rsETH as collateral in Aave V3, Compound V3, and Euler, then borrowed real WETH. Once rsETH was confirmed unbacked, these positions became “uncancelable” bad debt—collateral turned worthless, while borrowed WETH was already gone. Aave’s WETH utilization spiked to 100% instantly, locking out normal users. If you were an Aave WETH depositor—even if you never interacted with rsETH—your funds were impacted. Kelp’s partnership with Nexus Mutual covered only specific vault products, not the core rsETH protocol exposure.

This was a failure on both sides. On Kelp’s side: a protocol managing $1.3 billion TVL with zero insurance pool and no loss absorption mechanism. No buffer existed when the bridge was breached. On Aave’s side: accepting rsETH as collateral without properly assessing cross-chain bridge configuration risks. Aave’s risk parameters (LTV, liquidation thresholds) were designed for normal price volatility, not tail risks like “bridge configuration compromise leading to instant collateral devaluation.” The recovery fund couldn’t even cover 30% of the bad debt. Fundamentally, this was a risk pricing failure: Aave treated rsETH as a volatile asset, but it carried a binary tail risk of bridge failure. The combination of failures—Kelp failing to prevent bad collateral from entering the system, Aave failing to model exposure under extreme scenarios—created a perfect storm.

Where We Went Wrong

Three things should have been done better:

Low risk rating. We rated cross-chain bridge risk as “medium.” Five unresolved information gaps in the report were related to LayerZero bridge configuration, and the attack pattern matched Ronin/Harmony history—this should have been “high” or “critical.” Opaqueness alone should have triggered stronger warning signals.

We couldn’t penetrate the configuration layer. The report repeatedly requested Kelp disclose DVN thresholds, but we couldn’t independently verify them. This is precisely the structural blind spot highlighted in Juyuan’s post-mortem analysis: current audit tools focus on code logic and miss configuration-level risks. We flagged the issue but couldn’t answer it.

We didn’t query the blockchain. DVN configuration can be read directly on-chain via LayerZero’s EndpointV2 contract. We could have queried the ULN302 registry to independently verify Kelp’s DVN threshold instead of marking it “not disclosed.” Had we done so, we’d have seen the 1-of-1 configuration immediately—no disclosure needed. This is the most concrete improvement direction for the tool: integrate on-chain DVN configuration validation into the cross-chain assessment step.

Findings were too vague and non-actionable. Saying “DVN configuration not disclosed” reflects a document gap—not a predicted exploit. These risks (oracle centralization, bridge dependency, lack of insurance) are widespread across most cross-chain DeFi protocols. While the tool flagged Kelp’s opacity, it also flagged similar patterns across dozens of unattacked protocols. Without published false positive rates, claiming “we predicted it” is misleading. A more honest statement: we asked some questions nobody else was asking—and one happened to hit a critical weak point.

About Responsible Disclosure

A fair question: If we flagged these risks on April 6, why didn’t we notify Kelp before the April 18 attack?

We didn’t. Reason: the report identified opacity—“DVN configuration not disclosed”—not a specific exploitable vulnerability. We didn’t know it was 1-of-1—we only knew it wasn’t public. There was nothing concrete enough to report. “Your bridge configuration isn’t documented” is a governance observation, not a bug bounty-ready report.

Looking back, we should have reached out directly to the Kelp team and asked about their DVN threshold. That conversation might have exposed the 1-of-1 setup and prompted a fix. We didn’t. This is a lesson: even if a finding seems too vague for formal disclosure, a private message asking for clarification is still worth sending.

What This Means for DeFi Security

The Kelp theft—like the Drift theft 17 days prior—is not a smart contract vulnerability. Tools like Slither, Mythril, or even GoPlus cannot detect it. The flaw lies in deployment configuration, governance gaps, and architectural decisions—above the code layer.

This is the core argument behind crypto-project-security-skill:

Protocol security is not just code security. A protocol can have flawless Solidity, five audits from top firms, and a $250k bug bounty—and still lose $292 million due to a bridge validator misconfiguration.

The tool is open-sourced on GitHub—anyone can review the methodology, run it themselves, or improve it.

Timeline

Twelve days. Signals were there. The question is: how can the ecosystem build tools capable of detecting these signals before the next bridge falls?

What You Can Do

If you hold assets in DeFi protocols with cross-chain bridges:

The Bigger Picture: AI Agent as a Security Layer

This article discusses a tool and one exploit. But the underlying proposition is larger: AI Agents can serve as an independent security layer for DeFi investors.

Traditional crypto security operates like this: protocols hire auditors, auditors review code, auditors issue reports. This model has blind spots—Kelp’s incident proves it, focusing on code correctness while missing configuration, governance, and architectural risks.

Claude Code and similar skill tools offer an alternative path: anyone can use public data to run an AI-assisted risk assessment on any protocol in minutes. You don’t need to spend $200k hiring auditors. You don’t need to read Solidity. You let the agent compare the protocol’s architecture against known attack patterns, surfacing the questions you should ask before depositing funds.

This won’t replace professional audits—but it lowers the barrier to first-layer due diligence to universal accessibility. A new LP considering a restaking protocol can now run a command like audit defi <protocol>, receiving a structured risk assessment covering governance, oracles, bridges, and economic design. For retail and mid-tier investors, this represents a genuine shift in self-protection capability.

Kelp’s report wasn’t perfect. It rated bridge risk as medium—should have been severe. It failed to penetrate the configuration layer. But it asked the right questions—if Kelp’s team or any LP had taken them seriously, the $292 million loss could have been avoided.

Source: DeepChaos TechFlow