Measuring RPC Data Quality​

RPC providers form the foundation of blockchain data infrastructure, yet there is no standardized mechanism for validating the correctness or freshness of the data they serve. This is a significant risk for downstream applications -- indexing pipelines, DeFi protocols, and analytics platforms -- that depend on accurate, up-to-date chain data.

RouteMesh processes billions of RPC requests across 20+ EVM chains, serving data to enterprise customers who require deterministic accuracy. Our production routing infrastructure performs continuous data quality validation, enabling us to quantify provider performance objectively.

The findings presented here are drawn from live production data across our global node fleet, averaged across three major regions (Canada East, Frankfurt, Singapore). We analyze three of the largest RPC providers -- Alchemy, Quicknode, and Chainstack -- across two primary quality dimensions: data freshness (lag) and data correctness.

Data Quality Dimensions

We evaluate RPC providers across two independent dimensions:

Data Freshness (Lag): The latency between the canonical chain tip and the data a node reports. A node serving stale block data can cause missed opportunities, failed transactions, or incorrect state reads.

Data Correctness: The accuracy of the data returned relative to the canonical chain state. Even a node that is perfectly in-sync can return incorrect data due to internal bugs, corrupted state, or misconfiguration.

Both dimensions require infrastructure at scale to measure reliably. This report describes our methodology and presents 30-day production measurements.

Methodology: Measuring Data Freshness

Node lag is measured by comparing the block number reported by each node against the consensus block number observed across our fleet. Checks are executed at a frequency proportional to chain activity -- chains with higher block production rates receive more frequent sampling.

The primary mechanism involves querying eth_getBlockByNumber("latest", false) across the fleet at regular intervals and computing the distribution of reported block numbers relative to the network tip.

Methodology: Measuring Data Correctness

Measuring correctness is more complex. A naive approach -- duplicating every request across a second provider -- is economically infeasible at scale and introduces its own biases: if both providers are incorrect, the comparison yields a false positive. Assuming two independent providers each correct 90% of the time, the combined error rate is still approximately 1% -- significant when processing billions of requests.

RouteMesh uses a probabilistic replay mechanism designed for scale:

A data quality check is triggered for approximately 1 in every few thousand requests.

The original request is replayed in real-time, non-blocking, against additional nodes in the pool.

Responses are compared across all providers to determine the consensus result. A minimum of three non-null matching responses is required to establish finality.

Nodes that return non-conforming responses are struck. Depending on configuration, struck nodes are removed from the active production pool.

Struck nodes must pass through staged revalidation rounds -- with a pass rate disproportionate to their strike count -- before being reintegrated into the active pool.

This progressive filtering ensures that the active node pool converges toward the highest-quality providers over time.

Provider Analysis

The following analysis covers a 30-day production window. Data points where insufficient checks were performed are omitted (represented as blank gaps in the visualizations).

Alchemy

Data Freshness

Alchemy's fleet maintains strong synchronization with the chain tip across the majority of chains. Isolated nodes with elevated lag appear intermittently, consistent with normal fleet-level variance. This pattern is stable month-over-month with minor fluctuations.

Data Correctness

Correctness data reveals more variation. Ethereum mainnet exhibited notable correctness dips in mid-March, where a significant minority of requests returned non-conforming data. Chains with smaller ecosystems, such as HyperEVM, showed correctness rates in the 96-98% range -- functionally high, but still introducing measurable error into downstream pipelines processing millions of requests.

Quicknode

Data Freshness

Quicknode's fleet demonstrates more consistent lag across chains compared to Alchemy, though the direction of variance differs -- certain chains show persistent lag relative to the network tip, suggesting either lower priority in maintenance or ongoing infrastructure transitions.

Data Correctness

Quicknode's correctness data shows patterns of intermittent severe degradation. Arbitrum, Ethereum, and Polygon all exhibit periods where correctness drops significantly below acceptable thresholds. The pattern suggests correctness issues are not random -- they tend to cluster, indicating systemic rather than isolated failures.

Chainstack

Data Freshness

Chainstack's lag performance is generally strong, though several chains (notably Mantle and Sonic) show persistent and significant lag. Additional brief correctness drops on Polygon mainnet are also observable.

Data Correctness

Chainstack presents the most significant correctness challenges among the three providers analyzed. Our data consistently shows correctness rates below thresholds we consider acceptable for production data pipelines. However, RouteMesh's node selection and replay validation mechanism can isolate and filter the higher-quality nodes within the Chainstack fleet, enabling reliable utilization of the provider's good nodes even when overall fleet correctness is below ideal.

Industry Implications

The most concerning finding from this analysis is the widespread use of incorrect data in downstream applications across the blockchain infrastructure industry. Data indexing companies are typically aware of provider quality issues and employ their own redundancy and validation layers, but these solutions require operational sophistication and compute overhead that are inaccessible to smaller teams and startups.

The fundamental problem is misaligned incentives under static pricing models. RPC providers receive the same revenue regardless of data quality, creating no economic pressure to invest in the monitoring and validation infrastructure that RouteMesh maintains. This dynamic can only change when customers -- like RouteMesh's -- explicitly demand and reward data quality as a differentiating factor.

About RouteMesh

All data presented in this report is sourced from live production systems serving billions of requests through RouteMesh's routing algorithms. The monitoring infrastructure and validation methodology described herein are continuously refined to adapt to new chains, provider updates, and RPC methods.

This data is publicly available at https://routeme.sh/providers.

We believe RPC data quality is one of the most impactful but least addressed problems in blockchain infrastructure -- it is both one of the most fundamental building blocks of the industry and one of its least transparent components.

Looking Ahead

This report covers two of the four primary dimensions of RPC provider evaluation. We plan to publish additional analyses on:

Global latency -- head-to-head latency measurements across provider regions and geographic locations

Pricing transparency -- cost-per-request analysis with quality-adjusted comparisons

Chain coverage -- breadth and depth of RPC method support across providers

Rate limiting behavior -- throttling patterns and their impact on application performance

Subscribe to RouteMesh research for updates on these and future analyses.