KelpDAO rsETH $292M Bridge Exploit (Explained)

On April 18, 2026, KelpDAO, one of Ethereum's largest liquid restaking protocols with over $1.6B+ in TVL, was hit by a $292M exploit. This wasn't a smart contract vulnerability. The attacker compromised the downstream RPC infrastructure used by KelpDAO's single LayerZero DVN, forged a cross-chain message, and tricked the bridge into releasing 116,500 rsETH in a single transaction. It stands as the largest DeFi hack of 2026, surpassing the Drift Protocol exploit by a few million dollars.

What is a DVN and How Does KelpDAO's Architecture Work?

KelpDAO is a liquid restaking protocol where users deposit ETH, which gets routed through EigenLayer to earn additional yield. Users receive rsETH a tradeable token representing their restaked position deployed across 20+ chains via LayerZero's OFT (Omnichain Fungible Token) standard. The Ethereum OFTAdapter acts as the master escrow, locking native rsETH and backing all cross-chain versions.

A DVN, or Decentralized Verifier Network, is the security layer that validates cross-chain messages in LayerZero V2. When rsETH moves between chains, a DVN observes the transaction on the source chain, verifies it happened, and delivers a signed attestation to the destination chain before funds are released. Think of it as the referee that confirms a cross-chain instruction is real. LayerZero recommends running multiple independent DVNs in parallel so no single verifier can unilaterally authorize a transfer. KelpDAO ran just one.

Hack Analysis

This wasn't a smart contract bug, it was a bridge configuration failure combined with a state-sponsored infrastructure attack. KelpDAO's rsETH OFT Adapter on Ethereum was configured with a 1-of-1 DVN setup meaning LayerZero Labs was the sole entity responsible for verifying cross-chain messages.

The attacker, preliminarily attributed to North Korea's Lazarus Group (TraderTraitor) obtained the list of RPC nodes used by the LayerZero Labs DVN, compromised two of them by swapping out the op-geth binaries with malicious versions that served forged data exclusively to the DVN's IP addresses while appearing honest to every other observer, then DDoS'd the remaining clean nodes offline to force a full failover to the poisoned infrastructure, at which point they submitted a forged cross-chain message claiming to originate from KelpDAO's Unichain deployment, the DVN confirmed it against its fabricated view of on-chain state, the 2-of-3 multisig quorum passed, and the forged packet was certified as valid.

The fraud is provable on-chain. Unichain's outboundNonce was stuck at 307 nonce 308, the one the attacker claimed, never existed. No PacketSent event for nonce 308 was ever emitted. Unichain's rsETH totalSupply was only 49.26 rsETH at the time mathematically impossible to burn 116,500.

The attacker then invoked commitVerification() using the fabricated payload and its corresponding hash, which had already been verified by the DVN.

The attacker then invoked lzReceive() using the fabricated origin details, causing the rsETH OFTAdapter on Ethereum to release 116,500 rsETH to the primary attacker EOA.

With the rsETH in hand, the attacker distributed it to eight pre-staged cash-out EOAs. Each followed an identical sequence within approximately six minutes: deposit rsETH into Aave V3 as collateral, borrow ETH at ~99% effective LTV, and consolidate borrowed ETH to a central hub address. By T+27 minutes, the Ethereum hub held 75,700.76 ETH from five distinct cash-out EOAs alone.

At 18:21 UTC 46 minutes after the initial drain KelpDAO's emergency pauser multisig froze the protocol's core contracts. Two follow-up attempts were made at 18:26 UTC and 18:28 UTC, each carrying the same forged packet structure and targeting an additional 40,000 rsETH (~$100M). Both reverted. The emergency pause held.

Root Cause

The KelpDAO exploit was not caused by a bug in the protocol's smart contracts. It was an operational security failure rooted in a misconfigured bridge and a single point of trust.

KelpDAO's rsETH OFT Adapter was deployed with requiredDVNCount = 1 for the Unichain source path, with LayerZero Labs as the sole verifier. LayerZero's own integration checklist and direct communications to KelpDAO had explicitly recommended a multi-DVN setup with redundancy, where consensus across several independent verifiers would be required to confirm a message. Under that configuration, poisoning one verifier's infrastructure would not have been enough. KelpDAO chose to maintain the 1-of-1 setup.

The LayerZero Labs DVN itself was not directly broken its least-privilege access controls prevented the attacker from compromising the actual DVN instances. Instead, the attacker went one layer deeper, targeting the RPC infrastructure the DVN relied on to see on-chain state. By compromising two independent RPC nodes and DDoSing the clean ones into offline failover, the attacker created a false reality for the DVN to operate in one where nonce 308 existed and 116,500 rsETH had been burned on Unichain.

The DVN's 2-of-3 multisig signing quorum passed cleanly. The on-chain contract did exactly what it was programmed to do. The keys behind it were compromised. No code was broken. The off-chain verification layer was.

How QuillAudits OPSEC & Multisig Audit Could Have Prevented This

