Author: Zengineer

Compiled by: Deep Tide TechFlow

Deep Dive: On April 18th, Kelp DAO suffered a $292 million theft, the largest DeFi incident so far in 2026. The vulnerability wasn't in the contract code, but in the 1-of-1 validator node configuration of the LayerZero cross-chain bridge—a single point of failure could lead to the forgery of cross-chain messages. The author had already flagged this risk point 12 days prior when scanning Kelp with their self-developed open-source AI auditing tool. This article recounts the entire attack process and honestly reflects on three things the tool failed to do at the time.

What is Kelp DAO?

Kelp DAO is a liquidity restaking protocol built on EigenLayer. The mechanism works like this: users deposit ETH or liquidity staking tokens (stETH, ETHx) into the Kelp contract, which then delegates the assets to EigenLayer's operating nodes for restaking—providing security for multiple AVS (Actively Validated Services). In return, users receive rsETH as collateral. 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 cross-chain.

To achieve this cross-chain liquidity, Kelp deployed rsETH on more than 16 chains using LayerZero's OFT (Omnichain Fungible Token) standard. When you cross rsETH from Ethereum to an L2 chain, LayerZero's DVN (Decentralized Verifier Network) verifies the legitimacy of this cross-chain message. This bridge architecture is the core of the story that follows.

Kelp was initiated by Amitej Gajjala and Dheeraj Borra (former co-founders of Stader Labs) and launched in December 2023. Its peak TVL reached $2.09 billion. Governance employs a 6/8 multisignature mechanism with a 10-day contract upgrade time lock. The governance token KERNEL governs Kelp, Kernel, and Gain.

Theft

On April 18, 2026, attackers stole 116,500 rsETH, equivalent to approximately $292 million, from Kelp DAO's cross-chain bridge—the largest DeFi attack to date in 2026. The root cause wasn't a smart contract vulnerability, but a configuration issue: a 1-of-1 DVN setup (meaning only one validator node, and a single signature was sufficient), allowing attackers to forge cross-chain messages using a single compromised node.

Twelve days ago, on April 6th, my open-source security auditing tool had already identified this attack surface.

First and foremost: this theft involved real people and real money losses. Aave WETH depositors who had never touched rsETH had their funds frozen; multiple LPs in various protocols are now bearing bad debts they weren't even contracted to assume. This article analyzes what happened and what our tools captured—but the actual cost to people is more important than any rating chart.

The full report is available on GitHub, and the commit timestamps can be verified by anyone. Below, we'll discuss what we caught, what we missed, and what this means for DeFi security tools.

46 minutes, DeFi shakes

At 17:35 UTC on April 18th, the attacker compromised the isolated DVN validator node and forced it to "approve" a forged cross-chain message. LayerZero's endpoint, seeing that DVN had approved the message, forwarded it to Kelp's OFT contract via lzReceive—the contract complied, minting 116,500 rsETH on the Ethereum mainnet. The message claimed that equivalent assets were locked on other chains as collateral. Those assets never existed.

Next is a standard DeFi money laundering process:

1. The stolen rsETH was deposited as collateral into Aave V3, Compound V3, and Euler.
2. Using these unsecured collateral, approximately $236 million of WETH was borrowed.
3. Approximately 74,000 ETH were pooled and withdrawn via Tornado Cash.

At 18:21, 46 minutes later, Kelp's emergency pause multisignature froze the contract. The attackers then reverted two subsequent attacks (40,000 rsETH each, approximately $100 million) – this pause blocked another $200 million.

The impact was still devastating. Aave V3 absorbed approximately $177 million in bad debt. AAVE tokens plummeted by 10.27%. ETH dropped by 3%. WETH usage on Aave instantly surged to 100%, with depositors rushing to withdraw. Over 20 L2 servers' rsETH became assets of questionable value overnight.

What did the report uncover on April 6th?

