What Is Kelp DAO?

Kelp DAO is a liquid restaking protocol built on EigenLayer. The core mechanism works like this: users deposit ETH or liquid staking tokens (stETH, ETHx) into Kelp's contracts, which delegate those assets to EigenLayer operators for restaking — securing multiple Actively Validated Services (AVSs) simultaneously. In return, users receive rsETH, a liquid restaking token that represents their restaked position. Unlike directly restaking on EigenLayer (which locks your assets), rsETH stays liquid — you can trade it, use it as collateral on lending protocols like Aave, or move it across chains.

To enable this cross-chain liquidity, Kelp deploys rsETH on 16+ blockchains using LayerZero's OFT (Omnichain Fungible Token) standard. When you bridge rsETH from Ethereum to an L2, LayerZero's DVN (Decentralized Verifier Network) validates the cross-chain message to ensure the transfer is legitimate. This bridge architecture is central to the story that follows.

Founded by Amitej Gajjala and Dheeraj Borra (previously co-founders of Stader Labs), Kelp launched in December 2023, peaked at $2.09 billion in TVL, and is governed by a 6/8 multisig with a 10-day timelock on upgrades. Its governance token KERNEL unifies three products: Kelp, Kernel, and Gain.

The Hack

On April 18, 2026, attackers drained 116,500 rsETH (~$292 million) from Kelp DAO's cross-chain bridge — the largest DeFi exploit of 2026. The root cause wasn't a smart contract bug. It was a configuration flaw: a 1-of-1 DVN setup that let attackers forge cross-chain messages with a single compromised node.

Twelve days earlier, on April 6, our open-source security audit skill had already flagged this exact attack surface.

Before we go further: real people lost real money in this exploit. Aave WETH suppliers who never touched rsETH had their funds frozen. LPs across multiple protocols are facing haircuts they didn't sign up for. This article analyzes what happened and what our tool caught — but the human cost matters more than any scorecard.

The report exists on GitHub with a commit timestamp anyone can verify. Here's what we caught, what we missed, and what this means for DeFi security tooling.

The Attack: 46 Minutes That Shook DeFi

At 17:35 UTC on April 18, the attacker compromised the single DVN validator node, which then approved a fraudulent cross-chain message. LayerZero's Endpoint, seeing the DVN's validation, delivered the message to Kelp's OFT contract via lzReceive — causing it to mint 116,500 rsETH on Ethereum mainnet. The message claimed locked assets existed on another chain. Those assets never existed.

The attacker then executed a textbook DeFi money laundering playbook:

1. Deposited stolen rsETH as collateral on Aave V3, Compound V3, and Euler
2. Borrowed ~$236M in WETH against the unbacked collateral
3. Consolidated ~74,000 ETH and routed through Tornado Cash

Kelp's emergency pauser multisig froze contracts 46 minutes later at 18:21 UTC. Two follow-up drain attempts (40,000 rsETH each, ~$100M) reverted — the pause saved roughly$200M more.

The aftermath was devastating. Aave V3 absorbed ~$177M in bad debt. AAVE token crashed 10.27%. ETH dropped 3%. WETH utilization on Aave hit 100% as suppliers rushed to withdraw. rsETH across 20+ L2 networks became questionable overnight.

What the Report Found — April 6, 2026

In early April, shortly after the Drift Protocol hack ($285M on April 1), I built an open-source Claude Code skill called crypto-project-security-skill — an AI-assisted architectural risk assessment framework that uses public data (DeFiLlama, GoPlus, Safe API, on-chain verification) to evaluate DeFi protocols. It is not a code scanner or formal verifier. The Drift hack showed that the biggest exploits aren't in smart contract code — they're in governance gaps, configuration oversights, and architectural blind spots that no code scanner catches. So I built a tool that evaluates exactly those layers: governance structures, oracle dependencies, economic mechanisms, and cross-chain architecture, comparing each protocol against known attack patterns from historical exploits (Drift, Euler, Ronin, Harmony, Mango).

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

The report gave Kelp a composite triage score of 72/100 (MEDIUM risk). In hindsight, this score was too generous — the unresolved cross-chain information gaps should have pulled it lower. But even at MEDIUM, the report identified the exact attack surface that was later exploited.

