RPC poisoning: How the Kelp DAO $290M exploit happened

In April 2026, Kelp DAO experienced an exploit, due to an RPC attack, that resulted in the loss of 116.5k rsETH (worth $290 million at the time). 

rsETH is a liquid-staking token pegged 1:1 to Ethereum and deployed across more than 20 networks, including Base, Arbitrum, Linea, Mantle, and Scroll. Crypto holders can deposit ETH to Kelp DAO smart contracts across 20+ chains and then receive an equivalent amount of rsETH.

Unlike commonly perceived attacks, the exploit was not due to a vulnerability in Kelp DAO or other protocol smart contracts. Instead, it was a direct attack on the infrastructure that orchestrated cross-chain rsETH transactions.

Kelp DAO used LayerZero, a cross-chain messaging protocol, to manage rsETH across several chains. Attackers exploited this system by “poisoning” and manipulating the RPC API responses LayerZero relied on for deposit verification, leading the APIs to provide data suggesting the attacker had 116.5k rsETH on Unichain. The attacker requested a transfer of 116.5k rsETH from Unichain to Ethereum. Since the system trusted this manipulated data, it mistakenly believed the attacker had sufficient rsETH to proceed, causing Kelp DAO to transfer rsETH to the attacker’s Ethereum wallet.

The exploit exposed multiple risks that are not commonly discussed in the web3 space, including RPC “poisoning.” 

RPC attacks are an underappreciated but growing attack vector in Web3. As DeFi protocols increasingly rely on cross-chain infrastructure, the security of RPC nodes — the communication layer between applications and blockchains — has become a critical but often overlooked concern. This article explains crypto RPC attacks, how they work, including examples, and how to prevent them.

The Kelp DAO rsETH attack

On April 18, 2026, Kelp DAO, a major Ethereum liquid restaking protocol, was drained of 116,500 rsETH, valued at around $290 million at that time, in a single transaction exploiting the bridge infrastructure.

The attacker, preliminarily attributed to the Lazarus Group based in North Korea, targeted the LayerZero Decentralized Verifier Network (DVN), which verified cross-chain messages for Kelp DAO rsETH. They compromised two of the RPC nodes the DVN relied on, leading them to return data suggesting the attacker had 116.5k rsETH on Unichain, when it did not. It also made denial-of-service attacks on the other nodes offline to ensure that no other nodes could reference the actual blockchain state that the attack did not have rsETH.

After the attack, the attacker distributed the funds across several wallets, deposited all rsETH into Aave V3 as collateral, and borrowed ETH at roughly 99% effective Loan-to-Value. They chose this route because there was insufficient DEX liquidity to swap 116,500 rsETH for ETH without the price collapsing, and redeeming rsETH directly through Kelp DAO’s smart contracts was no longer an option once the team froze the protocol. Borrowing against rsETH allowed the attacker to obtain real ETH while leaving unpegged rsETH as collateral on Aave. 

As a result, Aave is left holding bad debt worth 116,500 ETH.

What is an RPC? How are RPCs used in crypto?

Remote Procedure Call is a widely used, lightweight communication protocol that allows a program (client) to communicate with a remote program (server).

In blockchain, specifically, an RPC node is a server that connects to a blockchain, listens for blockchain activity, and serves requests so that software applications can query blockchain data and submit new transactions.

An RPC URL is the network endpoint or API URL for this interface, so software applications know where to send requests. Here’s a format example of an RPC URL for accessing the node that I deployed on Chainstack Console:

https://ethereum-mainnet.core.chainstack.com/xxxxxxx-xxxxxx-xxxxx

Kelp DAO used LayerZero, a cross-chain protocol, to monitor ETH deposits, verify them, and send a signed attestation before Kelp DAO smart contracts trigger a release of rsETH. In turn, LayerZero uses RPCs to listen for message requests sent to its smart contracts and to send messages across various blockchains.

In the case of the Kelp DAO rsETH attack, attackers identified the list of RPCs LayerZero was using and attempted to “poison” them.

Generally, an RPC provider list isn’t considered sensitive information. Knowing the RPC providers used is not enough to attack them, but in this case, there were vulnerabilities in the RPCs that LayerZero relied on that led to the exploits.

In the upcoming sections, we’ll discuss how to better secure RPCs and protect against RPC attacks, rather than merely “hiding” a list of RPC providers you use.

What is an RPC Attack?

Many applications treat RPC responses as the “truth” to blockchain data. An RPC attack targets this trust assumption and interferes with the data returned by the RPC that applications rely on.

RPC Poisoning 

Attackers proceeded to “poison” the RPCs that LayerZero relied on, and ultimately used to manage rsETH. 

RPC poisoning involves alternating the data returned by an RPC endpoint so that applications read an incorrect view of the blockchain state.

The attackers were able to access two independent, unconnected nodes and swap out the binaries, effectively running a different version of the blockchain than the current state, one where the attacker had 116.5k rsETH on Unichain. 

Rate-limiting and denial-of-service (DDoS) attacks 

Rather than returning false data, an attacker can overwhelm an RPC endpoint, rendering it unavailable. For applications that rely on a single RPC, downtime can stall transaction processing, block liquidations, or create time-sensitive failures that attackers exploit through other means. 

In the Kelp DAO attack, the attackers DDoSed the fallback (backup) RPCs, leaving the two poisoned nodes as the only source of truth.

Other types of RPC attacks

Malicious or compromised RPC endpoints

