Fastest private HyperEVM WebSocket push, per-block race across keyed RPC providers
Per-block WebSocket push lag in milliseconds versus the first provider to deliver the same HyperEVM block, across API-key endpoints probed from us-east, eu-west and Singapore.
TL;DR. As of , Dwellir has the lowest median lag behind the first HyperEVM block push, 43 ms; Chainstack trails at 197 ms (p50, 24h) across 3 ranked providers. Source: OpenChainBench, https://openchainbench.com/benchmarks/hyperliquid-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 (HyperEVM) 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. Dwellir currently leads at 43 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 HyperEVM 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 measured, 3 ranked by Push lag (p50, 24h)
| № | Providers | p50 | p90 | p99 | Success | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Dwellir | 43 ms | 377 ms | 1.06 s | 99.83% | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2 | Chainstack | 197 ms | 548 ms | 1.05 s | 99.92% | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 3 | QuickNode | 200 ms | 433 ms | 825 ms | 100.00% | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Measured, not ranked: sample below the ranking floor | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| not ranked | GetBlock | 0.3 ms | 0.5 ms | 556 ms | 33.31% | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Frequently asked
Which private RPC provider pushes new HyperEVM blocks first over WebSocket?
Dwellir has the lowest median lag behind the first arrival over 24h; a figure inside the first histogram bucket reads as zero. QuickNode trails most, at 200 ms (p50, 24h). The board re-scores on every HyperEVM 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. QuickNode serves this chain's WebSocket on a separate /nanoreth path rather than the /evm path its HTTP endpoint uses. GetBlock completed a handshake only from Frankfurt, so it is raced from eu-west alone.
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