In early April, shortly after the $285 million theft from Drift Protocol on April 1st, I wrote an open-source tool called Claude Code , crypto-project-security-skill —an AI-assisted architectural risk assessment framework that uses publicly available data (DeFiLlama, GoPlus, Safe API, on-chain verification) to evaluate DeFi protocols. It's not a code scanner or a formal verification tool. The Drift incident made me realize that the biggest losses weren't in the smart contract code—but in governance vulnerabilities, configuration oversights, and architectural blind spots—places code scanners can never see. So I wrote a tool specifically for assessing these layers: governance structure, oracle dependencies, economic mechanisms, and cross-chain architecture, comparing each protocol with the attack patterns of historically notorious attacks (Drift, Euler, Ronin, Harmony, Mango).

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

The report gave Kelp an overall triage score of 72/100 (medium risk) . In hindsight, this score was too lenient—the unresolved cross-chain information gaps should have lowered the score. However, even with the medium risk rating, the report pointed out the attack surface that was later actually exploited.

The screenshot below is the original text of the "information gap" section of the report—the issue regarding Kelp's DVN configuration ultimately became the root cause of the $292 million theft:

Caption: In the "Information Gap" section of the report dated April 6, the lack of transparency in DVN configuration was directly mentioned.

Below, we will compare each point with what was marked in the report and how it was actually breached.

Finding 1: DVN configuration is opaque (warning signal)

Original report text: "LayerZero DVN configuration (validator sets and threshold requirements for each chain) has not been publicly disclosed."

What actually happened: Kelp was running a 1-of-1 DVN configuration. One node. A single point of failure. An attacker compromised this single node and forged cross-chain messages. If the configuration were 2-of-3 (the industry minimum recommended), an attacker would have to compromise multiple independent validators simultaneously.

To clarify one thing: this is a Kelp issue, not a LayerZero issue. LayerZero is the infrastructure—it provides the DVN framework, and each protocol chooses its own configuration: the number of validator nodes (1-of-1, 2-of-3, 3-of-5...), whose nodes to use, and the thresholds for each chain. Kelp chose 1-of-1 when deploying the OFT bridge. LayerZero fully supports 2-of-3 or higher—Kelp simply didn't enable it.

For example, AWS provides MFA (Multi-Factor Authentication). If your account is stolen because you never enabled MFA, that's your problem, not AWS's. LayerZero has its security mechanisms in place, Kelp can't do that.

Our report couldn't determine a specific DVN threshold at the time (because Kelp had never disclosed it), but we explicitly listed this lack of transparency as an unresolved information gap and risk. The unwillingness to disclose itself was a red flag.

Finding 2: Single point of failure (direct hit) on 16 chains.

Original report: "A single point of failure in LayerZero DVN could simultaneously affect rsETH on 16 supporting chains."

What actually happened: The fake message hit the Ethereum mainnet directly, and the shockwave spread to all chains that deployed rsETH. LayerZero preemptively suspended all OFT bridges leading out of Ethereum. Over 20 rsETH holders on L2 exchanges found their tokens unsecured overnight.

This is a systemic risk inherent in multi-chain deployments: rsETH circulates simultaneously on L2 platforms such as Arbitrum, Optimism, Base, and Scroll, but the value of all these tokens originates from assets on the Ethereum mainnet. If the mainnet bridge is compromised, rsETH on each L2 platform simultaneously loses its guarantee—holders can neither redeem their tokens nor verify their remaining value. Lido's earnETH (holding rsETH exposure) and Ethena's LayerZero bridge—both were forced to suspend operations. The impact extends far beyond Kelp itself.

Finding 3: Cross-chain governance control is unverified (related issues)

The original report stated: "Government control over LayerZero OFT configurations across different chains is unverified—specifically: whether this control is held by the same 6/8 multisignature and 10-day time lock, or by independent management keys."

What actually happened: DVN configurations were clearly not under the strict governance of the core protocol. If bridge configuration changes were also subject to 6/8 multisignature plus a 10-day lockout, a 1-of-1 DVN setup would require the consent of 6 out of 8 signatories—a configuration that is unlikely to remain unregulated indefinitely.

