On April 18, 2026, Kelp DAO's liquidity re-staking protocol was attacked, leading to the withdrawal of 116,500 rsETH from the cross-chain bridge by the attacker within a few hours, amounting to approximately $293 million at the time. The entire process was alarmingly efficient, moving from the fabrication of cross-chain messages to dispersing the stolen funds across three lending protocols—Aave V3, Compound V3, and Euler—where real assets were borrowed, allowing the attacker to exit with $236 million in WETH the same day. Aave, SparkLend, and Fluid promptly froze the rsETH market.

This is the largest DeFi attack event to date in 2026.

However, one thing sets this attack apart from most hacking incidents: Kelp DAO's smart contract code contained no vulnerabilities. Security researcher @0xQuit, involved in the investigation, stated on X, "From what I currently know, this is a combination of two issues: the 1-of-1 DVN configuration and the DVN node itself being compromised." The LayerZero official statement also did not mention the contract code, characterizing the issue as a "rsETH vulnerability" rather than a "LayerZero vulnerability."

$293 million is not found in any line of code. It is hidden in a configuration parameter incorrectly filled during deployment.

The general logic of DeFi security auditing is: find the contract, read the code, look for vulnerabilities. This logic operates quite smoothly when addressing code logic vulnerabilities. Tools like Slither and Mythril are quite mature in detecting known patterns such as reentrancy attacks and integer overflows. The recently popular LLM-assisted code audits can also detect some business logic vulnerabilities (e.g., flash loan arbitrage paths).

However, there are two rows of red in this matrix.

Configuration layer vulnerabilities are a structural blind spot in tool audits. The issue with Kelp DAO lies not in the .sol file but in a parameter—DVN threshold—written during protocol deployment. This parameter determines how many validation nodes are required to verify a cross-chain message before it is deemed legitimate. It does not appear in the code, is outside the scanning range of Slither, and does not enter the symbolic execution path of Mythril. According to a comparative study by Dreamlab Technologies, Slither and Mythril detected 5/10 and 6/10 vulnerabilities, respectively, in the tested contracts, but these results are based on the premise that "vulnerabilities are in the code." According to IEEE research, even at the code level, existing tools can only detect 8%-20% of exploitable vulnerabilities.

From the perspective of existing audit paradigms, there are no tools capable of "detecting whether the DVN threshold is reasonable." To assess such configuration risks, what is needed is not a code analyzer, but a specialized configuration checklist: "Is the number of DVNs used for the cross-chain protocol ≥ N?" "Is there a minimum threshold requirement?" Currently, there are no standardized tools covering such questions, nor are there widely recognized industry standards.

Also within the red zone are key and node security. @0xQuit mentioned that the DVN node "was compromised," which falls under operational security (OpSec), exceeding the detection boundaries of any static analysis tool. No top auditing firm or AI scanning tool has the capability to predict whether a node operator's private key will be leaked.

This attack triggered two red zones in the matrix simultaneously.

DVN is the cross-chain message verification mechanism of LayerZero V2, standing for Decentralized Verifier Network. Its design philosophy delegates security decision-making to the application layer: each protocol connecting to LayerZero can choose how many DVN nodes must confirm before a cross-chain message is released.

This "freedom" creates a spectrum.

Kelp DAO opted for the far left end of the spectrum, 1-of-1, requiring only one DVN node for confirmation. This means the fault tolerance rate is zero; an attacker only needs to compromise that one node to fabricate any cross-chain message. In contrast, Apechain, which is also connected to LayerZero but requires two or more mandatory DVNs, was not affected by this incident. The wording in the LayerZero official statement was "all other applications remain secure," implying that security depends on the configuration chosen.

The normal industry recommendation is at least 2-of-3, which means an attacker would need to compromise two independent DVN nodes simultaneously to fabricate a message, increasing the fault tolerance rate to 33%. High-security configurations like 5-of-9 can achieve a fault tolerance rate of 55%.

The problem is that external observers and users cannot see this configuration. What is both labeled as "LayerZero supported" could have 0% tolerance or 55% tolerance. Both are called DVN in the documentation.

Veteran crypto investor Dovey Wan, who experienced the Anyswap incident, directly stated on X, "LayerZero's DVN is actually 1/1 validator... all cross-chain bridges should immediately conduct a comprehensive security audit."

In August 2022, a vulnerability was discovered in the Nomad cross-chain bridge. Someone copied the first attack transaction, made slight modifications, and found it was successful as well—then hundreds of addresses began to replicate, draining $190 million within hours.

The post-analysis of Nomad stated that the vulnerability arose from "initializing the trusted root to 0x00 during a routine upgrade." This is a configuration error that occurred during the deployment stage. There was no issue with the Merkle proof verification logic, and the code itself was fine; the problem was simply an incorrect initial value filled.

This incident and Nomad together have caused approximately $482 million in losses due to configuration/initialization vulnerabilities. In the history of stolen cross-chain bridges, this category of vulnerabilities has reached a scale comparable to key leak cases (Ronin $624 million, Harmony $100 million, Multichain $126 million, totaling about $850 million).

However, the product design of the code auditing industry has never targeted this category.

Discussions in the industry are still mainly focused on code logic vulnerabilities. Wormhole was hacked for $326 million due to signature verification bypass, and Qubit Finance lost $80 million due to false deposit events. These cases have complete vulnerability analysis reports, CVE numbers for comparison, and reproducible PoCs, making them suitable for training and optimization of auditing tools. Configuration layer issues are not written in the code, making them difficult to enter this production loop.

One notable detail is that the triggering methods of the two configuration-related incidents were entirely different. Nomad's issue was an accidental wrong initial value filled during a routine upgrade, categorized as a slip-up. Kelp DAO's 1-of-1 was a proactive configuration choice—LayerZero protocol did not prohibit this option, and Kelp DAO did not violate any protocol rules. A "compliant" configuration choice and a "slip-up" in initial value ultimately led to the same consequence.

The logic of executing this attack was very simple: a fabricated cross-chain message told the Ethereum mainnet that "an equivalent asset has been locked on another chain," triggering the mainnet to mint rsETH. The minted rsETH itself had no actual backing, but its on-chain record was "legitimate," allowing it to be accepted as collateral by lending protocols.

The attacker then dispersed the 116,500 rsETH across Aave V3 (Ethereum and Arbitrum), Compound V3, and Euler, borrowing over $236 million in real assets in total. According to multiple reports, the bad debt valuation faced by Aave V3 alone is approximately $177 million. Aave's security module Umbrella has reserves of WETH to absorb bad debts of about $50 million, covering less than 30%, leaving the remaining portion to be borne by aWETH stakers.

This bill ultimately fell on those who merely wanted to earn a little WETH interest.

As of this writing, LayerZero officials are still investigating jointly with the security emergency response organization SEAL Org, stating they will release a post-analysis report with Kelp DAO once they have all the information. Kelp DAO stated they are taking "proactive remedial actions."

The $293 million vulnerability is not in the code. The four words "audit passed" did not cover the place where that parameter is located.

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