The screenshot below shows the exact line from our report's "Information Gaps" section — the question about Kelp's DVN configuration that turned out to be the root cause of the $292M hack:

Here's what we flagged — and how it maps to the actual attack:

Finding #1: DVN Configuration Opacity (Prescient Signal)

Report excerpt:

"LayerZero DVN configuration (validator set, threshold requirements per chain) not publicly disclosed"

What actually happened: Kelp was running a 1-of-1 DVN configuration. One node. One point of failure. The attacker compromised that single node and forged a cross-chain message. If the configuration had been 2-of-3 (the industry minimum recommendation), the attacker would have needed to compromise multiple independent validators.

To be clear: this is Kelp's problem, not LayerZero's. LayerZero is infrastructure — it provides the DVN framework and lets each protocol choose its own configuration: how many verifier nodes (1-of-1, 2-of-3, 3-of-5...), which node operators, and what thresholds per chain. Kelp chose 1-of-1 when deploying its OFT bridge. LayerZero fully supports 2-of-3 or higher — Kelp simply didn't enable it.

Think of it like AWS offering MFA. If your account gets compromised because you never turned on MFA, that's on you, not AWS. LayerZero offered the security controls; Kelp didn't use them.

Our report couldn't determine the exact DVN threshold (because Kelp never disclosed it), but we explicitly called out this opacity as an unresolved information gap and a risk vector. The fact that they wouldn't disclose it was itself a red flag.

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

Report excerpt:

"A single point of failure in LayerZero's DVN could simultaneously affect rsETH across all 16 supported chains"

What actually happened: The spoofed cross-chain message affected Ethereum mainnet directly, and the fallout cascaded across all chains where rsETH was deployed. LayerZero paused all OFT bridges from Ethereum as a precaution. rsETH holders on 20+ L2s were left with tokens of uncertain backing.

This is the systemic risk of multi-chain deployment: rsETH circulates on Arbitrum, Optimism, Base, Scroll, and other L2s, but all of these tokens derive their backing from assets on Ethereum mainnet. Once the mainnet bridge was compromised, rsETH on every L2 simultaneously lost its guarantee — holders couldn't redeem, and couldn't verify whether their tokens still had value. Lido's earnETH (which had rsETH exposure), Ethena's LayerZero bridges — all were forced to pause. The blast radius extended far beyond Kelp itself.

Finding #3: Cross-Chain Governance Controls Unverified (Relevant Question)

Report excerpt:

"Governance controls over LayerZero OFT configuration per chain remain unverified—specifically, whether these controls fall under the same 6/8 multisig and 10-day timelock or separate administrative keys"

What actually happened: The DVN configuration was clearly not under the same rigorous governance as the core protocol. If the 6/8 multisig and 10-day timelock had governed bridge configuration changes, the 1-of-1 DVN setup would have required 6 of 8 signers to approve — making it far less likely to persist unnoticed.

This exposes a common governance blind spot: many protocols enforce strict multisig and timelock controls on core contract upgrades, but operational-layer changes — bridge configurations, oracle parameters, whitelist management — may be controlled by a single admin key. Kelp's core protocol governance was industry-leading (6/8 multisig + 10-day timelock), but those protections didn't extend to its largest attack surface: the cross-chain bridge.

Finding #4: Ronin/Harmony Attack Pattern Match (Direct Hit)

Report excerpt:

"The most relevant historical parallel involves bridge security. Kelp's 16-chain LayerZero deployment creates operational complexity similar to Ronin's multi-chain architecture."

What actually happened: The attack followed the Ronin playbook almost exactly — compromise bridge validators, forge messages, drain assets. Our skill's attack pattern matching, which compares protocol architecture against historical exploit categories, correctly identified this as the highest-risk vector.

Historical context: in 2022, the Ronin Bridge lost $625M when attackers compromised 5 of 9 validators; that same year, the Harmony Horizon Bridge lost$100M when attackers compromised 2 of 5 validators. Kelp's situation was even more extreme — only 1 validator, reducing the attack threshold to its absolute minimum. Our skill flagged this risk precisely because it automatically compares protocol architecture against these historical attack patterns, rather than only examining code.

