The $292M KelpDAO/LayerZero Hack and What It Means for RPC Security
Executive Summary
On April 18, 2026, an attacker drained 116,500 rsETH — approximately $292 million, or 18% of the token's circulating supply - from KelpDAO's LayerZero-powered cross-chain bridge. It is the largest DeFi exploit of 2026 to date.
The attack did not exploit a smart contract bug. It exploited the RPC infrastructure that LayerZero's Decentralized Verifier Network (DVN) relied on to verify cross-chain messages.
LayerZero has attributed the incident to North Korea's Lazarus Group, specifically the TraderTraitor subgroup. This case study outlines what happened, why existing defenses failed, and how the attack could have been caught by Smart Router.
Background
LayerZero is a cross-chain messaging protocol used by hundreds of applications to move assets and data between blockchains. KelpDAO is a liquid restaking protocol that issues rsETH, a receipt token for restaked ETH deployed across more than 20 networks via LayerZero's OFT standard.
Cross-chain messages in LayerZero are verified by a DVN - a set of independent verifiers that confirm a message originated on the source chain before it is executed on the destination chain. KelpDAO operated with a 1-of-1 DVN configuration, meaning a single verifier's approval was sufficient to release funds.
What Happened
RPC compromise. The attackers gained access to RPC nodes the DVN relied on, poisoning them to return forged transaction data while continuing to serve correct responses to other clients — so nothing looked wrong from the outside.
DDoS to force failover. The clean RPC nodes were DDoS'd, forcing the DVN to rely on the poisoned ones.
Single-point verification. KelpDAO's OFTAdapter was configured with a 1-of-1 DVN setup. With the DVN ingesting forged data, a fabricated message claiming to originate from Unichain was accepted as valid.
Drain and extraction. The OFTAdapter released 116,500 rsETH — effectively minted without backing. The attacker deposited it into Aave V3 and V4 as collateral and borrowed real WETH against it, leaving Aave with bad debt.
A second forged packet targeting 40,000 rsETH was blocked when KelpDAO's emergency multisig paused the protocol 46 minutes in.
Root Cause: The RPC Trust Assumption
The structural failure was not in any smart contract. It was in the assumption that the RPC nodes feeding the DVN could be trusted by default.
RPCs are a critical attack surface for crypto infrastructure and financial institutions.
Most teams treat them as reliable utilities. In reality, they are off-chain services running on infrastructure that can be compromised, DDoS'd, or swapped without anyone downstream noticing.
How This Could Have Been Caught
1. Quorum alone isn’t enough. LayerZero operated a quorum mechanism, but quorum could be satisfied entirely by internal nodes. Requiring both internal and external nodes to participate changes the threat model: an attacker must now compromise internal infrastructure and independent third-party infrastructure simultaneously.
2. Cryptographic verification. The DVN did not verify the transaction on-chain before approving it. Many RPC responses can be verified without trusting the node - L2 blocks against L1 signatures, L1 blocks against known validator sets.
How Magma Addresses This
We’ve been working with Fireblocks, Kraken, Hypernative, and GK8 by Galaxy on exactly this problem.
Smart Router cross-validates RPC data across multiple independent sources and flags inconsistencies before they reach downstream systems. A DVN or verification service running on Smart Router would spot the data conflict and not be able to approve it without further investigation. Same for if an external source was not available — a quorum would not be reached and an error would surface.
The Broader Pattern
The attack surface in modern DeFi is no longer primarily the smart contract code. It is the off-chain infrastructure, key management, and trust assumptions that smart contracts delegate to. KelpDAO's OFTAdapter passed its audit. LayerZero's contracts passed their audits.
The exploit required no on-chain vulnerability. Smart contract audits are not enough.
The Question for Every Blockchain Team
Not sure your RPC stack can withstand this kind of attack? Ask yourself:
Do you depend on a single source for RPC data?
Do you run your own RPC infrastructure?
Do you have a failover system — and do you know what it fails over to?
Do you cross-validate responses across independent sources?
Does your quorum require multiple independent sources to agree?
Do you use cryptographic proofs to verify on-chain transactions before approval?
If any of these are "no" or "not sure," reach out. Our team is happy to review and help secure your RPC stack.