Kelp Dao Incident Analysis

Kelp DAO Incident Analysis

Posted
Kabuto Okajima Diaz Zazueta9 min read

Updated: 2026-05-02, 2026-05-05

Background#

What is Unichain?#

Unichain is a DeFi-focused Ethereum L2 by Uniswap, designed for faster, lower-cost onchain liquidity across chains.

https://l2beat.com/scaling/summary (As of Apr 29)

What is LayerZero?#

LayerZero is a cross-chain messaging protocol that allows applications to send messages and move assets across blockchains.

In this incident, LayerZero was the messaging layer used by the rsETH bridge path between Unichain and Ethereum.

Incident Summary#

TraderTraitor, a DPRK-linked threat actor also tracked as Lazarus Group/APT38, exploited the rsETH bridge path and caused 116,500 rsETH to be released, with approximately $175M of ETH-side proceeds later moved through cashout and laundering routes.

https://etherscan.io/tx/0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222

The _guid in the transaction input is 0x3f4510d855cf3a805fec59daafae640d290749b7bf1e5450f91b5fb0018b3b4e; searching this value on LayerZero Scan links the Ethereum execution to its LayerZero message.

The transaction with 0x3f45...3b4e as its GUID: https://layerzeroscan.com/tx/0x28fa5d1cc4ebcd87e8a15336636841e93d94bb9b9f4e5f76469c07ee49d4e4ea

On LayerZero Scan, the message is currently displayed as 0.001 rsETH was transferred to 0x000...00000 (burned), and 116,500 rsETH was released to the exploiter's address 0x8B1b6c9A6DB1304000412dd21Ae6A70a82d60D3b.

At execution time, there was no corresponding attacker-controlled source transaction.
Unichain was still at outbound nonce 307, but Ethereum had already accepted nonce 308.
Therefore, the current LayerZero Scan linkage should not be interpreted as proof of an attacker-controlled source tx.

Arkham later reported that approximately $175M of the stolen assets were laundered through new addresses and cross-chain swap routes.

Legit Request Flow#

  1. User calls bridge/send request on Unichain

    • RSETH_OFT.send(...) is called on the Unichain RSETH_OFT contract.
      • RSETH_OFT.send(...) internally burns the user's rsETH on Unichain.
      • It then calls _lzSend(...), which calls the Unichain LayerZero Endpoint.
    • The LayerZero Endpoint emits PacketSent event.
      • PacketSent(encodedPacket, _params.options, _sendLibrary);
    • The selected Send Library assigns jobs to the configured DVN(s) and Executor and emits DVNFeePaid and ExecutorFeePaid.
      • DVNFeePaid(config.requiredDVNs, config.optionalDVNs, dvnFees);
      • *DVN: Decentralized Verification Network

  2. DVN observes Unichain via RPC

    • The DVN read from multiple RPC paths, including two LayerZero-hosted internal (LayerZero-hosted) RPC nodes and at least one external third-party RPC path.
    • In LayerZero Labs’ public Gasolina AWS reference configuration, the RPC provider quorum is set to 1 for several major mainnet chains. This suggests that, under this configuration, the RPC-layer quorum can be satisfied by a single provider response rather than requiring multi-provider consensus. source
    • The RPC nodes watch PacketSent and DVNFeePaid emit events 
      PacketSent(
    bytes encodedPacket,
    bytes options,
    address sendLibrary
)
 
struct Packet {
    uint64 nonce;
    uint32 srcEid;
    address sender;
    uint32 dstEid;
    bytes32 receiver;
    bytes32 guid;
    bytes message;
}

  3. DVN verifies the packet

    • supports required/optional DVN threshold configurations at the OApp level.
      • In this incident, Kelp's Unichain → Ethereum path was 1-of-1 at the OApp/DVN config level: only the LayerZero Labs DVN was required.
    • reads PacketSent, decodes encodedPacket to derive the packet header and payloadHash.
      • However, this payloadHash only reflects the packet observed by the DVN; it does not independently prove that the packet existed on canonical Unichain.
    • check DVNFeePaid to confirm that its own DVN address was assigned to verify this packet.
    • wait for 42 confirmations (42 seconds)

https://docs.layerzero.network/v2/developers/evm/protocol-contracts-overview#dvn-verification

  1. DVN submits its witness on Ethereum

  2. Executor (any account) calls commitVerification(...) on Ethereum

  3. Executor (any account) calls EndpointV2.lzReceive(...)

  4. Recipient receives rsETH

Unable to render diagram.

Exploit and Monetization Flow#

  1. The attacker obtained the list of RPC nodes used by the LayerZero Labs DVN.

  2. The attacker compromised internal RPC nodes and replaced their binaries.

    • The poisoned RPC nodes returned a forged Unichain view to the DVN, including a non-existent PacketSent for 116,500 rsETH to the attacker-controlled address.

  3. The attacker DDoSed the uncompromised external RPC nodes, forcing failover to the poisoned RPC nodes.

    DDoS of external RPC. Attack took place between 10:20a and 11:40a PT, https://x.com/LayerZero_Core/status/2046081551574983137

    Internal attempt to reach external RPC during the time of the attack, https://x.com/LayerZero_Core/status/2046081551574983137

  4. The remaining LayerZero flow executed normally, releasing rsETH to the attacker.