Finding #5: No Insurance Fund (Amplified Damage)

Report excerpt:

"The protocol currently lacks a dedicated insurance fund or socialized loss mechanism to absorb slashing events"

What actually happened: With no insurance reserves, the $292M loss was absorbed entirely by downstream protocols. Aave's recovery reserves covered less than 30$177M bad debt. Liquidity providers — who had no direct relationship with Kelp's bridge configuration decisions — bore the brunt.

The attacker deposited stolen rsETH as collateral on Aave V3, Compound V3, and Euler, then borrowed real WETH against it. Once rsETH was confirmed as unbacked, these positions became "unliquidatable" bad debt — the collateral was worthless, but the borrowed WETH was already gone. WETH utilization on Aave hit 100% instantly, preventing normal users from withdrawing. If you were a WETH supplier on Aave, your funds were impacted even if you never touched rsETH. Kelp's Nexus Mutual insurance partnership only covered specific vault products, not core rsETH protocol exposure.

This is a dual responsibility failure. On Kelp's side: a protocol managing $1.3B in TVL had zero insurance fund or loss absorption mechanism. When the bridge was compromised, there was no buffer to absorb the damage. On Aave's side: accepting rsETH as collateral without adequately assessing its cross-chain bridge configuration risk. Aave's risk parameters (LTV, liquidation thresholds) were designed for normal price volatility, but didn't account for the tail risk of "collateral goes to zero overnight because a bridge config was compromised." Recovery reserves covered less than 30% of the bad debt. In essence, this was a risk pricing failure: Aave treated rsETH as an asset with normal volatility, when in reality it carried a binary bridge-failure tail risk. The two failures compounded — no insurance on Kelp's end to prevent the bad collateral from entering the system, and inadequate risk modeling on Aave's end to limit exposure to that exact scenario.

What We Got Wrong

Three things we should have done better:

1. Risk rating was too low. We rated cross-chain bridge risk as MEDIUM. Given that 3 of the 5 unresolved information gaps in our report related to LayerZero bridge configuration, and given the Ronin/Harmony pattern match, this should have been HIGH or CRITICAL. The opacity itself should have been a stronger signal.

2. We couldn't pierce the configuration layer. Our report repeatedly asked Kelp to disclose DVN thresholds, but we couldn't verify them independently. This is the same structural blind spot the cnyes.com post-mortem identifies: current audit tools focus on code logic but can't detect configuration-layer risks. We flagged the question; we couldn't answer it.

3. We didn't check on-chain. DVN configurations are actually readable on-chain via LayerZero's EndpointV2 contracts. We could have queried the ULN302 registry to verify Kelp's exact DVN threshold instead of flagging it as "not publicly disclosed." If we had, we would have seen the 1-of-1 configuration directly — no need for Kelp to disclose anything. This is the most concrete improvement for the tool: add on-chain DVN config verification to the cross-chain assessment step.

4. The findings were not specific enough to be actionable. Saying "DVN configuration is not disclosed" is an observation about missing documentation — not a prediction of a hack. Many of these same risks (oracle concentration, bridge dependencies, missing insurance) apply generically to most cross-chain DeFi protocols. The tool flagged Kelp's opacity, but it also flags similar patterns across dozens of protocols that have not been hacked. Without publishing the false positive rate, claiming "we predicted this" overstates what actually happened. More honestly: we asked the right questions that nobody else was asking, and one of those questions turned out to be load-bearing.

A Note on Responsible Disclosure

A fair question: if we flagged these risks on April 6, did we try to warn Kelp before the hack on April 18?

No, and here's why. The report identified opacity — "DVN configuration not disclosed" — not a specific exploitable vulnerability. We didn't know the configuration was 1-of-1; we only knew it wasn't public. There was no concrete finding to disclose. "Your bridge configuration is not documented" is a governance observation, not a bug report suitable for a bounty program.

In hindsight, we could have reached out to Kelp's team directly to ask about their DVN threshold. That conversation might have surfaced the 1-of-1 configuration and prompted a fix. We didn't, and that's a lesson: even when a finding feels too vague for formal disclosure, it may be worth a direct message.

