On April 18, 2026, attackers drained 116,500 rsETH from Kelp DAO’s liquid restaking protocol via a cross-chain bridge within hours, worth approximately $293 million at the time. The entire process was unnervingly efficient: from forging cross-chain messages to borrowing real assets across three lending protocols—Aave V3, Compound V3, and Euler—the attacker withdrew $236 million in WETH the same day. Aave, SparkLend, and Fluid immediately froze all rsETH markets.
This is the largest DeFi attack since 2026.
But one thing sets this attack apart from most hacking incidents: Kelp DAO’s smart contract code had no vulnerabilities. Security researcher @0xQuit wrote on X, “Based on what I currently know, this is a combination of two issues: a 1-of-1 DVN configuration and the DVN nodes themselves being compromised.” LayerZero’s official statement also did not mention the contract code, characterizing the issue as an “rsETH vulnerability” rather than a “LayerZero vulnerability.”
$293 million, not in a single line of code. It was hidden in a misconfigured parameter during deployment.
The general logic of DeFi security audits is: find the contract, read the code, and identify vulnerabilities. This approach works well for detecting code logic vulnerabilities; tools like Slither and Mythril are well-established in detecting known patterns such as reentrancy attacks and integer overflows. In recent years, the widespread adoption of LLM-assisted code auditing has also shown some capability in identifying business logic vulnerabilities, such as arbitrage paths involving flash loans.
But there are two red rows in this matrix.
Configuration-layer vulnerabilities represent structural blind spots in tool audits. The issue with Kelp DAO was not in the .sol files, but in a parameter written during protocol deployment—the DVN threshold. This parameter determines how many verification nodes must confirm a cross-chain message before it is considered valid. It does not enter the code, nor does it fall within Slither’s scanning scope or Mythril’s symbolic execution paths. According to comparative research by Dreamlab Technologies, Slither and Mythril detected 5/10 and 6/10 vulnerabilities, respectively, in the tested contracts—but this performance assumes that vulnerabilities reside within the code. According to IEEE research, even at the code level, existing tools can detect only 8%–20% of exploitable vulnerabilities.
From the perspective of existing audit paradigms, there are no tools available to "detect whether the DVN threshold is reasonable." To identify this type of configuration risk, what is needed is not a code analyzer, but a specialized configuration checklist: "Is the number of DVNs used in the cross-chain protocol ≥ N?" "Are there minimum threshold requirements?" Currently, no standardized tools address these questions, nor are there widely accepted industry standards.
Also within the red zone are key and node security. @0xQuit’s description of DVN nodes being “compromised” falls under operational security (OpSec), which lies beyond the detection scope of any static analysis tool. Neither any leading audit firm nor any AI scanning tool can predict whether a node operator’s private key will be leaked.
This attack triggered two red zones within the matrix simultaneously.
DVN is the cross-chain message verification mechanism for LayerZero V2, standing for Decentralized Verifier Network. Its design philosophy delegates security decisions to the application layer: each protocol integrating with LayerZero can independently choose how many DVN nodes must simultaneously confirm a cross-chain message before it is approved.
This "degree of freedom" creates a spectrum.
Kelp DAO chose the far left end of the spectrum: 1-of-1, requiring confirmation from only one DVN node. This means zero fault tolerance— an attacker needs to compromise just that single node to forge any cross-chain message. In contrast, Apechain, which also integrates with LayerZero, configured more than two required DVNs and was unaffected by this incident. LayerZero’s official statement used the phrasing “all other applications remain secure,” implying that security depends entirely on your chosen configuration.
The standard industry recommendation is at least 2-of-3, requiring an attacker to compromise two independent DVN nodes simultaneously to forge a message, increasing fault tolerance to 33%. For higher security configurations, such as 5-of-9, fault tolerance can reach 55%.
The issue is that external observers and users cannot see this configuration. Both a 0% fault tolerance and a 55% fault tolerance may be labeled as “powered by LayerZero,” yet both are referred to as DVN in the documentation.
Dovey Wan, a seasoned crypto investor who experienced the Anyswap incident, wrote directly on X: “LayerZero’s DVN is a 1/1 validator… All cross-chain bridges should immediately undergo a comprehensive security audit.”
In August 2022, a vulnerability was discovered in the Nomad cross-chain bridge. Someone replicated the first attack transaction, made minor modifications, and found it also succeeded—prompting hundreds of addresses to copy the exploit, draining $190 million within hours.
Nomad’s post-mortem stated that the vulnerability originated from “an例行 upgrade during which the trusted root was initialized to 0x00.” This was a configuration error that occurred during deployment. The Merkle proof verification logic was correct, and the code itself was sound—the issue was simply an incorrect initial value.
Together with Nomad, configuration/initiation-type vulnerabilities have resulted in approximately $482 million in losses. Across the entire history of cross-chain bridge thefts, this category is now on par with key compromise incidents (Ronin: $624 million, Harmony: $100 million, Multichain: $126 million, totaling approximately $850 million).
However, product design in the code audit industry has never been targeted at this category.
The most discussed issues in the industry are still code logic vulnerabilities. Wormhole suffered a $326 million exploit due to signature verification bypass, and Qubit Finance lost $80 million due to a fake deposit incident. These cases come with comprehensive vulnerability analysis reports, CVE-like identifiers, and reproducible PoCs, making them ideal for training and optimizing auditing tools. Configuration-layer issues, which are not embedded in the code, are difficult to incorporate into this production cycle.
An important detail to note is that the two configuration-related events were triggered in completely different ways. Nomad’s incident occurred due to an accidental incorrect initial value set during a routine upgrade—an error. In contrast, Kelp DAO’s 1-of-1 configuration was an intentional configuration choice—the LayerZero protocol did not prohibit this option, and Kelp DAO did not violate any protocol rules. A “compliant” configuration choice and an “accidental” initial value ultimately led to the same outcome.
The attack’s logic was straightforward: a forged cross-chain message told the Ethereum mainnet, “Assets of equivalent value have been locked on another chain,” triggering the minting of rsETH on the mainnet. The minted rsETH itself had no real backing, but its on-chain record appeared “legitimate” and was accepted as collateral by lending protocols.
The attacker then distributed 116,500 rsETH across Aave V3 (Ethereum and Arbitrum), Compound V3, and Euler, borrowing over $236 million in real assets. Multiple reports estimate that Aave V3 alone faces bad debt of approximately $177 million. Aave’s safety module, Umbrella, holds around $50 million in WETH reserves to absorb bad debt, covering less than 30% of the loss; the remaining portion will be borne by aWETH stakers.
This cost ultimately fell on those who simply wanted to earn a little WETH interest.
As of the time of this writing, LayerZero is still jointly investigating with the security incident response organization SEAL Org and states that it will jointly release a post-incident analysis report with Kelp DAO once all information has been obtained. Kelp DAO indicates that it is conducting "proactive remediation."
The $293 million vulnerability was not in the code. The four words "audit passed" did not cover the location of that parameter.