The Smart Contracts Worked Perfectly — Anatomy of the "RPC Poisoning" Attack That Drained $292M from KelpDAO

## Chapter 1: Foundations — What Is an "RPC"? ### RPC Is the Blockchain's Service Window An RPC (Remote Procedure Call) node is the server through which external software reads from and writes to a blockchain. By analogy, if the blockchain ledger is a library's collection, the RPC is the librarian. Users — DApps, wallets, bridges, verification networks — ask the librarian: "What is this address's balance? Has this transaction been finalized?" The librarian retrieves the answer from the stacks (the node) and replies. The structural reality is critical: users have no choice but to trust the librarian. Running one's own full node would allow direct verification, but cost and throughput drive most services to depend on external RPCs. ### LayerZero DVN's Relationship to RPCs A DVN (Decentralized Verifier Network) validates the authenticity of cross-chain messages on LayerZero. When a message arrives stating "100 ETH was burned on Chain A," the DVN must look at Chain A to confirm. The "looking" is performed via RPC. KelpDAO's rsETH bridge ran a 1/1 DVN configuration: a single verifier — the LayerZero Labs DVN — which itself queried multiple RPC nodes (a mix of internal and external). ## Chapter 2: The Four-Step Attack Chain ### [Step 1] Acquiring the RPC List (Reconnaissance) The attackers first obtained the list of RPC nodes used by the LayerZero Labs DVN. LayerZero's post-mortem states the attackers "gained access to the list of RPCs." The exact vector is not disclosed, but social engineering, an insider source, or configuration-file leakage are all plausible. Lazarus Group's TraderTraitor has historically used LinkedIn-based fake-job lures targeting developers with malware, and a similar approach is highly likely here. ### [Step 2] Compromising Two Internal Nodes — Binary Swap From the RPC list, attackers compromised two internal RPC nodes running on independent clusters. They swapped the op-geth (Optimism-derived Ethereum execution client) binary itself with a malicious version. This is not source-code tampering — it is replacing the running executable on the server. Once restarted, the node looks normal but has acquired the capability to lie. LayerZero's least-privilege architecture prevented penetration of the DVN instances themselves, but the attackers had succeeded in controlling the read-information source. ### [Step 3] Selective Lying — Evading Detection This is the most ingenious element. The poisoned RPC nodes did not lie to everyone. They executed a custom payload that returned forged data only to the LayerZero Labs DVN, while serving accurate responses to all other IP addresses — external monitoring services, Scan tools, other applications. Specifically, the poisoned nodes returned forged information ("rsETH was burned") only to queries originating from the LayerZero Labs DVN, while returning accurate information to LayerZero's Scan monitoring service and to all other external IP addresses. In other words, the nodes implemented an asymmetric structure: lying only to the attack target (the DVN) while delivering truthful responses to monitoring infrastructure and third parties — making detection extraordinarily difficult. This selective deception ensured external monitoring dashboards detected zero anomalies — exactly why Chainalysis observed that "every on-chain transaction looked completely valid." ### [Step 4] DDoS-Induced Failover Compromising two internal nodes alone was insufficient. The LayerZero DVN also referenced external RPCs as redundancy. The attackers launched distributed denial-of-service (DDoS) attacks against the uncompromised external RPCs. As external RPCs became unresponsive, the DVN's failover logic forced it to rely solely on the poisoned internal RPCs. LayerZero's published traffic charts show abnormal external-RPC traffic and internal-side response failures during the attack window of 10:20–11:40 PT. The DVN accepted the forged "rsETH was burned on the source chain" message as truth and instructed the Ethereum-side contract to release 116,500 rsETH. Despite no burn ever having occurred upstream, approximately $292 million flowed to attacker-controlled addresses. ## Chapter 3: Why Traditional Security Could Not Detect This ### Three Reasons the Attack Was Effectively Invisible First, the smart-contract code executed flawlessly. No reentrancy, no access-control gap, no oracle manipulation. The contract simply processed a legitimate-looking message from the DVN exactly as designed. Second, on-chain transactions all appeared consistent. The Ethereum-side transactions had correct signatures, formats, and authorizations — block-explorer surveillance would detect nothing. Third, no system continuously verified the cross-chain invariant: tokens released on the destination chain must equal tokens burned on the source chain. As Chainalysis noted, detecting this requires real-time reconciliation of token flows across chains — a capability with no industry-standard solution. ### "1/1 DVN" Brought Attack Success to 100% Had KelpDAO used a 3/5 DVN configuration (3 of 5 DVNs must agree), even with the LayerZero Labs DVN compromised, other independent DVNs would have detected the mismatch and rejected the message. Kelp's actual 1/1 configuration was itself a single point of failure that allowed the attack to succeed; under the industry-recommended 3/5 setup, the four remaining DVNs would have detected the inconsistency and rejected the forged message, and this attack would not have succeeded. Post-incident, LayerZero declared it will no longer sign messages for any application using a 1/1 DVN configuration. Kelp counters that "1/1 was LayerZero's default and was explicitly affirmed during the L2 expansion." Per CoinDesk, 40% of LayerZero protocols still run identical 1/1 setups. ## Chapter 4: Damage Propagation and Containment Within minutes, KelpDAO detected the anomaly and paused rsETH contracts on Ethereum and L2 deployments. Blacklisting attacker addresses blocked a follow-up attempt targeting an additional 40,000 rsETH (approximately $95 million). The Arbitrum Security Council froze approximately $75 million in downstream attacker funds three days later. However, immediately after Step 4, the attackers had deposited approximately $249.7 million of stolen rsETH into Aave and other lending markets and withdrawn approximately $228.2 million in wETH and wstETH. rsETH became frozen, but the withdrawn assets effectively crystallized as bad debt, forcing Aave to publish bad-debt scenarios reaching as high as $230.1 million. Organizing the timeline: at 17:35 UTC on April 18, 116,500 rsETH (~$292M) was drained from the Kelp DAO bridge. Immediately afterward, $249.7M was deposited as collateral into Aave and other lending markets while $228.2M was withdrawn. Within minutes, Kelp blocked the follow-up attack (40,000 rsETH / ~$95M). Within 48 hours, total DeFi TVL had shed approximately $13 billion. On April 21, the Arbitrum Security Council froze approximately $75 million in downstream funds. On April 23, Aave published bad-debt scenarios reaching up to $230.1 million. ### [Business Development Insights] 1. Obtaining the list of RPC nodes used by the LayerZero Labs DVN 2. Compromising two internal RPC nodes running on independent clusters 3. 3. $1,000,000 in losses incurred due to inadequate security measures Sources: LayerZero, *KelpDAO Incident Statement* (April 20, 2026); Chainalysis, *Inside the KelpDAO Bridge Exploit* (April 23, 2026); CoinDesk, *LayerZero blames Kelp's setup* and *Kelp DAO claims LayerZero's default settings* (April 20, 2026); The Block, *Kelp DAO shifts blame to LayerZero* (April 21, 2026); SecurityWeek, *$290 Million Kelp DAO Crypto Heist Blamed on North Korea* (April 21, 2026); DEXTools News; Sherwood News; CryptoTimes (April 20, 2026); CoinPost (April 22, 2026).