
Inside The KelpDAO Bridge Exploit: How ~$292 Million In rsETH Was Released Against A Non-Existent Burn
A sophisticated infrastructure attack on KelpDAO's LayerZero bridge allowed North Korean-linked actors to drain $292 million in rsETH — without exploiting a single line of smart contract code.
On April 18, 2026, roughly $292 million worth of rsETH — 116,500 tokens — was drained from KelpDAO's LayerZero bridge. The attackers were later attributed to North Korea's Lazarus Group, specifically the TraderTraitor sub-unit. But unlike most major DeFi exploits, this was not a smart contract vulnerability. No reentrancy bug. No missing access check. No oracle manipulation. Every on-chain transaction was technically valid. The attack happened one layer deeper — in the off-chain infrastructure that cross-chain bridges depend on to know what's true.
How the Attack Was Structured
KelpDAO used LayerZero's bridging infrastructure to move rsETH across chains. LayerZero's architecture requires every cross-chain message to be verified by one or more Decentralized Verifier Networks (DVNs) before the destination chain acts on it. KelpDAO's rsETH was configured with a single DVN: the one operated by LayerZero Labs themselves. No second verifier had to agree. This 1-of-1 setup was, at the time, the default configuration for new deployments — but it meant that whoever could deceive that one DVN could deceive the entire system.
The attackers targeted the RPC nodes the LayerZero Labs DVN used to read source-chain state. LayerZero's DVN read from both internal nodes (hosted by LayerZero) and external third-party nodes. The attackers hit both simultaneously. Two internal RPC nodes were compromised — the attackers identified which nodes the DVN was querying, gained access, and replaced the running software with modified versions. These poisoned nodes fed fabricated data to the DVN while continuing to return truthful responses to other systems, including LayerZero's own monitoring infrastructure. They were also engineered to self-destruct once the attack window closed, wiping binaries, logs, and configuration files behind them.
At the same time, a DDoS attack was launched against the external RPC nodes the DVN relied on. With the external path unreachable, the DVN failed over to the only nodes it could still reach — the two internal ones now under attacker control. From that moment, the DVN's entire view of the source chain was whatever the attackers wanted it to be.
The poisoned nodes reported that rsETH had been burned on the source chain (Unichain) when no such burn had occurred. The DVN, trusting only those nodes, confirmed the cross-chain message as valid. On that confirmation, the Ethereum-side contract did exactly what it was designed to do: released 116,500 rsETH to an attacker-controlled address. The protocol executed a correct transaction on top of a falsified view of reality.
Why Traditional Monitoring Missed It
At the transaction level, nothing about the exploit was anomalous. The validator signature was valid. The message format was valid. The release function executed as designed. A standard transaction-by-transaction audit — the kind most protocol monitoring is built around — would not have flagged a single call.
The failure was structural. Bridges are two-sided systems. Their correctness cannot be evaluated by looking at one chain in isolation. Every bridge operates on a simple accounting rule: assets released on the destination chain must equal assets burned or locked on the source chain. In this case, 116,500 rsETH entered circulation on Ethereum against a burn that never happened anywhere upstream. That is not a transaction-level problem. It is a system-state problem — an invariant violation — and detecting it requires monitoring at the relationship level, not the call level.
The same fundamental failure produced the Ronin, Nomad, and Multichain incidents, each through different mechanisms. The common thread is not the specific vulnerability. It is the broken invariant.
The Response
KelpDAO detected the anomaly shortly after the first drain began and paused the relevant contracts on Ethereum and its L2 deployments. That action blocked a follow-up attempt in which the attacker tried to drain an additional 40,000 rsETH — roughly $95 million — via a second forged phantom packet. The second theft never succeeded.
Three days after the hack, the Arbitrum Security Council executed an emergency action to freeze 30,766 ETH held at an address tied to the exploiter. The Council acted with input from law enforcement, moved the funds to an intermediary wallet without affecting any other Arbitrum users or chain state, and ensured those funds can only be moved by further action from Arbitrum governance. It does not make the bridge whole — the invariant break and the gap between released and burned supply remain a separate problem — but it materially reduces the attacker's realized proceeds and demonstrates what coordinated governance and fast law-enforcement action can achieve when mobilized within hours.
What This Changes
Three things stand out from this incident. First, quorum design is security design. A DVN that relies on one party is not a quorum — it is a single point of failure with extra steps. Multi-DVN configurations should be treated as a baseline requirement, not an optional upgrade. Second, invariant-based monitoring is not optional for bridge protocols. Watching individual transactions for suspicious patterns will not catch an attack in which every transaction is, by itself, valid. What catches it is continuously verifying that the accounting holds across both sides of the bridge — that every release has a matching burn. Third, the window to intervene is small but real. Bridges that combine invariant monitoring with a credible, fast-acting pause mechanism can stop an in-progress exploit before the attacker begins converting stolen assets. The difference between the $292 million first drain and the $95 million second attempt that was blocked shows exactly how much that pause capability is worth.
Smart contract audits remain necessary. They are not sufficient. Cross-chain systems inherit the security of their weakest off-chain dependency — and in the KelpDAO case, that dependency was a single set of RPC nodes operated by one party, with no independent check.