AI Agents can serve as an independent security layer for DeFi investors.

Author: Zengineer

Translated by: DeepTide TechFlow

What is Kelp DAO

Kelp DAO is a 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—simultaneously providing security to multiple AVSs (Actively Validated Services). In return, users receive rsETH as a receipt. 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 transferred across chains.

To enable this cross-chain liquidity, Kelp deploys rsETH on over 16 chains using LayerZero’s OFT (Omnichain Fungible Token) standard. When users bridge rsETH from Ethereum to a Layer 2 chain, LayerZero’s DVN (Decentralized Verifier Network) validates the legitimacy of the cross-chain message. This bridge architecture forms the core of the subsequent narrative.

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

The Theft 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 attack 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 an attacker to forge cross-chain messages using a single compromised node.

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

Let’s be clear: this theft caused real financial losses for real people. Aave WETH depositors who never touched rsETH had their funds frozen; multiple LPs across protocols were forced to absorb bad debt they never agreed to bear. This article analyzes what happened and what our tool captured—but the actual cost of loss far exceeds any risk score.

The full report is hosted on GitHub, with immutable commit timestamps verifiable by anyone. Below, we discuss what we caught, what we missed, and what this means for DeFi security tools.

46 Minutes, DeFi Shaken

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

Next came a standard DeFi money-laundering sequence:

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

Yet the fallout remained 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 panic withdrawals. Over 20 L2 chains saw rsETH become value-in-question assets overnight.

April 6: What the Report Caught

Early April, shortly after Drift Protocol was hacked for $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. The Drift incident made me realize: the greatest losses don’t stem from code flaws—they come from governance vulnerabilities, configuration oversights, and architectural blind spots invisible to traditional scanners. So I built a specialized tool to assess these layers: governance structure, oracle dependencies, economic mechanisms, and cross-chain architecture, comparing each protocol against historical attack patterns (Drift, Euler, Ronin, Harmony, Mango).

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

The report gave 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 lowered it. Even at medium risk, the report did flag the exact attack vector later exploited.

The following screenshot shows the original text from the report’s “Information Gaps” section—specifically about Kelp’s DVN configuration, which later became the root cause of the $292 million theft:

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

Below, we break down what the report flagged and how each was exploited.

Findings 1: Opaque DVN Configuration (Warning Signal)

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

What actually happened: Kelp operated under a 1-of-1 DVN setup—one node, one point of failure. The attacker compromised this single node and forged cross-chain messages. Had it been 2-of-3 (industry minimum recommendation), the attacker would have needed to breach multiple independent validators simultaneously.

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

Think of it this way: AWS offers MFA (multi-factor authentication). If your account is breached because you never enabled MFA, that’s your fault—not AWS’s. LayerZero provided the security mechanism; Kelp failed to use it.

Our report couldn’t determine the exact DVN threshold (since Kelp never disclosed it), but we explicitly listed this opacity as an unresolved information gap and risk factor. Refusal to disclose is itself a red flag.

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

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

What actually happened: The forged message directly targeted Ethereum mainnet, sending shockwaves across all chains where rsETH was deployed. LayerZero proactively paused all OFT bridges originating from Ethereum. Over 20 L2 chains saw rsETH holders suddenly unable to verify whether their tokens still held backing.

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 breached, 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 quote: “Governance control over LayerZero OFT configurations across chains remains unverified—particularly whether these controls are governed by the same 6-of-8 multisig with 10-day timelock, or by separate admin keys.”

What actually happened: DVN configuration clearly fell outside strict core protocol governance. If bridge configuration changes were also subject to the 6-of-8 multisig + 10-day timelock, a 1-of-1 DVN setup would require 6 out of 8 signers to approve—making such a configuration unlikely to remain unmonitored long-term.

This reveals a common governance blind spot: many protocols enforce strict multisig + timelock for core contract upgrades, but allow single-admin-key control over operational changes—bridge configurations, oracle parameters, whitelist management. Kelp’s core governance is industry-leading (6-of-8 multisig + 10-day timelock), but these protections did not extend to its most exposed surface: the cross-chain bridge.

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

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