This exposes a common governance blind spot: many protocols have strict multi-signature and time locks for core contract upgrades, but for changes at the operational level—bridge configuration, oracle parameters, whitelist management—often only an admin key can modify them. Kelp's core protocol governance is industry-leading (6/8 multi-signature + 10-day time lock), but these protections do not extend to its biggest attack surface: cross-chain bridges.

Discovery 4: Matches Ronin/Harmony attack pattern (direct hit)

The report states: "The most relevant historical precedent involves 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 almost perfectly replicated Ronin's scenario—breaching the bridge validator, forging messages, and draining assets. Our tool's attack pattern matching module compared the protocol architecture with historical attack categories and correctly identified this as the highest-risk attack vector.

Historical Context: In 2022, the Ronin Bridge suffered a $625 million loss due to the compromise of 5 (out of 9) validators; in the same year, Harmony's Horizon Bridge suffered a $100 million loss due to the compromise of 2 (out of 5) validators. Kelp's situation was even more extreme—it had only 1 validator, lowering the attack threshold to an absolute minimum. The tool can identify this risk because it automatically compares the protocol architecture to these historical attack patterns, rather than just looking at the code.

Finding 5: No insurance pool (amplified losses)

The original report stated: "Currently, the agreement lacks a dedicated insurance pool and a socialized loss-sharing mechanism to absorb confiscation and forfeiture incidents."

What actually happened: Because there was no insurance reserve, the entire $292 million loss was absorbed by downstream agreements. Aave's recovery reserve covered less than 30% of its $177 million in bad debt. LPs, who had no connection to the Kelp bridge configuration decision, bore the brunt of the impact.

Attackers used stolen rsETH as collateral, depositing it into Aave V3, Compound V3, and Euler, and then borrowed real WETH. Once the rsETH was confirmed to be uncollateralized, these positions became "unrecoverable" bad debts—the collateral became worthless, but the borrowed WETH was gone. WETH utilization on Aave instantly skyrocketed, making it impossible for ordinary users to withdraw their funds. If you were a WETH depositor on Aave, even if you had never touched rsETH, your funds were affected. The insurance partnership between Kelp and Nexus Mutual only covered specific vault products and did not cover exposure to the core rsETH protocol.

This is a failure on both sides. Kelp, managing a $1.3 billion TVL, has a zero-insurance pool and a zero-loss absorption mechanism. When the bridge is breached, there's no buffer to absorb the damage. Aave, accepting rsETH as collateral, failed to adequately assess the risks associated with its cross-chain bridge configuration. Aave's risk parameters (LTV, liquidation threshold) are designed for normal price fluctuations but don't account for tail risks like "bridge breach causing collateral to become worthless overnight." Recovery reserves can't even cover 30% of bad debt. Essentially, this is a failure in risk pricing: Aave treats rsETH as a normally volatile asset, but it actually carries the binary tail risk of bridge failure. The failures on both sides combine—Kelp lacks insurance to prevent bad collateral from entering the system, and Aave hasn't done sufficiently sophisticated risk modeling to limit exposure in this scenario.

Where did we go wrong?

There are three things that could have been done better:

The risk rating was too low. We rated the cross-chain bridge risk as "moderate." Three of the five unresolved information gaps in the report are related to LayerZero bridge configuration, which also matches the historical attack patterns of Ronin/Harmony—this should have been "high" or "severe." Lack of transparency should have been a stronger signal.

We were unable to penetrate the configuration layer. The report repeatedly requested Kelp to disclose the DVN threshold, but we were unable to verify it independently. This is precisely the same structural blind spot pointed out by Juheng.com's post-event analysis : existing auditing tools focus on code logic and fail to capture risks at the configuration layer. We flagged the issues, but we couldn't answer them.

We didn't check the on-chain information. The DVN configuration can actually 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 as "not publicly disclosed." If we had checked it then, we could have directly seen the 1-of-1 configuration without needing Kelp's disclosure. This is the most concrete direction for tool improvement: add on-chain DVN configuration verification to the cross-chain evaluation step.