QuillAudits OPSEC and multisig audit process reviews bridge security configuration, verifier trust models, and off-chain infrastructure posture exactly the gaps that made this attack possible.

DVN configuration review. KelpDAO's 1-of-1 DVN setup was a single point of failure protecting over $1.6B+ in bridge reserves. An OPSEC audit would have flagged requiredDVNCount = 1 as a critical risk for any production OFT deployment holding material TVL, and recommended a minimum 2-of-3 multi-DVN configuration with independent verifiers before mainnet launch.

Bridge trust model assessment. A multisig audit would have examined not just the signing thresholds of the DVN contract itself, but the entire trust chain beneath it including the RPC infrastructure the DVN relied on to verify source chain state. Identifying that LayerZero Labs' DVN depended on a finite, enumerable set of RPC nodes would have surfaced the risk of RPC poisoning as an attack vector.

Verifier independence analysis. An OPSEC review would have evaluated whether the DVN's signing keys and RPC nodes represented truly independent failure domains. Two nodes on separate clusters sounds independent but both being in the same discoverable RPC list makes them a shared attack surface.

Timelock and emergency controls review. With $1.6B+ in bridge reserves, a multisig audit would have flagged the absence of any timelock or delay mechanism on bridge configuration changes, and recommended circuit breakers that could halt withdrawals within seconds of anomalous attestation patterns.

Attestation verification posture. An OPSEC audit would have recommended that the bridge validate DVN attestations against publicly verifiable source chain state cross-checking claimed nonces and burn events before releasing funds rather than accepting attestations purely at face value from a single verifier.

With a QuillAudits OPSEC and multisig audit in place, the 1-of-1 DVN configuration would never have reached production. The single verifier representing a $1.6B+ trust assumption would have been caught at the design review stage, long before an attacker could exploit it.

Review your OPSEC and Multisig Infra Now.

Funds Flow After Attack

The $292M drain was only Phase 1. Phase 2 weaponized DeFi composability itself. Because rsETH was whitelisted as collateral across multiple major lending protocols, the attacker could deposit worthless unbacked rsETH and borrow real ETH against it leaving lending protocols holding bad debt that cannot be liquidated through normal mechanisms.

At the time of writing, the stolen funds remain in the attacker’s EOA (0x5d3919F12bCc35c26Eee5F8226A9bee90c257Ccc), held in native ETH on both the Ethereum and Arbitrum networks.

Post Attack Mitigation

At T+46 min (18:21 UTC) emergency pauser multisig froze all rsETH contracts across mainnet and multiple L2s and at T+~3 hours (20:10 UTC), first public X post acknowledging the incident

LayerZero published a detailed incident report explaining that the $292M KelpDAO exploit was caused by an advanced RPC poisoning attack targeting its DVN infrastructure, likely by the Lazarus Group. The attack only impacted KelpDAO’s rsETH due to its insecure single-DVN setup, while the LayerZero protocol itself remained unaffected and no other assets were compromised.

Relevant Address and Transactions

Attacker EOAs

• (rsETH Receiver) 0x8b1b6c9a6db1304000412dd21ae6a70a82d60d3b
• 0x8d11aeac74267dd5c56d371bf4ae1afa174c2d49
• (Hold all hacked assets) 0x5d3919F12bCc35c26Eee5F8226A9bee90c257Ccc
• 0xcbb24a6b4dafaaa1a759a2f413ea0eb6ae1455cc
• 0xeba786c9517a4823a5cfd9c72e4e80bf8168129b
• 0xbb6a6006eb71205e977eceb19fcad1c8d631c787
• 0x1f4c1c2e610f089d6914c4448e6f21cb0db3adef
• (Attack Tx executor) 0x4966260619701a80637cDbdAc6A6cE0131f8575E

Attack Transaction

• Commit Verify 0x68eb14e2d0ea9eca0f6277b6e4242c898a08d83a9ffe322dd875e69112e3b564
• lzReceive 0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222

DVN

0x589dedbd617e0cbcb916a9223f4d1300c294236b

DVN Attestation Transaction

0xfe575668f895e10f8496fca3bb928fa53bebbea3e1de567d61bcd12d935f0d6f

DVN Admin

0xd95d7761a585bbc1b59b4b6f441b9edc2878dade

DVN Whitelisted Signers

0x7e1879A1Fba74d8107E2E3EE42f5fea5E6500f5B

0x5AB40527AA622960E26a171c58011de58DFA5bE9

rsETH Unichain

0xc3eACf0612346366Db554C991D7858716db09f58

rsETH Ethereum

0x85d456b2dff1fd8245387c0bfb64dfb700e98ef3

Conclusion

The KelpDAO exploit is a clear example of how bridge configuration failures can bypass even audited smart contracts. A 1-of-1 DVN setup, no independent verifier, and an off-chain RPC layer that became a single exploitable trust assumption gave the attacker everything they needed. No code was broken. The verification layer was. For protocols managing hundreds of millions in cross-chain TVL, multi-DVN configurations, rigorous OPSEC audits, and real-time bridge monitoring are no longer optional they are the last line of defense.