What actually happened: The attack path closely replicated the Ronin playbook—breach bridge validators, forge messages, drain assets. Our tool’s attack pattern matching module correctly identified this as the highest-risk attack vector by comparing protocol architecture to historical attack categories.

Historical context: In 2022, Ronin Bridge lost $625 million after 5 of 9 validators were compromised; same year, Harmony’s Horizon Bridge lost $100 million after 2 of 5 validators were breached. Kelp’s situation was more extreme—only one validator, reducing the attack barrier to absolute minimum. The tool identified this risk precisely because it compares protocol architecture to past attacks, not just code.

Findings 5: No Insurance Pool (Amplified Losses)

Report quote: “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 reserve covered less than 30% of its $177 million bad debt. LPs unrelated to Kelp’s bridge configuration bore the brunt of the impact.

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 “unclearable” bad debt—collateral turned worthless, but WETH was already withdrawn. Aave’s WETH utilization spiked instantly to 100%, locking out ordinary users. If you were a WETH depositor on Aave—even if you never touched rsETH—your funds were affected. Kelp’s insurance partnership with Nexus Mutual covers only specific vault products, not the core rsETH protocol exposure.

This reflects failures on both sides. Kelp: a protocol managing $1.3 billion TVL with zero insurance pool or loss absorption mechanism. No buffer existed when the bridge was breached. Aave: accepted rsETH as collateral without properly assessing cross-chain bridge configuration risk. Aave’s risk parameters (LTV, liquidation thresholds) were designed for normal price volatility, not tail risks like “bridge configuration compromise leading to instant asset devaluation.” Recovery reserves covered less than 30% of bad debt. Fundamentally, this was a risk pricing failure: Aave treated rsETH as a volatile asset, but it carried the binary tail risk of bridge failure. The combination—Kelp failing to prevent bad collateral entry, Aave failing to model fine-grained exposure—created a perfect storm.

Where We Went Wrong

Three things should have been done better:

Risk rating too low. We rated cross-chain bridge risk as “medium.” Five unresolved information gaps in the report involved LayerZero bridge configuration, and the pattern matched Ronin/Harmony attacks—this should have been “high” or “critical.” Opacity alone should have triggered stronger warning signals.

We failed to penetrate the configuration layer. The report repeatedly requested Kelp disclose DVN thresholds, but we couldn’t independently verify them. This is exactly the structural blind spot highlighted in later analysis by Juxingwang: 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 publicly disclosed.” Had we done so, we’d have seen the 1-of-1 setup immediately—no need for disclosure. This is the most concrete improvement direction for the tool: add on-chain DVN configuration validation within the cross-chain assessment step.

Findings were too vague and non-actionable. Saying “DVN configuration not disclosed” points to missing documentation—not a predicted exploit. These risks (oracle centralization, bridge dependency, lack of insurance) are widespread across most cross-chain DeFi protocols. The tool flagged Kelp’s opacity, but also marked similar patterns in dozens of unattacked protocols. Without published false positive rates, claiming “we predicted it” is misleading. A more honest statement: we asked some correct questions that no one else was asking—and one of them 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 attack on April 18?

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

Looking back, we could have directly contacted 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 worth it.

What This Means for DeFi Security

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

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

Protocol security isn’t 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-source on GitHub—anyone can review the methodology, run it themselves, or improve it.

Timeline

Twelve days. The signal was there. The question is: how can the ecosystem build tools capable of seeing these signals before the next bridge falls.

What You Can Do

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

Bigger Picture: AI Agent as a Security Layer

This article discusses a tool and one theft. But the underlying proposition is larger: AI Agents can become 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 event 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 to known attack patterns and surface the questions you should ask before depositing funds.

This won’t replace professional audits—but it lowers the first line of due diligence to a level accessible to everyone. An LP considering investing in a new restaking protocol can now run audit defi <protocol>, receiving a structured risk assessment covering governance, oracles, bridges, and economic mechanisms. 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: DeepTide TechFlow