Fastest private BNB Chain WebSocket push, per-block race across keyed RPC providers
Per-block WebSocket push lag in milliseconds versus the first provider to deliver the same BNB Chain 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 BNB Chain block push, inside the first histogram bucket; GetBlock trails at 31 ms (p50, 24h) across 4 ranked providers. Source: OpenChainBench, https://openchainbench.com/benchmarks/bnb-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 (BNB Chain) 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 BNB Chain 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 | 32 ms | 138 ms | 99.95% |
| 2 | GetBlock | 31 ms | 299 ms | 808 ms | 100.00% |
| 3 | Chainstack | 59 ms | 596 ms | 10.00 s | 99.76% |
| 4 | Dwellir | 100 ms | 218 ms | 602 ms | 99.91% |
Frequently asked
Which private RPC provider pushes new BNB Chain 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 100 ms (p50, 24h). The board re-scores on every BNB Chain 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 issues one WebSocket token per chain per region, so its three cells are distinct endpoints rather than one URL probed from three places.
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