The findings are not specific enough or actionable. Saying "DVN configuration is not disclosed" refers to missing documentation—not predicting an attack. These risks (oracle concentration, bridge dependence, lack of insurance) are actually prevalent in most cross-chain DeFi protocols. The tool flagged Kelp's opacity, but it also flagged similar patterns on dozens of protocols that weren't attacked. Claiming "we predicted it" without disclosing the false positive rate is an exaggeration. A more honest statement is: we asked some correct questions that nobody else was asking, and one of them happened to hit a key nerve.

Regarding "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?

No notification was given. The reason is that the report identified a lack of transparency—"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 publicly available. There was nothing specific that could be disclosed. "Your bridge configuration is undocumented" is a governance observation, not a report suitable for submitting to a bug bounty program.

In hindsight, we could have directly contacted the Kelp team to inquire about their DVN thresholds. That conversation might have exposed the 1-of-1 configuration and facilitated a fix. We didn't. This is a lesson learned: even if a discovery seems too vague to be formally disclosed, it's always worthwhile to send a private message to inquire.

What does this mean for DeFi security?

The Kelp hack—just like the Drift hack 17 days earlier—wasn't caused by a smart contract vulnerability. Automated code scanners like Slither, Mythril, and even GoPlus couldn't detect it. The vulnerability lay hidden in deployment configurations, governance gaps, and architectural decisions—above the code level.

This is also the core claim of crypto-project-security-skill :

Protocol security is not just about code security. A protocol can have perfect Solidity, five audits from top companies, and a $250,000 bug bounty—and still have $292 million stolen because of a problem with the bridge validator configuration.

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

Timeline

12 days. The signal has been there all along. The question is: how can the ecosystem build up the tools to see these signals before the next bridge collapses?

What you can do

If you have assets in a DeFi protocol with cross-chain bridges:

1. Run an audit yourself. The tool is open source. Don't trust us—verify it yourself.
2. Check the bridge validator configuration. If a protocol is unwilling to disclose its DVN threshold, treat it as a red flag. Our report did just that, and it proved to be correct.
3. Don't assume that code audits cover everything. Kelp has had more than five code audits conducted by well-known companies and platforms (Code4rena, SigmaPrime, MixBytes). Traditional code audits are designed to exclude catching configuration-level risks like DVN threshold settings—that's a different kind of analysis, not a failure on the part of the auditing firm.
4. Assess insurance coverage. If a protocol doesn't have an insurance pool, and you're a limited partner (LP) on a lending platform that accepts its tokens as collateral, you're implicitly underwriting it. WETH depositors at Aave learned this the hard way.

The bigger picture: AI Agent as a security layer

This article tells the story of a tool and a theft. But the underlying claim is broader: AI agents can serve as a separate security layer for DeFi investors.

The traditional security model in the crypto industry looks like this: the protocol hires an auditing firm, the auditing firm reviews the code, and the auditing firm issues a report. This model has blind spots—the Kelp incident illustrates this point; it focuses on code correctness but overlooks configuration, governance, and architectural risks.

Claude Code and similar tools offer an alternative path: anyone can use publicly available data to run an AI-assisted risk assessment of any protocol in minutes. You don't need to spend $200,000 on an auditing firm. You don't need to know Solidity. You have an agent compare the protocol architecture against known attack patterns, and it will present the questions you should have asked before depositing any money.

This won't replace professional audits—but it lowers the barrier to entry for first-tier due diligence to a level accessible to everyone. An LP considering investing in a new restaking protocol can now run an audit defi protocol and obtain a structured risk assessment covering governance, oracles, bridges, and economic mechanisms. This represents a real shift in how retail and mid-sized investors protect themselves.

Kelp's report wasn't perfect. It rated the bridge risk as moderate, which should be considered severe. It didn't penetrate the configuration layer. But it asked the right questions—the $292 million loss could have been avoided if the Kelp team or any LPs had taken these questions seriously at the time.