When RPC Data Lies: How to Diversify Blockchain Infrastructure Risk

On April 18, 2026, the KelpDAO rsETH bridge lost 116,500 rsETH, valued at about $292 million at the time.

According to LayerZero Labs’ final incident

report

, the attack began after a developer was socially engineered into exposing session keys. The attacker then gained access to LayerZero’s RPC environment and modified two running internal node processes in memory.

The compromised nodes returned:

The attacker also disrupted an external RPC provider with a denial-of-service (DoS) attack. The verifier then relied on the two compromised internal nodes and signed a message for an event that had not occurred.

The affected pathway required only one DVN. No second independent verifier was present to reject the forged message. LayerZero reported that its on-chain protocol was not compromised; the failure occurred in off-chain RPC infrastructure and the application’s verification setup.

Yes.

An endpoint can be online, respond within normal latency and still report an incorrect view of blockchain state. Uptime checks confirm that a service responds. They do not confirm that its answer is true.

The KelpDAO attack was designed around that gap. The compromised nodes changed their responses based on who was asking. Monitoring systems saw valid information, while the verifier received forged data.

For exchanges, custodians, payment processors and cross-chain applications, RPC data can trigger actions involving real assets. That data should be treated as an input to verify, not as unquestionable ground truth.

Not necessarily.

Two nodes can run in separate regions and still share the same failure domain. They may depend on the same:

Regional separation helps during a data-center outage. It offers less protection when an attacker compromises the credentials or software pipeline used across both regions.

LayerZero’s current

production guidance

recommends diversity across operators, infrastructure providers, RPC providers and verification methods. Two sources controlled by the same organization and deployed through the same pipeline can still fail together.

The number of endpoints matters less than how independently they are operated.

The application needs a defined verification policy before a disagreement occurs.

For a high-value transaction, teams may compare fields such as:

The policy should also define the required threshold. That may mean two matching sources, two out of three, or a separate verification service.

When trusted sources disagree, the system should pause the affected action and alert the responsible team. Silently choosing the fastest source defeats the purpose of diversification.

Running several nodes does not create this decision logic automatically. It must exist in the application or verification layer.

Novacula lets teams run supported blockchain nodes on customer-controlled bare-metal hosts, virtual machines (VMs) or Kubernetes clusters.

The nodes and executors run in the customer’s environment. Executors connect outbound to the Novacula control plane, while node processes and blockchain data remain on customer infrastructure. Existing nodes continue running if the control plane becomes temporarily unavailable.

This allows a company to use two operationally different sources:

The customer-controlled node can carry production traffic, provide a separate verification source or serve as a failover. The managed provider can remain available for additional capacity or redundancy.

Novacula does not automatically compare RPC responses or decide which source is correct. The application must still define how sources are checked and what happens when they disagree.

The goal is not to replace every external provider. It is to avoid making one provider the only source your business can use.

For Agent deployments, Novacula verifies downloaded software using Secure Hash Algorithm 256-bit (SHA-256) checksums.

The current Agent documentation states that:

A checksum helps confirm that a downloaded file matches the expected artifact. It can detect a corrupted download or a file that has been changed before installation.

It does not prove that the software has no vulnerabilities. It also does not inspect the memory of a running process.

That distinction matters here. The final LayerZero report says the attacker modified running RPC processes in memory. It would therefore be inaccurate to claim that a deployment checksum alone would have prevented the KelpDAO attack.

Checksum verification reduces one type of software supply-chain risk. It must work alongside access controls, runtime security, monitoring and independent data verification.

A practical design separates ownership, access and failure domains.

Run at least one customer-controlled node and keep a separately operated RPC source where the risk justifies it.

Avoid placing every source under the same:

Define which operations require confirmation from more than one source. Higher-value or irreversible actions should have stricter rules than ordinary read requests.

Pin approved versions and verify checksums or signatures before installing updates. Limit who can change node software or executor configuration.

Track health, synchronization and resource use, but also look for differences between independent sources. An endpoint that returns HTTP 200 may still be wrong.

A disagreement should pause the affected operation instead of silently falling back to a source that may be compromised.

No. Two endpoints may share the same provider, credentials or deployment pipeline. They reduce risk only when they fail independently.

That cannot be claimed. Novacula can add a customer-controlled RPC source and verifies downloaded software in Agent deployments. It does not continuously inspect process memory or automatically create agreement between RPC sources.

No. It confirms that a file matches an expected checksum. It does not prove that the software contains no vulnerabilities or cannot be compromised after it starts.

Yes. A customer-controlled node can work alongside a managed endpoint for comparison, failover or additional capacity.

The customer’s application or verification layer must define the decision rule. Novacula operates supported nodes but does not arbitrate between independent RPC responses.