Author: Zengineer
Compiled by: Deep Tide TechFlow
Deep Tide Introduction: On April 18, Kelp DAO was hacked for $292 million, making it the largest DeFi incident so far in 2026. The vulnerability wasn't in the contract code, but in the LayerZero cross-chain bridge's 1-of-1 verifier node configuration—a single point of failure that allowed the forging of cross-chain messages. The author, using their own open-source AI auditing tool to scan Kelp 12 days prior, had already flagged this risk. This article reviews the entire attack process and honestly reflects on three things the tool got wrong at the time.
What is Kelp DAO
Kelp DAO is a liquidity restaking protocol built on top of EigenLayer. The mechanism is as follows: users deposit ETH or liquid staking tokens (stETH, ETHx) into Kelp contracts, which then delegate the assets to EigenLayer operator nodes for restaking—simultaneously providing security to multiple AVSs (Actively Validated Services). In return, users receive rsETH as a certificate. 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 achieve this cross-chain liquidity, Kelp deployed rsETH on over 16 chains using LayerZero's OFT (Omnichain Fungible Token) standard. When you bridge rsETH from Ethereum to an L2, LayerZero's DVN (Decentralized Verifier Network) verifies whether the cross-chain message is legitimate. This bridge architecture is the core of the subsequent story.
Kelp was initiated by Amitej Gajjala and Dheeraj Borra (previously co-founder of Stader Labs), launched in December 2023, with a peak TVL of $2.09 billion. Governance uses a 6/8 multi-signature wallet plus a 10-day timelock for contract upgrades. The governance token KERNEL governs the Kelp, Kernel, and Gain product lines.
The Hack
On April 18, 2026, an attacker drained 116,500 rsETH, worth approximately $292 million, from Kelp DAO's cross-chain bridge—the largest DeFi attack of 2026 so far. The root cause was not a smart contract vulnerability, but a configuration issue: a 1-of-1 DVN setup (meaning only 1 verifier node, validated by 1 signature) allowed the attacker to forge cross-chain messages by compromising a single node.
12 days prior, on April 6, my open-source security auditing tool had flagged this attack surface.
Let me be clear first: this hack resulted in real people losing real money. Aave WETH depositors who never touched rsETH had their funds frozen; LPs across multiple protocols are facing bad debt they never signed up for. This article analyzes what happened and what our tool caught—but the actual cost to people is more important than any scorecard.
The full report is hosted on GitHub, with a commit timestamp anyone can verify. Below is what we caught, what we missed, and what this means for DeFi security tools.
46 Minutes That Shook DeFi
At 17:35 UTC on April 18, the attacker compromised the isolated DVN verifier node and had it "approve" a forged cross-chain message. LayerZero's Endpoint, seeing the DVN's approval, passed the message via lzReceive to Kelp's OFT contract—which complied, minting 116,500 rsETH on the Ethereum mainnet. The message claimed equivalent assets were locked as collateral on another chain. Those assets never existed.
What followed was a standard DeFi money laundering process:
- Deposit the stolen rsETH as collateral into Aave V3, Compound V3, Euler
- Borrow approximately $236 million in WETH using this unbacked collateral
- Consolidate around 74,000 ETH and cash out via Tornado Cash
46 minutes later, at 18:21, Kelp's emergency pause multi-signature froze the contracts. The attacker then attempted two follow-up attacks (40,000 rsETH each, ~$100 million) which were reverted—this pause blocked an additional $200 million.
But the fallout was still severe. Aave V3 absorbed approximately $177 million in bad debt. The AAVE token plummeted 10.27%. ETH fell 3%. WETH utilization on Aave instantly maxed out to 100% as depositors rushed to withdraw. rsETH on over 20 L2s became assets of questionable value overnight.
What the April 6th Report Caught
In early April, shortly after the April 1st Drift Protocol hack of $285 million, I wrote 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's not a code scanner or a formal verification tool. The Drift incident made me realize: what causes the biggest losses isn't in the smart contract code—it's in governance vulnerabilities, configuration oversights, architectural blind spots, places code scanners never see. So I built a tool specifically to assess these layers: governance structure, oracle dependencies, economic mechanisms, cross-chain architecture, comparing each protocol against attack patterns from historical hacks (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 lenient—those unanswered cross-chain information gaps should have pulled it lower. But even with a medium risk rating, the report pointed to the attack surface that was later exploited.
The screenshot below is the original text from the "Information Gaps" section of the report—the question about Kelp's DVN configuration that became the root cause of the $292 million theft:
Caption: The "Information Gaps" section from the April 6th report directly named DVN configuration opacity.
Let's go through what the report flagged versus what actually happened.
Finding 1:DVN Configuration Opacity(Warning Sign)
Report原文: "LayerZero DVN configuration (verifier sets per chain, threshold requirements) not publicly disclosed"
What Actually Happened: Kelp was running a 1-of-1 DVN configuration. One node. One single point. The attacker compromised this one node and forged cross-chain messages. If the configuration had been 2-of-3 (the industry minimum recommendation), the attacker would have needed to compromise multiple independent verifiers simultaneously.
Let's be clear: this is Kelp's issue, not LayerZero's. LayerZero is infrastructure—it provides the DVN framework, and each protocol chooses its own configuration: how many verifiers (1-of-1, 2-of-3, 3-of-5...), whose nodes to use, 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 enable it.
An analogy: AWS provides MFA (Multi-Factor Authentication). If your account gets hacked because you never turned on MFA, that's your problem, not AWS's. LayerZero made the security mechanisms available; Kelp didn't use them.
Our report couldn't determine the specific DVN threshold at the time (because Kelp never disclosed it), but we explicitly listed this opacity as an unresolved information gap and risk item. The unwillingness to disclose itself is a red flag.
Finding 2:Single Point of Failure Across 16 Chains(Direct Hit)
Report原文: "Single point of failure in LayerZero DVN could simultaneously affect rsETH on all 16 supported chains"
What Actually Happened: The forged message hit the Ethereum mainnet directly, and the shockwave spread to all chains where rsETH was deployed. LayerZero preemptively paused all OFT bridges outgoing from Ethereum. Holders of rsETH on over 20 L2s were left with tokens of questionable backing overnight.
This is the systemic risk of multi-chain deployment: rsETH was circulating on Arbitrum, Optimism, Base, Scroll, and other L2s simultaneously, but the value of all these tokens derived from assets on the Ethereum mainnet. Once the mainnet bridge was compromised, rsETH on every L2 simultaneously lost its backing—holders could neither redeem nor verify if their tokens were still valuable. Lido's earnETH (which holds rsETH exposure), Ethena's LayerZero bridge—all were forced to pause. The blast radius extended far beyond Kelp itself.
Finding 3:Unaudited Cross-Chain Governance Control(Related Issue)
Report原文: "Governance control over LayerZero OFT configuration across chains is unverified—specifically: whether these controls reside with the same 6/8 multi-sig and 10-day timelock, or are managed by independent admin keys"
What Actually Happened: The DVN configuration was clearly not under the strict governance of the core protocol. If bridge configuration changes were also governed by the 6/8 multi-sig + 10-day timelock, a 1-of-1 DVN setup would require consent from 6 out of 8 signers—a configuration unlikely to have gone unnoticed.
This exposes a common governance blind spot: many protocols impose strict multi-sigs and timelocks on core contract upgrades, but operational changes—bridge configurations, oracle parameters, whitelist management—are often modifiable by a single admin key. Kelp's core protocol governance was industry-leading (6/8 multi-sig + 10-day timelock), but these protections did not extend to its largest attack surface: the cross-chain bridge.
Finding 4:Matched Ronin/Harmony Attack Pattern(Direct Hit)
Report原文: "The 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 almost perfectly replicated the Ronin playbook—compromise bridge validators, forge messages, drain assets. Our tool's attack pattern matching module, which compares protocol architecture against historical attack categories, correctly identified this as the highest-risk attack vector.
Historical context: In 2022, the Ronin bridge lost $625 million due to 5 out of 9 validators being compromised; that same year, Harmony's Horizon bridge lost $100 million due to 2 out of 5 validators being compromised. Kelp's situation was more extreme—only 1 validator, lowering the attack barrier to an absolute minimum. The tool flagged this risk because it automatically compares protocol architecture against these historical attack patterns, not just the code.
Finding 5:No Insurance Fund(Amplified Losses)
Report原文: "The protocol currently lacks a dedicated insurance pool or socialized loss mechanism to absorb slashing events"
What Actually Happened: With no insurance reserve, the entire $292 million loss was absorbed by downstream protocols. Aave's safety module covered less than 30% of its $177 million bad debt. LPs who had nothing to do with Kelp's bridge configuration decision bore the brunt of the impact.
The attacker deposited the stolen rsETH as collateral into Aave V3, Compound V3, Euler, and borrowed real WETH. Once rsETH was confirmed to be unbacked, these positions became "unliquidatable" bad debt—the collateral was worthless, but the borrowed WETH was gone. WETH utilization on Aave instantly maxed out, preventing ordinary users from withdrawing. 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 only covered specific vault products, not the core rsETH protocol exposure.
This is a failure of responsibility on both sides. Kelp's side: A protocol managing $1.3 billion TVL had zero insurance pool, zero loss absorption mechanism. When the bridge was compromised, there was no buffer to absorb the damage. Aave's side: It accepted rsETH as collateral but did not sufficiently assess its cross-chain bridge configuration risk. Aave's risk parameters (LTV, liquidation threshold) were designed for normal price volatility, not the tail risk of "bridge configuration compromise rendering collateral worthless overnight." The safety module couldn't even cover 30% of the bad debt. Essentially, this was a risk pricing failure: Aave treated rsETH as a normally fluctuating asset, but it actually carried the tail risk of bridge failure. The failures compounded—Kelp had no insurance to prevent bad collateral from entering the system, and Aave didn't do sufficiently granular risk modeling to limit exposure in such a scenario.
Where We Were Wrong
Three things could have been done better:
Underrated the risk. We rated the cross-chain bridge risk as "Medium." The report had 5 unresolved information gaps, 3 of which were related to LayerZero bridge configuration, plus a match to historical attack patterns like Ronin/Harmony—this should have been "High" or "Critical." Opacity itself should have been a stronger signal.
We failed to penetrate the configuration layer. The report repeatedly asked Kelp to disclose the DVN threshold, but we couldn't verify it independently. This is the same structural blind spot pointed out in post-mortem analyses: existing auditing tools focus on code logic and miss configuration-layer risks. We flagged the problem but couldn't answer it.
We didn't check on-chain. The DVN configuration could 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 labeling it "not publicly disclosed." If we had checked, we would have directly seen the 1-of-1 configuration, no Kelp disclosure needed. This is the most specific area for tool improvement: add on-chain DVN configuration verification to the cross-chain assessment step.
Findings weren't specific or actionable enough. Saying "DVN configuration not disclosed" is an observation about missing documentation—not a prediction of an attack. These risks (oracle centralization, bridge dependency, lack of insurance) are also普遍 (widespread) across most cross-chain DeFi protocols. The tool flagged Kelp's opacity, but it has also flagged similar patterns on dozens of protocols that weren't attacked. Without published false positive rates, claiming "we predicted it" is an overstatement. A more honest assessment is: we asked some correct questions that no one else was asking, and one of them happened to hit the critical load-bearing 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 didn't notify. The reason: The report identified opacity—"DVN configuration not disclosed"—not a specific, exploitable vulnerability. We didn't know the configuration was 1-of-1, only that it wasn't public. There was nothing concrete enough to disclose. "Your bridge configuration lacks documentation" is a governance observation, not a report suitable for a bug bounty program.
In hindsight, we could have directly contacted the Kelp team and asked about their DVN threshold. That conversation might have exposed the 1-of-1 configuration and prompted a fix. We didn't do that. It's a lesson: even if a finding seems too vague for formal disclosure, sending a private message to ask is still worthwhile.
What This Means for DeFi Security
The Kelp hack—like the Drift hack 17 days prior—was not a smart contract vulnerability. Automated code scanners like Slither, Mythril, or even GoPlus couldn't catch it. The vulnerability hid in deployment configurations, governance gaps, and architectural decisions, residing above the code layer.
This is also the core proposition of the crypto-project-security-skill:
Protocol security is more than just code security. A protocol can have perfect Solidity, five audits from top firms, a $250k bug bounty—and still lose $292 million due to a verifier configuration issue.
The tool is open-source on GitHub—anyone can review the methodology, run it themselves, or improve it.
Timeline
12 days. The signal was there. The question is: How does 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 yourself.
- Check bridge verifier configuration. If a protocol is unwilling to disclose its DVN threshold, treat it as a red flag. Our report did exactly that, and it was right.
- Don't assume code audits cover everything. Kelp had 5+ code audits from renowned 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 type of analysis, not a failure of the audit firms.
- Evaluate insurance coverage. If a protocol has no insurance pool, and you are an LP on a lending platform that accepts its token as collateral, you are implicitly underwriting its risk. Aave's WETH depositors learned this the hard way.
The Bigger Picture: AI Agent as a Security Layer
This article is about one tool and one hack. But the underlying proposition is larger: AI Agents can become an independent security layer for DeFi investors.
The traditional security model in crypto is this: Protocols hire audit firms, audit firms look at code, audit firms issue reports. This model has blind spots—the Kelp incident illustrates this perfectly. It focuses on code correctness but misses configuration, governance, and architectural risks.
Claude Code and skill tools like this offer another 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 on an audit firm. You don't need to read Solidity. You let the agent compare the protocol's architecture against known attack patterns, and it surfaces 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 a level accessible to everyone. An LP considering allocating funds to a new restaking protocol can now run `audit defi
That Kelp report wasn't perfect. It rated bridge risk as Medium, should have been Critical. It didn't penetrate the configuration layer. But it asked the right questions—and if the Kelp team or any LP had taken those questions seriously at the time, the $292 million loss could have been avoided.
