Fastest private Arc WebSocket push, per-block race across keyed RPC providers
Per-block WebSocket push lag in milliseconds versus the first provider to deliver the same Arc block, across API-key endpoints probed from us-east, eu-west and Singapore.
TL;DR. As of , QuickNode has the lowest median lag behind the first Arc block push, inside the first histogram bucket; Chainstack trails at 52 ms (p50, 24h) across 4 ranked providers. Source: OpenChainBench, https://openchainbench.com/benchmarks/arc-rpc-ws.
A bot that subscribes to eth_subscribe(newHeads) does not care what a provider's median HTTP latency is. It cares who hands it block N first, and by how much the others trail. This page races the private (Arc) cohort: one WebSocket per provider per region, open ten minutes in every hour across the whole cohort, every frame timestamped on arrival, each block scored against whichever provider delivered it earliest. QuickNode currently leads at 0.3 ms (p50, 24h) across 4 keyed providers.
Because the measurement is relative, the leader reads near zero by construction. The numbers to read are the gap to the runner-up and the shape of the trailing distribution, p50 against p99, not the leader's absolute figure.
Methodology
Private, API-key Arc endpoints raced on WebSocket delivery. One harness holds an eth_subscribe(newHeads) subscription per provider in each of three regions and timestamps every push on receipt. Per block, the earliest arrival across providers in that region defines T0; each provider's sample is its own arrival minus T0, in milliseconds. The same process runs the HTTP arm of the keyed cohort, which is deliberate: comparing arrival times recorded by separate processes would compare clocks as much as providers, and the differences here are tens of milliseconds.
Results: 4 providers ranked by Push lag (p50, 24h)
| № | Providers | p50 | p90 | p99 | Success |
|---|---|---|---|---|---|
| 1 | QuickNode | 0.3 ms | 0.5 ms | 0.5 ms | 100.00% |
| 2 | Chainstack | 52 ms | 98 ms | 10.00 s | 99.90% |
| 3 | GetBlock | 75 ms | 135 ms | 204 ms | 66.76% |
| 4 | Dwellir | 187 ms | 251 ms | 409 ms | 99.98% |
Frequently asked
Which private RPC provider pushes new Arc blocks first over WebSocket?
QuickNode has the lowest median lag behind the first arrival over 24h; a figure inside the first histogram bucket reads as zero. Dwellir trails most, at 187 ms (p50, 24h). The board re-scores on every Arc block. Read the p99 column before wiring a latency-sensitive bot to one provider.
Why does the fastest provider show a lag near zero?
By construction. Each block is a race: the earliest arrival defines T0 and every sample is measured against it, so the provider that wins most races accumulates mostly zero samples. A single vantage point cannot measure absolute production-to-client latency without a node co-located with block producers; it can measure fairly which provider delivers the same block earlier over the same path. Read the gap to the runner-up and the trailing distribution, not the leader's absolute number.
Is this the same as the HTTP latency cohort on this chain?
Same providers, same keys, same regions, different question. The HTTP cohort measures a request you send; this measures a push you wait for, and the two orderings are not the same. GetBlock does not offer this chain from Singapore, so it is raced from us-east and eu-west only and its Singapore column is empty by provision rather than by failure.
Could a provider win by pushing blocks before validating them?
In principle, at the cost of occasionally pushing something that gets retracted. That is why coverage is published next to the lag: a provider that pushes early but wrong shows gaps, and the coverage column counts blocks seen against the cohort maximum. Hash-level cross-checking against an independent reference is not in this version.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/rpc-keyed-latency