"KelpDAO Exploit Explained: RPC Trust in Cross Chain Apps"

Updated October 22, 2026 · Spectrum Nodes

Short answer: The KelpDAO exploit on 18 April 2026 broke no smart contract: it was a failure of RPC data verification. At 17:35 UTC, a cross chain message with no matching burn event on Unichain was accepted at Ethereum block 24,908,285, releasing about 116,500 rsETH. The attacker compromised some of the RPC nodes LayerZero's verifier read from and made the rest unavailable, so a single verifier attested to false chain state.

The KelpDAO exploit on 18 April 2026 has already been widely discussed, often as a bridge incident. That framing misses what went wrong. There was no failure in contract logic, no broken signature scheme and no evidence of compromised keys. The system behaved exactly as designed, but it acted on data that did not reflect the source chain's actual state.

That distinction changes how the incident should be read. The failure started in how the system determined what had happened onchain, before execution began. Once that assumption was wrong, everything after it followed from one bad input.

The KelpDAO hack was a problem of blockchain data verification. Contract correctness was never the issue. This article covers what went wrong, why monitoring tools did not flag it, how far the impact spread and what every team should learn from it.

Was the KelpDAO Exploit a Smart Contract Failure?

No. Every contract involved executed correctly, the message format remained valid and the verifier produced an attestation based on the data it received. From inside the system, everything behaved as expected.

Most early interpretations got this wrong. The issue was valid logic applied to invalid inputs, which is a different category of failure. It came from what the system assumed to be true before execution began.

What Happened in the KelpDAO Incident?

The system accepted a cross chain message that should not have existed, then released tokens on Ethereum with no matching event on the source chain.

In simple terms, tokens were created on Ethereum without a matching burn or lock event on the source chain.

The nonce gap makes the inconsistency clear. A nonce is a counter that goes up by one with each message, so each step reflects an actual event on the source chain. On the source chain the nonce stayed at 307, yet Ethereum accepted nonce 308 as if the previous step had already happened. That gap should not be possible. The system skipped a step and accepted a message with no underlying transaction.

The message was invalid, and the system had no way to recognise that, because it was working from data that did not reflect the actual state of the chain.

How Did the Attack Work at the Infrastructure Layer?

The attacker went after the RPC infrastructure that fed the verifier. The verifier in this case was LayerZero's DVN (Decentralised Verifier Network), the component that attests a cross chain message matches the source chain before it is executed. It relied on a mix of internally operated and external RPC endpoint providers to read source chain state, and that is where the attacker concentrated.

The attack ran in four steps:

1. Map the endpoints. The attack did not begin with contract interaction. It began by mapping the RPC endpoints the verifier used.
2. Compromise a subset of nodes. That let the attacker control what those nodes reported about the chain.
3. Disrupt the rest. The remaining nodes were made unavailable through targeted disruption, so the only reachable data sources were under the attacker's control.
4. Let the system carry on. The system did not pause or try to validate what it saw. It kept operating with whichever infrastructure was reachable, which meant nodes the attacker already controlled.

The attacker did not need to break the protocol or bypass cryptography. They only needed to influence what the system believed had happened onchain. As our CEO Isaac Zarb put it:

“The attacker didn’t break smart contracts or steal keys. They poisoned reality.”

Where Did the System Break?

Two design choices let the false data through: one verifier could approve a message alone, and RPC responses were treated as the truth.

Single Verifier Trust Model

The affected pathway relied on a 1-of-1 DVN configuration, which means a single verifier was enough to approve a message and trigger execution. There was no requirement for independent confirmation, and no mechanism to challenge the attestation once it had been produced.

LayerZero's own guidance makes this risk clear. Its integration checklist advises developers not to rely on single verifier setups in production.

A single verifier does not create a failure on its own. It removes the ability to detect one when it occurs.

RPC Treated as a Source of Truth

The most fundamental issue sat at the data layer. The verifier treated RPC responses as authoritative without validating them against other sources. There was no comparison between providers, no attempt to detect inconsistencies and therefore no rejection of conflicting data.

The system accepted whichever response was available and internally consistent. That assumption holds in normal conditions. It breaks when the infrastructure itself is part of the attack: once the RPC responses were influenced, the system lost its ability to tell the actual state from a fabricated one.

Why Didn't Redundancy Prevent the KelpDAO Exploit?

Redundancy didn't help because multiple endpoints were already in place. What was missing was any way to validate their responses against one another.

A common misconception is that adding more RPC providers would have avoided the exploit. It sounds reasonable, but it does not address what failed. Some nodes were compromised, others were made unavailable, and the system kept operating on the remaining sources without questioning their reliability.

As our CEO wrote on LinkedIn:

“We run nodes out of multiple locations with multiple redundancies: That solves availability, but the KelpDAO incident makes it clear that redundancy must be coupled with in‑code verification.”

Redundancy keeps a system running. It does not make sure the system is running on correct data. The KelpDAO exploit is a clear case of an RPC failure where availability masked a deeper problem at the data layer. To see how these failures affect systems in practice, read what happens when an RPC goes down.

Why Didn't Monitoring Catch It?

Monitoring missed it because the manipulation was selective. Compromised nodes returned manipulated data to the verifier while giving normal responses to other observers.

