An open-source AI tool that no one is watching warned about the $292 million vulnerability of Kelp DAO 12 days ago.

AI Agent can become an independent security layer for DeFi investors.

Author: Zengineer

Compiled by: Deep Tide TechFlow

Deep Tide Introduction: On April 18, Kelp DAO was hacked for $292 million, the largest DeFi incident of 2026 so far. The vulnerability was not in the contract code, but in the 1-of-1 validation node configuration of the LayerZero cross-chain bridge—if a single point fails, cross-chain messages can be forged. Twelve days ago, when scanning Kelp using my self-developed open-source AI auditing tool, this risk point had already been flagged. This article reviews the entire attack process and honestly reflects on three things our tool did not address at the time.

What is Kelp DAO

Kelp DAO is a liquidity re-staking protocol built on EigenLayer. The mechanism is as follows: users deposit ETH or liquid staked tokens (stETH, ETHx) into the Kelp contract, which then entrusts the assets to the operational nodes of EigenLayer for re-staking—simultaneously providing security to multiple AVS (Actively Validated Services). In return, users receive rsETH as a certificate. Unlike direct re-staking on EigenLayer (where assets are locked), rsETH is liquid—can be traded, used as collateral in lending protocols like Aave, and can be cross-chain.

To achieve this cross-chain liquidity, Kelp deployed rsETH using LayerZero's OFT (Omnichain Fungible Token) standard on over 16 chains. When you cross rsETH from Ethereum to a certain L2, LayerZero's DVN (Decentralized Verifier Network) verifies whether this cross-chain message is legitimate. This bridge architecture is central to the story that follows.

Kelp was initiated by Amitej Gajjala and Dheeraj Borra (both former co-founders of Stader Labs) and went live in December 2023, with a peak TVL of $2.09 billion. Governance employs a 6/8 multi-signature with a 10-day contract upgrade time lock. The governance token KERNEL oversees Kelp, Kernel, and Gain three product lines.

The Theft Incident

On April 18, 2026, attackers withdrew 116,500 rsETH from Kelp DAO's cross-chain bridge, approximately $292 million—the largest DeFi attack incident of 2026 so far. The root cause was not a smart contract vulnerability, but a configuration issue: a 1-of-1 DVN setting (which means only 1 validation node, with one signature counting), allowed attackers to forge cross-chain messages with a single compromised node.

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

First, I want to clarify: this theft represents real losses for real people. Depositors of Aave WETH, who had never dealt with rsETH, found their funds frozen; multiple LPs in various protocols had to bear bad debts they had not agreed to take on. This article analyzes what happened, what our tool captured—yet the actual costs of people's losses are more significant than any scorecard.

The full report is available on GitHub, with a commit timestamp that anyone can verify. Below, I will discuss what we identified, what we missed, and what this incident means for DeFi security tools.

46 Minutes, DeFi Shock

At 17:35 UTC on April 18, the attacker compromised that isolated DVN validation node and had it "approve" a forged cross-chain message. LayerZero's Endpoint saw that the DVN had passed, then relayed the message to Kelp's OFT contract via lzReceive—the contract complied, minting 116,500 rsETH on the Ethereum mainnet. The message claimed that equivalent assets had been locked on other chains as collateral. Those assets never existed.

Next was a standard DeFi money laundering process:

Deposit the stolen rsETH as collateral into Aave V3, Compound V3, Euler
Using those collateral without real backing, borrow approximately $236 million in WETH
Consolidate around 74,000 ETH and cash out through Tornado Cash

Forty-six minutes later at 18:21, Kelp's emergency pause multi-signature froze the contract. The attackers then made two more attempts (each for 40,000 rsETH, about $100 million), both of which were reverted—this pause blocked about $200 million.

Yet the impact was still devastating. Aave V3 absorbed around $177 million in bad debts. The AAVE token plummeted by 10.27%. ETH dropped 3%. The usage rate of WETH on Aave shot up to 100%, with depositors rushing to withdraw. rsETH across more than 20 L2s suddenly became assets of questionable value overnight.

