Fastest Ethereum WebSocket newHeads push, live block-push lag across RPC providers
Per-block WebSocket push lag in milliseconds versus the earliest provider to deliver the same Ethereum head, measured continuously from one eu-west vantage point.
TL;DR. As of , PublicNode leads block push lag at 0.4 ms (p50, 24h) on Fastest Ethereum WebSocket newHeads push, live block-push lag across RPC providers. Source: OpenChainBench, https://openchainbench.com/benchmarks/ws-head-latency-ethereum.
Every trading bot, MEV searcher, liquidation keeper and live dashboard that subscribes to `eth_subscribe("newHeads")` cares about one number first: how many milliseconds after the network produces a block does my RPC provider actually push it to me? Marketing pages say "real-time WebSocket streaming"; this page says who delivers block N first and by how much the others trail. The harness holds one persistent WebSocket per provider from the same eu-west host, timestamps every newHeads frame on receipt, and scores each Ethereum block as a race: the earliest arrival sets T0, every other provider's lag is its arrival minus T0. The headline is pinned to Ethereum, where all three keyless providers compete; the same harness also races Base heads and Solana slots for cross-chain context. Because the measurement is relative, the leader reads near zero by construction, so the win-rate and the shape of the trailing distribution (p50 vs p99) are the numbers to read, not the absolute magnitude. PublicNode currently leads at 0.4 ms (p50, 24 h) across 3 measured providers.
Methodology
We race RPC providers on WebSocket block delivery. One harness holds a persistent `eth_subscribe("newHeads")` connection to each provider from the same host and timestamps every head frame on receipt. Per block, the earliest arrival across providers defines T0; each provider's sample is its own arrival minus T0, in milliseconds. A block's cohort stays open 5 seconds after the first arrival, then it is scored: lag histogram per provider, a win for the earliest, and a gap counter for any live provider that never delivered the block. The measurement is relative to the fastest provider observed from our vantage point, not an absolute network latency; the same-path subtraction is exactly what makes the ordering fair. Solana runs the identical race on `slotSubscribe` slot notifications.
Frequently asked
Which RPC provider pushes new Ethereum blocks first over WebSocket?
PublicNode currently wins most per-block races, with a median lag of 0.4 ms versus the earliest arrival (p50, 24 h) across 3 measured keyless providers. The leaderboard re-scores on every Ethereum block, roughly every 12 seconds, so the answer reflects sustained live measurement, not a one-off test. Check the win rate and the trailers' p99 before wiring a latency-sensitive bot to any single provider.
Why does the fastest provider show a lag near zero?
By construction. Each block is scored as a race: the earliest arrival among providers defines T0 and every sample is measured against it, so the provider that wins most races accumulates mostly zero samples. This is deliberate. A single vantage point cannot measure absolute chain-to-client latency without a reference node co-located with block producers; it can measure, fairly, which provider delivers the same block earlier over the same network path. Read the leader's win rate and the trailers' distributions, not the leader's absolute number.
Is this absolute latency from block production to my client?
No. The number is relative lag versus the fastest provider observed from our eu-west host. Absolute delivery latency includes the propagation time from the block producer to each provider's infrastructure plus the path to you, which shifts with your geography. What transfers to your integration is the ordering and the spread: if a provider trails the winner by 800 ms at the median from our vantage point, its pipeline is structurally behind, and that gap does not disappear because you probe from another region.
Could a provider cheat by pushing heads before validating them?
In principle yes: pre-announcing an unvalidated head wins the race at the cost of occasionally pushing a block that gets reorged or retracted. That is why the bench exports more than the lag histogram. A provider that pushes early but wrong shows up as cohort inconsistencies, elevated reorg noise and gaps, and the coverage column (blocks seen versus the cohort maximum) penalises skipped or retracted blocks. Hash-level cross-checking against an independent reference node is planned for v2 of the harness.
How is WebSocket head lag measured on OpenChainBench?
One Go harness holds a persistent eth_subscribe('newHeads') WebSocket per provider from the same eu-west host, plus slotSubscribe for the Solana cohort. Every frame is timestamped on receipt with time.Now() precision. A block's cohort stays open for 5 seconds after the first arrival, then each provider's lag versus the earliest is observed into a Prometheus histogram (0.5 ms to 10 s buckets, sub-millisecond floor so the winner does not collapse to a single interpolation artifact); p50/p90/p99 come from histogram_quantile over the 24 h window. Connections carry a 90 s silent-subscription watchdog and exponential-backoff reconnects so a flaky endpoint degrades to health=0 instead of corrupting the race.
Why are only PublicNode, dRPC and Tenderly listed?
V1 measures the keyless tier: endpoints anyone can open a WebSocket to without an account, which is also the tier where claims are hardest to verify and marketing is loudest. Alchemy, Infura and Chainstack require API keys; the harness already accepts them via environment variables and they join the leaderboard once contributor keys are wired into the deployment. Keyed tiers usually run on better-provisioned infrastructure, so expect the keyless numbers here to be the floor, not the ceiling, of each vendor's performance.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/ws-head-latency