Why This Matters for DeFi Security

The Kelp hack — like the Drift hack 17 days earlier — wasn't a smart contract bug. Automated code scanners like Slither, Mythril, or even GoPlus wouldn't have caught it. The vulnerability lived in deployment configuration, governance gaps, and architectural decisions that sit above the code layer.

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

Protocol security isn't just code security. A protocol can have perfect Solidity, five audits from top firms, and a $250K bug bounty — and still lose$292M because of how its bridge validators are configured.

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

The Timeline

Date	Event
April 6, 2026	Security report published on GitHub — flags DVN opacity, single point of failure across 16 chains, Ronin attack pattern match
April 18, 2026 17:35 UTC	Attacker calls lzReceive with spoofed message, drains 116,500 rsETH ($292M)
April 18, 2026 18:21 UTC	Kelp emergency pause activated (46 min response)
April 19, 2026	Post-mortem coverage confirms 1-of-1 DVN configuration as root cause

Twelve days. The signals were there. The question now is how the ecosystem builds tooling to surface these signals before the next bridge goes down.

What You Can Do

If you're holding positions in DeFi protocols with cross-chain bridges:

1. Run the audit yourself. The skill is open-source. You don't need to trust us — verify.
2. Check bridge validator configurations. If a protocol won't disclose its DVN threshold, treat that as a red flag. Our report did, and we were right.
3. Don't assume code audits cover everything. Kelp had 5+ code audits from reputable firms and platforms (Code4rena, SigmaPrime, MixBytes). Traditional code audits are not designed to catch configuration-layer risks like DVN threshold settings — that's a different category of analysis, not a failure of those auditors.
4. Evaluate insurance coverage. If a protocol has no insurance fund and you're an LP on a lending platform that accepts its tokens as collateral, you're implicitly insuring them. Aave's WETH suppliers learned this the hard way.

The Bigger Picture: AI Agents as a Security Layer

This article is about one tool and one hack. But the underlying thesis is broader: AI agents can serve as an independent security layer for DeFi investors.

Traditional security in crypto follows a pattern: a protocol hires auditors, auditors examine code, auditors publish a report. This model has blind spots — as the Kelp hack demonstrates, it focuses on code correctness while missing configuration, governance, and architectural risks.

What Claude Code and tools like this skill enable is a different approach: anyone can run an AI-assisted risk assessment on any protocol, using public data, in minutes. You don't need to hire a $200K audit firm. You don't need to read Solidity. You ask an agent to evaluate the protocol's architecture against known attack patterns, and it surfaces the questions you should be asking before you deposit.

This won't replace professional audits — but it democratizes the first layer of due diligence. An LP considering deploying capital into a new restaking protocol can now run audit defi <protocol> and get a structured risk assessment that covers governance, oracles, bridges, and economic mechanisms. That's a meaningful shift in how retail and mid-tier investors can protect themselves.

The Kelp report wasn't perfect. It rated the bridge risk as MEDIUM when it should have been CRITICAL. It couldn't pierce the configuration layer. But it asked the right questions — questions that, if Kelp's team or any LP had taken seriously, could have prevented $292M in losses.

References

• CoinDesk: 2026's Biggest Crypto Exploit — $292M Drained from Kelp DAO
• Crypto Briefing: Kelp DAO Hit by $292M Bridge Hack
• DL News: Hackers Target DeFi Protocol Kelp DAO in Massive $300M Exploit
• Bitcoin.com: ZachXBT Flags $280M+ KelpDAO Exploit
• 鉅亨網: 2.93 億美元的漏洞不在程式碼裡
• Aave Official Statement on X
• Full Kelp DAO Security Report (April 6, 2026)
• crypto-project-security-skill Source Code

---

The full Kelp DAO security report is available at github.com/truenorth-lj/crypto-project-security-skill/docs/examples/kelp-liquid-restaking.md. The commit timestamp is independently verifiable.

The crypto-project-security-skill is open-source under MIT license at github.com/truenorth-lj/crypto-project-security-skill.