According to the Aave report, the attacker deposited 89,567 rsETH (221.39M)ascollateralonAaveandborrowed82,650WETH(221.39M) as collateral on Aave and borrowed 82,650 WETH (190.86M) and 821 wstETH ($2.33M).

The Galaxy Research report traced the subsequent cashout.

"The borrowed assets were swapped to ETH and are now consolidated in the exploiter’s wallet, with 75,700 ETH on Ethereum and 30,765 ETH on Arbitrum."

The Arbitrum official announcement states that 30,765 ETH on Arbitrum was frozen. By contrast, the Ethereum-side funds were not frozen and were later moved through multiple laundering routes.

In total, approximately $175M of the stolen assets was monetized.

Incident Response#

The attacker also attempted a second delivery of 40,000 rsETH to the same attacker-controlled address. The following lzReceive(...) input data is visible on Etherscan: 0x0000000000000000000000008b1b6c9a6db1304000412dd21ae6a70a82d60d3b00000009502f9000

This can be split into: recipient: 0x0000000000000000000000008b1b6c9a6db1304000412dd21ae6a70a82d60d3b amount: 00000009502f9000

python3 -c 'print(int("00000009502f9000", 16))'
40000000000

However, the attempt failed because Kelp had paused rsETH contracts across mainnet and several L2s and blacklisted the attacker’s addresses.

The two attempts were only 51 minutes apart.

  • The first forged TX: Apr-18-2026 05:35:35 PM +UTC
  • The second forged TX: Apr-18-2026 06:26:35 PM +UTC

Root Cause#

The incident was not caused by a bug in the Kelp rsETH contract or the Ethereum-side RSETH_OFTAdapter.

The failure was in the LayerZero Labs DVN’s source-chain observation layer.

  • Kelp’s Unichain → Ethereum path used a 1-of-1 DVN configuration: the LayerZero Labs DVN.
    • This made the DVN a single point of failure in the OApp configuration.

https://layerzeroscan.com/tx/0x28fa5d1cc4ebcd87e8a15336636841e93d94bb9b9f4e5f76469c07ee49d4e4ea

  • The DVN relied on RPC infrastructure to observe Unichain.
    • The attacker compromised LayerZero-hosted RPC nodes and used DDoS to force failover toward poisoned RPC nodes.
    • The poisoned RPC view presented a non-existent PacketSent / rsETH burn as valid.
    • The DVN accepted the forged observation and submitted a verification witness on Ethereum.
  • The Ethereum-side contracts verified the DVN witness, but neither the contracts nor the DVN witness independently proved canonical Unichain inclusion.

A multi-DVN configuration could reduce this failure mode, but only if the DVNs use independent source-chain observation infrastructure. If multiple DVNs share the same vulnerable RPC or failover path, the same class of attack can still apply.

Takeaways#

What Does "Verification" Mean?#

"DVNs are independent entities that validate the authenticity and integrity of messages sent across blockchains within the LayerZero ecosystem."

https://docs.layerzero.network/v2/workers/off-chain/dvn-overview

However, in Kelp’s configuration, the DVN did not independently prove that the observed packet was included on canonical Unichain.

  • A payloadHash reconstructed from the observed PacketSent only proves consistency with the packet observed by the DVN.
    • It does not prove that the observed PacketSent existed on canonical Unichain.
    • Meaningful verification should require checking the payloadHash against an independently observed source-chain view.

DDoS as an Observation-Layer Integrity Attack#

DDoS was not merely used to take RPC infrastructure offline; it was used to shape what the DVN could observe.

  • Uncompromised RPC paths were degraded.
  • Failover routed the DVN to poisoned RPC nodes.
  • The DVN accepted the forged source-chain view as valid. In this context, DDoS became an observation-layer integrity risk, not just an availability issue.

Defense should therefore move beyond RPC uptime and focus on:

  • independent source-chain views
  • fail-closed failover when independent RPC paths are unavailable or disagree
  • multi-DVN configurations with independent infrastructure
  • detection across DDoS, RPC divergence, nonce anomalies, and bridge accounting invariants

Post-Incident Development#

Aave Liquidity Shock and Ecosystem Support#

The incident triggered a sharp liquidity shock on Aave, with reports citing over 10Binwithdrawals;inresponse,the[DeFiUnited](https://www.defi−united.com/)initiativecoordinatedmorethan10B in withdrawals; in response, the [DeFi United](https://www.defi-united.com/) initiative coordinated more than 300M in ecosystem support to help restore rsETH backing and stabilize affected markets.

Kelp’s Rebuttal and Disclosed Communications#

Kelp later published a public rebuttal to LayerZero’s post-mortem.

"This is a Telegram communication with a LayerZero Labs team member stating that they are not only aware of Kelp’s 1-1 DVN configuration but they also explicitly approved that setup."

"Communication from a LayerZero team member indicating LayerZero has a robust monitoring setup on their DVN."

"A conversation with the LayerZero team on TG, assuring that LayerZero Labs DVN was run with full monitoring and alerting. However, in our initial reachout to the LayerZero team after the hack, they seemed to be unaware of any issue with their systems."

Further Reading