What the Report Captured on April 6

In early April, shortly after the $285 million theft of Drift Protocol on April 1, I created an open-source Claude Code skill crypto-project-security-skill—an AI-assisted architectural risk assessment framework that uses public data (DeFiLlama, GoPlus, Safe API, on-chain verification) to assess DeFi protocols. It is not a code scanner nor a formal verification tool. The Drift incident made me realize: the real drivers of maximal losses lie not in smart contract code—but in governance loopholes, configuration negligence, and architectural blind spots, areas which code scanners will never see. Thus, I developed a tool specifically for assessing these layers: governance structure, oracle dependencies, economic mechanisms, cross-chain architecture, comparing each protocol with the attack patterns of historically notable attacks (Drift, Euler, Ronin, Harmony, Mango).

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

The report provided Kelp with a comprehensive triage score of 72/100 (medium risk). In hindsight, this score was too lenient—the unanswered cross-chain information gaps should have lowered the score. But even with a medium risk rating, the report highlighted the attack surface that would be exploited later.

The screenshot below is the original text from the report's "Information Gap" section—regarding the issue with Kelp's DVN configuration, which ultimately became the root cause of the $292 million theft:

Caption: The "Information Gap" chapter from the April 6 report, where the lack of transparency in the DVN configuration was directly named

Below is a line-by-line comparison of what was marked in the report, how it was actually exploited.

Finding 1:DVN configuration lack of transparency (warning sign)

Report Text: “LayerZero's DVN configuration (validator set for each chain, threshold requirements) has not been publicly disclosed”

What Actually Happened: Kelp operated with a 1-of-1 DVN configuration. One node. One single point. If the attacker compromised that one node, they could forge the cross-chain message. If the configuration had been 2-of-3 (the industry minimum recommendation), the attacker would have had to simultaneously compromise multiple independent validators.

It’s important to clarify one thing: this is a problem with Kelp, not LayerZero. LayerZero is infrastructure—it provides the DVN framework, each protocol chooses its configuration: how many validation nodes (1-of-1, 2-of-3, 3-of-5...), whose nodes to use, and what the threshold is for each chain. Kelp chose 1-of-1 when deploying the OFT bridge. LayerZero fully supports 2-of-3 or higher configurations—but Kelp chose not to enable it.

To put this in perspective: AWS provides MFA (multi-factor authentication). If your account is hacked because you never turned on MFA, that's your problem, not AWS's. LayerZero laid out the security mechanism, Kelp did not use it.

Our report at the time could not ascertain the specific DVN threshold (because Kelp never disclosed it), but we explicitly listed this opacity as an unresolved information gap and risk item. The unwillingness to disclose is a red flag in itself.

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

Report Text: “Single point of failure of LayerZero DVN may simultaneously affect rsETH on 16 supported chains”

What Actually Happened: The forged message directly hit the Ethereum mainnet, sending shockwaves across all chains deploying rsETH. LayerZero proactively paused all OFT bridges outgoing from Ethereum. Holders of rsETH on over 20 L2s found their tokens suddenly void of assurance overnight.

This reflects a systemic risk of multi-chain deployment: rsETH circulates on L2s like Arbitrum, Optimism, Base, Scroll, etc., but the value of all these tokens derives from assets on the Ethereum mainnet. Once the mainnet bridge was compromised, all rsETH on each L2 simultaneously lost their guarantee—holders couldn't redeem nor verify whether the tokens they held still held value. Lido's earnETH (holding rsETH exposure), Ethena's LayerZero bridge—all were forced to pause. The blast radius exceeded Kelp itself.

Finding 3:Unverified governance control over cross-chain (related issue)

Report Text: “Governance control over LayerZero OFT configuration across chains has not been verified—especially: whether this control belongs to the same 6/8 multi-signature and 10-day time lock, or is controlled by independent management keys”

What Actually Happened: The DVN configuration was evidently not under strict governance of the core protocol. If changes to the bridge configuration were also governed by a 6/8 multi-signature and 10-day time lock, then a 1-of-1 DVN setting would require that 6 out of 8 signers agree—which is unlikely to go unmonitored for long.

