BREAKING
KELP DAO $292M drained via forged LayerZero DVN messages — Lazarus Group 19 APR 2026
Research QuiverCrypto
LIVE Subscribe
POST-MORTEM · 22 MIN READ · Kelp DAO · Ethereum CRITICAL

Kelp DAO — $292M drained via forged LayerZero messages after RPC node compromise and coordinated DDoS

Lazarus Group compromised LayerZero's internal RPC nodes, orchestrated a simultaneous DDoS on third-party nodes, and exploited Kelp's single-verifier bridge configuration to release 116,500 rsETH against a burn that never happened.

QuiverCrypto Research 19 April 2026
$292,000,000 $71,000,000 recovered (24%)

On April 18, 2026, attackers linked to North Korea’s Lazarus Group (TraderTraitor sub-group) exploited Kelp DAO’s LayerZero-powered rsETH bridge to release 116,500 rsETH — approximately $292 million — against a token burn that never took place on the source chain. The attack did not target a smart contract vulnerability. It was a precision strike on off-chain verification infrastructure, amplified by a misconfiguration that left Kelp relying on a single point of truth.

It is now the largest DeFi exploit of 2026.

Background: Kelp DAO and rsETH

Kelp DAO is a liquid restaking protocol built on EigenLayer. Users deposit ETH or LSTs (Liquid Staking Tokens) and receive rsETH in return — a liquid representation of their restaked position. The protocol deployed a LayerZero-powered bridge to allow rsETH to move freely across 20+ chains, minting and burning tokens as they travel.

The bridge’s security model relies entirely on LayerZero’s Decentralized Verifier Network (DVN): a set of independent nodes responsible for validating cross-chain messages before any tokens are released on the destination chain.

The DVN configuration flaw

LayerZero’s architecture allows protocol integrators to define their own verifier configuration. The safest setup is M-of-N: multiple independent DVN operators must agree before a message is deemed valid.

Kelp deployed with a 1-of-1 DVN setup — LayerZero Labs was the sole verifier. No independent parties. No consensus requirement. If LayerZero’s DVN could be convinced something was true, the bridge would act on it unconditionally.

LayerZero’s integration checklist, shared directly with Kelp’s team, explicitly recommended multi-verifier redundancy. The recommendation was not implemented.

“If the LayerZero Labs DVN could be made to believe something false, there was no independent party to catch the mistake.” — Chainalysis post-mortem

Attack timeline

Time (UTC)Event
10:20DDoS launched against third-party RPC nodes supplying data to the LayerZero DVN
10:20–11:40Third-party nodes become unreachable. DVN failover triggered — switches to LayerZero Labs internal nodes
Pre-attackAttackers had already replaced software on two internal LayerZero RPC nodes with a malicious variant
~18:05Compromised internal nodes attest a phantom rsETH burn on Unichain (source chain)
~18:05Bridge releases 116,500 rsETH to attacker-controlled address on Ethereum
18:21Kelp emergency multisig freezes core contracts — 46 minutes after the drain
18:26Second drain attempt (~40,000 rsETH, ~$95M) — reverted due to freeze
18:28Third drain attempt — reverted
April 20Arbitrum Security Council freezes 30,766 ETH (~$71M) from attacker-controlled addresses
April 20LayerZero publishes incident statement, attributes attack to Lazarus Group
April 20Kelp publishes rebuttal, blames LayerZero default configuration

Technical breakdown

Step 1 — Compromising the internal RPC nodes

The attackers did not exploit a known CVE or publicly-disclosed software vulnerability. They gained access to two RPC nodes operated by LayerZero Labs and replaced the node software with a custom malicious version. The replacement was designed to:

  • Return normal, truthful responses to all monitoring and health-check systems
  • Forge verification data — specifically, fabricating attestations of token burn events that never occurred on the source chain

This is a supply-side attack on the verification layer: the nodes looked healthy, but their outputs were adversarial.

Step 2 — DDoS to monopolize the DVN’s data feed

LayerZero’s DVN aggregates data from multiple RPC node operators. Under normal conditions, the malicious internal nodes would have been overruled by honest third-party nodes. The DDoS solved this:

10:20 UTC  →  DDoS launched on all third-party RPC providers
             Third-party nodes go offline / become unreachable
             DVN failover: switches exclusively to LayerZero Labs internal nodes
             DVN data feed now 100% controlled by attacker

With no independent nodes online, the DVN had no way to cross-check the forged attestation.

Step 3 — The phantom burn

The core invariant of any lock-and-mint bridge is:

tokens burned on chain A  ==  tokens released on chain B

The compromised DVN nodes submitted an attestation claiming:

“116,500 rsETH have been burned on Unichain — release them on Ethereum.”

No such burn occurred. The source chain supply was untouched. The bridge, trusting its sole verifier, released 116,500 rsETH onto Ethereum regardless.

The result: rsETH total supply increased by 116,500 tokens with zero backing. The bridge’s fundamental invariant was broken. These tokens were immediately swapped for other assets through DEX aggregators and bridged across chains.

Step 4 — Evidence destruction

After the successful drain, the malicious node software self-destructed — deleting its own binaries and local logs. This significantly complicated forensic analysis in the hours following the attack.

Step 5 — Kelp’s emergency response

Kelp’s emergency pause multisig detected anomalous bridge activity and froze the protocol’s core contracts at 18:21 UTC, 46 minutes after the primary drain. Two follow-up drain attempts for ~$95M total were blocked by the pause.

On April 20, the Arbitrum Security Council — a 12-of-15 multisig with emergency powers over the Arbitrum network — voted to freeze 30,766 ETH (~$71M) linked to the attacker. This represents approximately 24% recovery of stolen funds.

The blame game: Kelp vs. LayerZero

The incident exposed a fundamental tension in permissionless bridge infrastructure:

LayerZero’s position: Kelp was explicitly warned. The integration checklist, DVN documentation, and direct communications all recommended multi-verifier setups. Kelp chose to run 1-of-1. The responsibility is theirs.

Kelp’s position: LayerZero’s default deployment templates and documentation implicitly promote single-source verification on major chains. The risk was not sufficiently surfaced. A protocol integration checklist is not the same as enforced security requirements.

Independent researchers: Both parties share responsibility. LayerZero’s defaults normalize a dangerous configuration. Kelp failed to conduct adequate threat modeling for its bridge’s trust assumptions.

The broader lesson is architectural: the security of a cross-chain bridge should never depend on the integrity of a single operator, regardless of how trusted that operator appears.

Impact and blast radius

MetricValue
rsETH drained116,500 (~18% of circulating supply)
USD value at time of attack~$292M
Chains affected20+ (rsETH stranded cross-chain)
Funds frozen (Arbitrum SC)~$71M (24%)
Secondary drain attempts blocked2 (totaling ~$95M)
Protocol statusPaused indefinitely as of writing

What would have stopped this

  1. Multi-verifier DVN (M-of-N): Even with two internal nodes compromised, an honest third-party verifier would have rejected the phantom burn attestation. The attack only works if the DVN is monopolized.

  2. Rate limits on bridge releases: A circuit breaker limiting the volume releasable in a short window would have capped the blast radius.

  3. Timelock on large releases: Any release above a threshold (e.g., $10M) should require a waiting period before settlement.

  4. Independent monitoring: Real-time comparison of rsETH supply across all chains would have flagged the invariant violation within seconds.

  5. Segregated RPC infrastructure: LayerZero Labs should not operate its own RPC nodes within the DVN it controls. This creates an inherent conflict of interest and a single point of failure.

Sources