Attackers can control the RPC itself, for example, by redirecting users to an endpoint that mimics the real service.

Front-running and transaction censorship by RPC operators

A compromised or malicious RPC provider can review submitted transactions and act on them before they reach the mempool. This allows for front-running, censorship, or sharing transaction data with third parties capable of front-running. 

Such attacks are especially harmful for MEV-sensitive transactions like DEX swaps, liquidations, and arbitrage, as the RPC operator gains visibility of the transaction earlier than the public mempool.

Man-in-the-middle (MITM) attacks on RPC connections

Even when the RPC endpoint itself is legitimate, an attacker positioned between the application and the RPC can intercept and modify responses in transit. RPC connections made over plain HTTP rather than HTTPS are especially exposed to this attack vector, because the traffic is not encrypted and can be rewritten before it reaches the application.

How to Prevent RPC Attacks

Not every RPC attack is fully preventable, but several methods can help mitigate them.

Some suggested that the Kelp DAO’s LayerZero setup could have had more redundancy, though LayerZero has not made it clear if it would have.

KelpDAO used LayerZero’s Decentralized Verifier Network (DVN) set to the default option that uses a single validator to verify messages. A single validator that uses false RPC data is a clear point of failure. Using multiple validators could reduce this risk if they rely on independent RPC sources, since conflicting data would expose inconsistencies. However, it does not seem that different DVNs use distinct RPCs, so the failure points remain.

Despite this limitation, many are advocating for teams using DVN to use more than one validator to validate cross-chain messages.

A Dune analysis showed that 47% of OApp contracts (those that serve as the basis for using LayerZero DVN) use one-validator DVNs, 45% use two, and 5% use three or more.

Use multiple RPC providers

Using multiple RPC providers, ideally from different operators running on different infrastructure, reduces the likelihood that a single compromise can corrupt the data an application sees.

Chainstack operates its own managed infrastructure and gives you distinct types:

• A Global Node is a highly scalable public network node infrastructure accessed through your exclusive endpoint. With an elastic node, you pay for JSON-RPC requests to the node and do not pay for the compute and storage resources used by the node.
• A Dedicated Node is a public network node deployed exclusively for you. With a dedicated node, you pay for the compute and storage resources it uses, but not for JSON-RPC requests to it.
• A Self-Hosted Node lets you run the node in your own environment while still using Chainstack’s control plane to deploy, manage, and monitor it.

Quorum agreement across RPCs

Quorum agreement is the practice of querying multiple RPCs for the same data, such as a wallet balance or a transaction receipt, and proceeding only when a majority of providers return matching results. In practice, this means querying at least three independent providers and requiring two of three to agree before proceeding. If one provider returns a conflicting result, the application should either halt and alert or fall back to manual verification. This approach would have directly mitigated the Kelp DAO attack: even with two poisoned nodes, a third clean node would have exposed the discrepancy.

Access Control

Applying access controls, such as authentication tokens, IP allowlists, and network-level restrictions, limits who can query the RPC and, more importantly, who can reach the underlying node for administrative purposes. 

In the KelpDAO exploit, the attacker swapped out the binaries running the op-geth nodes, indicating that the RPCs were reachable at a level that allowed binary replacement.

All nodes deployed on Chainstack include password-protected access endpoints. 

All nodes can be configured with additional access rules, including allowing traffic from only trusted HTTP Origin header values or specific IP addresses. Learn more about access rules.

💡 Also recommended: How to secure your RPC endpoints with access rules

Aftermath

The Ethereum community moved quickly to mitigate the risk of the exploit.

rsETH transactions were frozen across multiple exchanges and lending platforms, including on Aave. 

The Arbitrum Security Council approved a vote to freeze 30,766 ETH held in an attacker-controlled address on Arbitrum, which moved the funds to a frozen wallet that the attacker can no longer access pending further governance action.

Several foundations and teams are loaning or donating ETH to Aave to help cover the bad debt created when the attacker borrowed ETH against rsETH collateral that no longer holds its peg, including:

• Mantle (to loan Aave 30,000 ETH at LIDO +1% APR)
• Etherfi (5,000 ETH)
• Golem (1,000 ETH)
• Lido (2,500 stETH. stETH is a liquid staking token pegged 1:1 to Ethereum, issued by the Lido protocol in exchange for ETH that users stake through it)

Conclusion

The Kelp DAO exploit demonstrated that smart contracts are only as secure as the infrastructure they depend on. Although the smart contracts themselves were not vulnerable, the infrastructure used to verify cross-chain messages was exploited, resulting in a $290 million attack.

Preventing this type of attack requires removing the single points of failure at every layer of the trust chain. Using multiple RPC providers with quorum agreement across them, running multiple independent DVNs with distinct RPC sources, and applying strict access controls to RPC nodes are no longer optional engineering choices for protocols managing hundreds of millions in cross-chain TVL.

To add Chainstack as an additional RPC provider and strengthen redundancy in your infrastructure, go to Chainstack to get started.

FAQ

Related Reading

• How to secure your RPC endpoints with access rules on Chainstack 
• Chainstack Access Rules Demo
• 5 essential factors for setting up RPC node endpoints

Resources

• LayerZero Incident Statement on Kelp DAO
• Kelp DAO Incident Response Further Context
• QuillAudits Hack Analysis – Kelp DAO rsETH $292 Bridge Exploit Explained
• LayerZero OApp DVN Configuration – Dune Dashboard