Incident Overview

At approximately 17:35 UTC on April 18, 2026, the DeFi sector suffered its largest security incident of the year. The LayerZero cross-chain bridge contract utilized by liquid restaking protocol Kelp DAO was exploited. By forging cross-chain messages, the attacker successfully withdrew 116,500 rsETH — representing roughly 18% of the total rsETH supply — valued at USD 290 million at the time of the attack.

Within minutes, the stolen rsETH was deposited into lending protocols such as Aave V3 as collateral. Because the price oracles had yet to reflect the severe depegging of rsETH, the attacker was able to borrow more than USD 200 million worth of WETH and ETH, effectively transferring the bad debt risk to the wider DeFi ecosystem. Kelp DAO immediately activated its emergency pause mechanism, and multiple related protocols froze their rsETH markets to contain systemic risk.

Post-Mortem: Configuration Single Point of Failure & Infrastructure Poisoning

Executive Summary

This incident was not a typical smart contract code vulnerability. Instead, it was a highly targeted infrastructure compromise met with an insufficiently redundant protocol configuration.

In the LayerZero V2 architecture, security is defined via a modular "configuration authority." Application-layer protocols (OApps) are expected to scale their DVN (Decentralized Verifier Network) settings in tandem with their asset value, utilizing multiple independent DVNs to create a decentralized quorum. However, for Kelp DAO's rsETH, a critical gap existed between its growing Total Value Locked (TVL) and its underlying security threshold, which remained tethered to a 1-of-1 "Default" configuration.

The Anatomy of On-Chain Configuration

In LayerZero V2, security is not a global setting but an on-chain state stored per-OApp (Origin Application). These configurations are defined via the EndpointV2.setConfig() interface, which delegates the storage of security parameters to a specific Message Library — in this case, ReceiveUln302. For the Kelp DAO rsETH contract, the security threshold was governed by the UlnConfig struct, a critical data structure stored in the library's state that explicitly defines the verification quorum:

struct UlnConfig {
 uint64 confirmations; // Blocks to wait for finality
 uint8 requiredDVNCount; // Number of required verifiers (Critical Failure: 1)
 uint8 optionalDVNCount; // Number of optional verifiers
 uint8 optionalDVNThreshold; // Threshold for optional verifiers
 address[] requiredDVNs; // The list of verifier addresses
 address[] optionalDVNs; // The list of optional verifier addresses
}

The Execution Path in UlnBase.sol

To pinpoint the mechanical failure, we must examine the internal _verify function within the ReceiveUln302 implementation (inherited from the UlnBase logic). The vulnerability was not in the presence of a bug, but in the deterministic success of a compromised verification loop under Kelp's specific configuration. When a DVN submits an attestation, the library executes a validation check. The logic follows an iterative verification of the requiredDVNs array:

// Technical execution flow within the ULN verification core
for (uint256 i = 0; i < config.requiredDVNCount; i++) {
 address dvn = config.requiredDVNs[i];
 if (!verifications[headerHash][payloadHash][dvn]) {
 return false; // The loop terminates if any required DVN signature is missing

In Kelp DAO's deployment, the requiredDVNCount was set to 1. This created a binary trust model: the moment the Lazarus-poisoned LayerZero Labs DVN submitted the forged hash, the for loop achieved a 100% success rate on its first and only iteration. Because the optionalDVNThreshold was also set to 0, the secondary verification layer — intended to provide asymmetric redundancy — was completely bypassed. The Root Causeis the 1-of-1 "Default" Inheritance The exploit succeeded because Kelp DAO's UlnConfig on the destination chain was set to a 1-of-1 threshold, requiring only the signature of the LayerZero Labs DVN. This meant the requiredDVNs array contained only a single address, with the optionalDVNThreshold set to zero.

Kelp DAO has since clarified that this configuration originated from the default settings applied during its 2024 onboarding. Within the LayerZero ecosystem, if an OApp owner does not run a custom lz:oapp:wire command or explicitly call setConfig() to override library defaults, the protocol will retain the Default Library Config. As its Total Value Locked (TVL) grew, Kelp DAO remained in a single‑verifier mode. This dependency on one verifier meant that an RPC poisoning attack targeting that verifier's downstream nodes could inject forged validation data into EndpointV2, resulting in an unauthorized release of funds.

Based on LayerZero Labs' KelpDAO Incident Statement

On April 18, 2026, LayerZero Labs' Decentralized Verifier Network (DVN) was subjected to a highly coordinated intrusion, attributed to the Lazarus Group's TraderTraitor unit. The compromise was not the result of flaws in the DVN protocol logic, the verifier software, or cryptographic key management; rather, it was an intentional operation aimed at contaminating the downstream RPC (Remote Procedure Call) infrastructure that the DVN relies upon for consensus-based transaction validation.

The threat actors first enumerated the DVN's trusted RPC endpoint list. They then breached two physically and logically isolated RPC nodes — each running in separate cluster environments with no interconnection — and replaced the legitimate op-geth binaries with maliciously patched versions. This modification created a controlled foothold from which to execute an RPC‑spoofing attack.

Due to LayerZero Labs' least-privilege principles, the attackers were unable to compromise the actual DVN instances. However, they used this pivot point to execute an RPC-spoofing attack. Their malicious nodes used a custom payload designed explicitly to forge messages to the DVN with minimal alerts. Fraudulent data was served exclusively to the DVN, while the nodes provided accurate state data to any other IP addresses, including the LayerZero Labs Scan service and all internal observability infrastructure. This was carefully designed to prevent security monitoring from noticing anomalies. The payload was also designed to self-destruct once the attack concluded, disabling the RPCs and deleting the malicious binaries and corresponding local logs and configs.

However, even this was insufficient to forge a message. LayerZero Labs' DVN setup is trust-minimized and uses both internal and external RPCs for redundancy. In order to complete the attack, the threat actors performed DDoS attacks on the uncompromised RPCs. The DDoS triggered a failover to the poisoned RPCs.

As a result of this manipulation, the LayerZero Labs-operated DVN instance confirmed transactions that never in fact took place.

RPC-verification is a fundamental limitation of all offchain services, including bridges, exchanges, etc. LayerZero Labs share these learnings to help the industry learn and adapt to these novel attack vectors.

Final Exploitation and Impact

Once the misled DVN issued a "valid" verification message, the final safeguard should have been multi-verifier consensus. However, at the time of deployment, Kelp DAO chose an extremely low security threshold and configured the rsETH cross-chain setup to operate in a single-verifier mode (1-of-1).

Because there was no additional DVN for cross-checking, the mainnet EndpointV2 passed the verification process without any challenge. The attacker immediately invoked the execution function, withdrawing 116,500 rsETH to a controlled wallet. Within minutes, the stolen assets were deposited into Aave V3 as collateral, enabling the attacker to borrow more than USD 200 million worth of WETH and ETH. This maneuver effectively transferred the bad debt risk to the entire DeFi ecosystem.

Key Takeaways and Mitigations

Regarding the protocol setup, Kelp DAO has stated that the single-verifier configuration was the default setting provided during their onboarding process with LayerZero, rather than a deliberate choice to bypass security best practices. The Kelp team emphasized that they had utilized this configuration since 2024 and maintained consistent communication with LayerZero, perceiving the setup as a standard default. As of now, the responsibility for this specific configuration remains a point of contention between the two organizations.

The Lazarus Group's operation highlights that even robust protocols are vulnerable when configured with single points of failure. It is critical to note that Kelp DAO's initial decision to deploy with a 1-of-1 verifier configuration created an unnecessary security vacuum. To mitigate such risks, application-layer protocols must move beyond the convenience of these early-stage setups and enforce mandatory multi-verifier quorums from day one. By requiring independent confirmations from diverse DVN providers, the industry can ensure that the compromise of a single infrastructure cluster no longer results in a total loss of assets.

Furthermore, this incident exposes the urgent need for asymmetric monitoring to counter selective RPC deception. Security teams must adopt zero-trust models that cross-reference data from randomized, rotating sources to detect inconsistencies in RPC reporting. Ultimately, transitioning toward light-client and zero-knowledge proofs is essential to verify state transitions independently of RPC trust assumptions, building the necessary resilience against coordinated nation-state cyberattacks.