So dashboards looked consistent, monitoring systems did not trigger alerts and external observers saw no obvious issues. From the outside, the system looked healthy. Monitoring can only report what it sees, and when what it sees is already compromised, it cannot provide meaningful protection.

This is what RPC poisoning looks like: a node returns incorrect or manipulated blockchain data to a specific consumer while appearing normal to everyone else.

How Did the Impact Spread?

Once the incorrect state was accepted, the rest of the system behaved exactly as expected. A portion of the released rsETH was deposited into lending markets and used as collateral to borrow ETH based assets. Of the 116,500 rsETH the attacker took control of, 89,567 rsETH were deposited on Aave.

From that point, the asset appeared valid across the ecosystem. Pricing mechanisms treated it normally and downstream protocols accepted it according to their own rules. The impact spread without any further failure, because the same trust assumptions were applied across multiple systems.

What Does the KelpDAO Exploit Mean for System Design?

Any system that depends on external data has to consider how that data is verified before it is used. That applies to cross chain messaging, oracle systems and any workflow that relies on off chain reads.

Compare how systems usually treat oracles and RPC nodes:

That assumption about RPC nodes does not hold. As this incident showed, RPC nodes can be influenced or manipulated in the same way as any external data source. Treat them as part of your system's trust model.

What Does a Secure RPC Architecture Require?

Avoiding this class of RPC failure takes more than extra endpoints. Systems need to change how they use them:

• Genuinely independent providers. Independent providers matter, but only if they are independent of each other.
• Response comparison. Comparing responses lets a system detect inconsistencies before it acts, which matters most for high value actions.
• Quorum based verification. Instead of relying on one RPC response, the system queries multiple providers and proceeds only if their answers match.
• The ability to refuse to act. When only one source is available, continuing is often the wrong decision. Moving from fail open (keep executing when checks can't run) to fail safe (stop until they can) is a key part of resilient design.

Infrastructure providers like Spectrum Nodes make this possible by giving you access to nodes in multiple regions, but the validation itself must be implemented in your application. Without that layer, multiple endpoints still behave like a single source of truth.

These principles line up with wider infrastructure practice. For more, read about decentralised blockchain infrastructure and the role performance plays in reliability in Why High Performance RPC Matters.

What Should Teams Ask About Their Own Setup?

If you build cross chain or data dependent systems, ask these questions now:

• Are RPC responses verified before execution?
• Can a single endpoint influence system behaviour?
• Can the system detect inconsistencies across providers?
• Does the system put availability ahead of correctness?
• Can it identify conflicting views of the same block if they occur?

These questions are practical: they map directly to the conditions that enabled the KelpDAO exploit.

Where Does Spectrum Nodes Fit?

Reliable RPC infrastructure is part of the solution. The bigger gain comes from how your system sources, compares and validates data before acting on it, and that is the layer Spectrum Nodes supports.

We run our nodes on our own racks and hardware in multiple locations, we are SOC 2 Type II attested and we have never had a breach. That covers dependable access. The verification step belongs in your code.

For a concrete view of how this works, see How Spectrum Handles Requests at Scale. To apply these principles to your own setup, contact our team.

What Is the Main Lesson From the KelpDAO Exploit?

The incident did not break cryptography. It exposed the assumption that the data used to verify blockchain state is inherently trustworthy. That assumption holds in normal conditions and becomes fragile once infrastructure is part of the attack surface.

For systems that move value across chains, contract correctness is only part of the picture. The data those contracts rely on needs to be verified just as carefully. Without that, even a well designed system can produce the wrong result.

FAQ

How did the KelpDAO exploit happen? A forged cross chain message was accepted because the verifier relied on manipulated RPC responses. The attacker compromised some of the verifier's RPC nodes and made the rest unavailable, so the system accepted an incorrect view of chain state and released about 116,500 rsETH.

What is RPC poisoning in crypto? RPC poisoning is when a node returns incorrect or manipulated blockchain data to a specific consumer while appearing normal to others. It can lead systems to act on false information without any alert firing.

Why are multiple RPC providers not enough? Multiple providers improve availability, but they do not guarantee correctness. Without response comparison or validation, a system can still accept incorrect data if it uses compromised sources.

How can blockchain systems verify data correctly? Systems can compare responses across independent providers, require quorum agreement and run consistency checks before execution. This approach is often called multi RPC validation or quorum based verification.

What is an RPC node in blockchain? An RPC node is a blockchain node that answers remote procedure calls, letting systems read blockchain data and submit transactions. It gives access to chain state, such as balances, events and blocks.

What is a 1-of-1 DVN? A 1-of-1 DVN configuration lets a single verifier approve a cross chain message on its own, with no independent confirmation. LayerZero's integration checklist advises against single verifier setups in production, and the pathway affected in the KelpDAO exploit used one.

References

• https://kerneldao.com/kelp/restake/
• https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580
• https://docs.layerzero.network/v2/tools/integration-checklist
• https://www.linkedin.com/posts/isaaczarb_the-kelpdao-hack-clearly-shows-why-singlesource-activity-7452269048274427905-D_h1

Talk to our team: https://calendly.com/spectrumnodes-sales/30min