$293 Million Evaporated, Zero Code Vulnerabilities: The 2026 Largest Hack Case Reveals DVN Configuration Security Blind Spots

On April 18, 2026, attackers drained 116,500 rsETH, worth approximately $293 million at the time, from the cross-chain bridge of Kelp DAO's liquid restaking protocol within a few hours. The entire process was unusually efficient. From forging cross-chain messages to dispersing the stolen funds across three lending protocols—Aave V3, Compound V3, and Euler—to borrow real assets, the attackers exited the same day with $236 million worth of WETH. Aave, SparkLend, and Fluid subsequently froze all rsETH markets.

This was the largest DeFi attack of 2026 to date.

However, one aspect distinguishes this attack from most hacks. There was no vulnerability in Kelp DAO's smart contract code. Security researcher @0xQuit, who participated in the investigation, wrote on X, "From what I can tell so far, this is a combination of two issues: a 1-of-1 DVN configuration, and the DVN node itself being compromised." LayerZero's official statement also did not mention contract code, framing the issue as an "rsETH vulnerability" rather than a "LayerZero vulnerability."

The $293 million vulnerability wasn't in any line of code. It was hidden in a configuration parameter that was incorrectly set during deployment.

The general logic of DeFi security audits is: find the contract, read the code, find the vulnerability. This logic works quite smoothly for code logic vulnerabilities. Tools like Slither and Mythril are relatively mature at detecting known patterns like reentrancy attacks and integer overflows. LLM-assisted code auditing, heavily promoted in recent years, also has some capability for business logic vulnerabilities (such as flash loan arbitrage paths).

But two rows in this matrix are red.

Configuration-layer vulnerabilities represent a structural blind spot in tool-based audits. The problem with Kelp DAO wasn't in a .sol file, but in a parameter written during protocol deployment—the DVN threshold. This parameter determines how many validator nodes must confirm a cross-chain message for it to be considered legitimate. It doesn't enter the code, doesn't enter Slither's scanning scope, and doesn't enter Mythril's symbolic execution path. 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 is based on the premise that "the vulnerability is 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 is no tool that can "detect whether the DVN threshold is reasonable." To detect such configuration risks, what's needed is not a code analyzer, but a specialized configuration checklist: "Number of DVNs for the cross-chain protocol used ≥ N?"; "Is there a minimum threshold requirement?" Such questions currently have no standardized tool coverage, nor even widely accepted industry norms.

Also in the red zone are key and node security. @0xQuit's description mentioned the DVN node being "compromised," which falls under operational security (OpSec), beyond the detection boundaries of any static analysis tool. Whether it's a top-tier audit firm or an AI scanning tool, none have the ability to predict whether a node operator's private key will be leaked.

This attack simultaneously triggered both red zones in the matrix.

DVN is LayerZero V2's cross-chain message verification mechanism, short for Decentralized Verifier Network. Its design philosophy is to delegate security decision-making to the application layer: each protocol integrated with LayerZero can choose how many DVN nodes must simultaneously confirm a cross-chain message before it is allowed through.

This "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 only needs to compromise that one node to forge any cross-chain message. In contrast, Apechain, also integrated with LayerZero, configured more than two required DVNs and was not affected in this incident. The subtext of LayerZero's official statement, "all other applications remain secure," is: security depends on which configuration you chose.

The normal industry recommendation is at least 2-of-3, requiring an attacker to simultaneously compromise two independent DVN nodes to forge a message, raising fault tolerance to 33%. High-security configurations like 5-of-9 can achieve 55% fault tolerance.

The problem is, external observers and users cannot see this configuration. Both are called "powered by LayerZero," but one could have 0% fault tolerance and the other 55%. Both are called DVN in the documentation.

Seasoned crypto investor Dovey Wan, who experienced the Anyswap incident, wrote directly on X: "LayerZero's DVN is actually 1/1 validator... All cross-chain bridges should immediately conduct a comprehensive security review."

In August 2022, a vulnerability was discovered in the Nomad cross-chain bridge. Someone copied the first attack transaction, made slight modifications, found it also worked—so hundreds of addresses successively began copying, draining $190 million within hours.

Nomad's post-mortem analysis stated the vulnerability originated from "initializing the trusted root to 0x00 during a routine upgrade." This was a configuration error that occurred during the deployment phase. The Merkle proof verification logic was fine, the code itself was fine; the problem was an incorrect initial value.

Combined with Nomad, configuration/initialization class vulnerabilities have now caused approximately $482 million in losses. In the entire history of cross-chain bridge thefts, this category's scale is now comparable to key leak incidents (Ronin $624 million, Harmony $100 million, Multichain $126 million, totaling approximately $850 million).

But the product design of the code audit industry has never targeted this category.

The industry still discusses code logic vulnerabilities the most. Wormhole's $326 million hack due to signature verification bypass, Qubit Finance's $80 million theft due to fake deposit events. These cases have complete vulnerability analysis reports, CVE number analogies, and reproducible PoCs, suitable for training and optimizing audit tools. Configuration-layer problems aren't written in code, making it difficult to enter this production cycle.

A noteworthy detail is that the triggering methods of the two configuration-class events were completely different. Nomad accidentally entered a wrong initial value during a routine upgrade, a mistake. Kelp DAO's 1-of-1 was an active configuration choice—the LayerZero protocol did not prohibit this option, and Kelp DAO did not violate any protocol rules. A "compliant" configuration choice and a "mistaken" initial value ultimately led to the same consequence.

The execution logic of this attack was simple: a forged cross-chain message told the Ethereum mainnet, "equivalent assets have 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" and could be accepted as collateral by lending protocols.

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

This bill ultimately fell on those who just wanted to earn a bit of WETH interest.

As of publication, LayerZero officials are still jointly investigating with the security emergency response organization SEAL Org, stating they will release a post-mortem analysis report with Kelp DAO after obtaining all information. Kelp DAO stated it is conducting "active remediation."

The $293 million vulnerability wasn't in the code. The phrase "audit passed" did not cover the location of that parameter.