This exposed a common governance blind spot: many protocols set strict multi-signature and time lock for core contract upgrades, but operational changes—bridge configurations, oracle parameters, whitelist management—often can be changed by a single admin key. Kelp's core protocol governance is industry-leading (6/8 multi-signature + 10-day time lock), but these protections did not extend to its largest attack surface: the cross-chain bridge.

Finding 4:Matched Ronin/Harmony attack patterns (direct hit)

Report Text: “The most relevant historical precedent involves bridge security. Kelp's LayerZero deployment across 16 chains brings operational complexity similar to Ronin's multi-chain architecture”

What Actually Happened: The attack path almost perfectly replicated the Ronin playbook—compromising the bridge validator, forging messages, draining assets. Our tool's attack pattern matching module correctly identified this as the highest risk attack vector by comparing protocol architecture with historical attack categories.

Historical Context: In 2022, the Ronin bridge was compromised due to 5 out of 9 validators being attacked, resulting in a $625 million loss; in the same year, Harmony's Horizon bridge lost $100 million due to 2 out of 5 validators being compromised. Kelp's situation was even more extreme—only 1 validator lowered the attack threshold to an absolute minimum. The tool was able to flag this risk precisely because it automatically compares protocol architecture with these historical attack patterns instead of just looking at the code.

Finding 5:No insurance pool (amplified losses)

Report Text: “The protocol currently lacks a dedicated insurance pool and social loss-sharing mechanism to absorb penalty incidents”

What Actually Happened: Due to the absence of insurance reserves, the entire $292 million loss was absorbed by downstream protocols. Aave's recovery reserves covered less than 30% of its $177 million bad debt. LPs—unrelated to Kelp's bridge configuration decisions—bore the brunt of the impact.

The attackers used the stolen rsETH as collateral, depositing it into Aave V3, Compound V3, Euler, and then borrowed real WETH. Once the rsETH was confirmed as unbacked, these positions turned into "uncollateralizable" bad debts—the collateral became worthless, but the borrowed WETH was already gone. The usage rate of WETH on Aave shot up to 100%, and ordinary users could not withdraw. If you were a WETH depositor on Aave, even if you had never touched rsETH, your funds were affected. Kelp's insurance partnership with Nexus Mutual only covered specific treasury products, not the core rsETH protocol exposure.

This is a failure of responsibility on both sides. On Kelp's side: a protocol managing $1.3 billion in TVL, with zero insurance pool and no loss absorption mechanisms. When the bridge was compromised, there was no buffer to absorb the damage. On Aave's side: accepting rsETH as collateral without adequate assessment of its cross-chain bridge configuration risks. Aave's risk parameters (LTV, liquidation threshold) were designed for normal price fluctuations but did not consider tail risks like "bridge configuration compromised causing collateral to drop to zero overnight." Recovery reserves could not even cover 30% of the bad debts. Essentially, this was a failure of risk pricing: Aave treated rsETH as an asset with normal volatility, but it actually carried the binary tail risk of bridge failure. The failures on both sides combined—Kelp did not have insurance to prevent bad collateral from entering the system, while Aave did not conduct sufficiently detailed risk modeling to limit exposure in such scenarios.

Where We Went Wrong

There were three things that should have been done better:

Risk ratings were too low. We rated the cross-chain bridge risk as "medium." Among the 5 unresolved information gaps in the report, 3 were related to LayerZero bridge configuration, which matched the historical attack patterns of Ronin/Harmony—this should have been rated as "high" or "critical." The lack of transparency should have been a stronger signal.

We failed to penetrate the configuration layer. The report repeatedly requested Kelp to disclose the DVN thresholds, but we could not verify independently. This is exactly the same structural blind spot pointed out by the analysis by CNYES: existing auditing tools focus on code logic and miss risks at the configuration layer. We flagged the issue but could not provide answers.

We did not check on-chain. The DVN configuration could actually have been read directly on-chain through LayerZero's EndpointV2 contract. We could have queried the ULN302 registry to independently verify Kelp's DVN thresholds, rather than marking it as "not publicly disclosed." Had we checked at the time, we would have seen the 1-of-1 configuration directly, without needing Kelp to disclose it. This is the most specific direction for tool improvement: to add on-chain DVN configuration verification in cross-chain assessment steps.

Findings were not specific enough, nor actionable. Saying "DVN configuration not disclosed" observes document deficiencies—not predicting an attack. These risks (oracle centralization, bridge dependency, lack of insurance) are actually also commonly found in most cross-chain DeFi protocols. The tool flagged Kelp's opacity, but it had previously flagged similar patterns in dozens of protocols that were not attacked. Without disclosing false positive rates, claiming "we predicted this" is an exaggeration. A more honest statement is: we asked some correct questions that no one had been asking, one of which happened to touch a critical pain point.

On "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 did not notify them. The reason was: the report identified opacity—“DVN configuration not disclosed,” which is not a specific exploitable vulnerability. We did not know the configuration was 1-of-1, only that the configuration was not publicly available. There was nothing concrete to disclose. “Your bridge configuration lacks documentation” is a governance observation, not a report suitable for submitting to a bug bounty program.

In retrospect, we could have contacted the Kelp team directly to ask about their DVN thresholds. That conversation might have exposed the 1-of-1 configuration and prompted a fix. We did not do this. This is a lesson: even if a finding seems too vague to follow formal disclosure processes, it is still worthwhile to send a private message to inquire.

What This Means for DeFi Security

Kelp's theft—like the Drift theft 17 days prior—was not due to smart contract vulnerabilities. Automated code scanners like Slither, Mythril, and even GoPlus did not capture it. The vulnerability lies in deployment configurations, governance gaps, and architectural decisions, situated above the code layer.

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

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

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

Timeline

12 days. The signals had been there all along. The question is: how can the ecosystem build tools that can see these signals before the next bridge falls?

What You Can Do

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

Run an audit yourself. The tool is open source. Don’t trust us—verify for yourself.
Check the bridge validator configuration. If a protocol is unwilling to disclose its DVN threshold, consider it a red flag. Our report did just that, and it proved correct.
Don’t assume code audits cover everything. Kelp underwent more than 5 audits from reputable firms and platforms (Code4rena, SigmaPrime, MixBytes). Traditional code audits are not designed to capture risks like DVN threshold settings at the configuration layer—that's another category of analysis, not a failure of the auditing company.
Assess insurance coverage. If a protocol lacks an insurance pool and you’re an LP on a lending platform that accepts its tokens as collateral, you’re implicitly insuring it. This was a hard lesson learned by WETH depositors on Aave in this instance.

The Bigger Picture: AI Agent as a Security Layer

This article discusses a tool and a theft. But the underlying claim is bigger: AI Agent can become an independent security layer for DeFi investors.

The traditional security model in the crypto industry works like this: protocols hire auditing firms, auditing firms review the code, and auditing firms issue reports. This model has blind spots—Kelp’s incident illustrates this, as it focuses on code correctness but overlooks configuration, governance, and architectural risks.

Claude Code and similar skill tools provide another path: anyone can run an AI-assisted risk assessment on any protocol in minutes using public data. You don’t need to spend $200,000 hiring auditors. You don’t need to know how to read Solidity. You have the agent compare the protocol architecture against known attack patterns, and it will present you with the questions you should be asking before placing your funds.

This will not replace professional audits—but it lowers the barrier for first-level due diligence to a level that everyone can use. An LP considering putting funds into a new re-staking protocol can now run an audit, receiving a structured risk assessment covering governance, oracles, bridges, and economic mechanisms. This represents a real shift in how retail and mid-tier investors can protect themselves.

The Kelp report is not perfect. It rated bridge risk as medium, when it should have been serious. It did not penetrate the configuration layer. But it asked the right questions—if the Kelp team or any LP had taken those questions seriously, the $292 million loss could have been avoided.

References

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。