Fastest Solana WebSocket slotSubscribe push, live slot-push lag across RPC providers
Per-slot WebSocket push lag in milliseconds versus the earliest provider to deliver the same Solana slot, measured continuously from one eu-west vantage point.
TL;DR. As of , PublicNode posts the lowest slot push lag at 0.4 ms (p50, 24h) across 2 ranked providers. Source: OpenChainBench, https://openchainbench.com/benchmarks/ws-head-latency-solana.
Solana slots land every ~400ms, thirty times faster than Ethereum blocks, and every real-time integrator on Solana (perp keeper, liquidator, market maker, on-chain scanner) inherits its provider's slot push pipeline thirty times as often. This page ranks the free keyless Solana WebSocket endpoints by the same relative race the EVM sibling uses on `eth_subscribe("newHeads")`, applied to Solana's `slotSubscribe` RPC. The harness holds one persistent WebSocket per provider from an eu-west host and timestamps every slot notification on receipt. Sample volume is roughly 30 times higher than the Ethereum sibling for the same 24h window, so the distribution is dense and tail estimates are stable. Provider cohort at launch: PublicNode's public Solana gateway and the Solana Foundation's `api.mainnet-beta.solana.com`.
Methodology
Per-chain member of the WebSocket head-latency cluster, applied to Solana. Same harness, same race scoring rules, adapted for Solana's slot model instead of EVM blocks: `slotSubscribe` notifications carry a slot number, the harness treats each distinct slot as one race, the first provider to deliver slot N sets T0, every other provider's sample is arrival minus T0 in milliseconds. The cross-chain view lives on the parent [ws-head-latency](https://openchainbench.com/benchmarks/ws-head-latency-ethereum) benchmark; this page is the Solana-scoped answer.
- Providers measured (keyless WebSocket endpoints): PublicNode (wss://solana-rpc.publicnode.com) and Solana Foundation (wss://api.mainnet-beta.solana.com). Keyed providers (Alchemy, Chainstack, Helius, QuickNode) join the cohort when contributor keys are wired via WS_URL_<PROVIDER>_SOLANA env vars.
- Cohort saturation: dRPC's free Solana tier explicitly disallows slotSubscribe ("method is not available on freetier") and the other public Solana WSS gateways audited (Blast, BlockPI, Ankr, extrnode, Chainstack public) all reject the handshake (verified 2026-07), which is why the keyless tier stops at two.
- Chain scope: every query on this page is pinned to chain="solana". Solana slot cadence is ~400ms, so a 24h window carries roughly 216000 samples per provider, an order of magnitude beyond the 7000 sample floor used across the head-lag cluster.
- RPC method: `slotSubscribe`, not `signatureSubscribe` or `logsSubscribe`. The notification payload includes the slot number and the parent slot; the harness dedupes on slot number and uses the first arrival per slot to define T0.
- Race scoring: identical to the parent [ws-head-latency](openchainbench.com/benchmarks/ws-head-latency-ethereum) benchmark, applied per slot instead of per block. First provider to deliver slot N sets T0. Each provider's sample for slot N is arrival(N) minus T0 in milliseconds. Cohort closes 5 seconds after the first arrival.
- Relative, not absolute: subtraction of two arrivals over the same path removes vantage-point network latency. Consequence: the fastest provider reads near zero by construction. The honest readings are win rate, trailers' lag distribution, and gap counts, not the leader's absolute number.
- Aggregation: per-provider lag histogram with a sub-millisecond floor (0.5 ms bucket up through 10 s tail), p50/p90/p99 via histogram_quantile over the 24h rate. Coverage score = ws_head_blocks_seen_total divided by cohort maximum, clamped to 1.
- Connection discipline: one persistent WebSocket per (provider, chain), client ping every 30s, read deadline 60s, 90s slot watchdog forcing reconnect when a socket keeps the heartbeat alive but silently drops the subscription. Exponential backoff 2s to 60s on reconnect.
- Vantage point: a single eu-west host. Multi-region deployment is a follow-up on the parent bench roadmap; the same limitation and reasoning are documented there.
Results: 2 providers ranked by Slot push lag (p50, 24h)
| № | Providers | p50 | p90 | p99 | First to push | Success |
|---|---|---|---|---|---|---|
| 1 | PublicNode | first · 84% | 5 ms | 151 ms | 83.7% | 100.00% (n=1452220) |
| 2 | Solana | 107 ms | 393 ms | 4.24 s | 9.71% | 65.11% (n=1049250) |
Frequently asked
What is the fastest free Solana RPC over WebSocket right now?
PublicNode currently wins most per-slot races on Solana first on 84% of the slots it received (24 h) across 2 measured keyless providers. The leaderboard re-scores on every Solana slot, roughly every 400ms, 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 Solana keeper or MEV integration to any single provider.
How is Solana WebSocket slot lag measured on OpenChainBench?
One Go harness holds a persistent `slotSubscribe` WebSocket per provider from the same eu-west host. Every notification is timestamped on receipt at millisecond precision, keyed on slot number, and deduplicated. Each slot is scored as a race: earliest arrival sets T0 and every other provider's lag is arrival minus T0. The cohort closes 5 seconds after the first arrival, then p50/p90/p99 are computed via `histogram_quantile` over 24 hours.
Why does the fastest provider read near zero?
By construction. The measurement is relative to the fastest arrival in the cohort, not to an external reference clock, so the provider that wins most races accumulates mostly zero samples. Without a validator co-located with block producers, a single vantage point cannot separate its own network latency from the provider's push pipeline. Read the leader's win rate and the trailers' distributions rather than the leader's absolute number.
Why aren't Alchemy and Helius on the leaderboard?
Both are keyed-only for Solana WebSocket subscriptions and V1 measures the keyless tier. The harness reads Alchemy and Helius endpoints from env variables and adds them to the cohort automatically once contributor keys are wired into the deployment.
Solana slots land every ~400ms. How does that change the numbers?
Sample volume is roughly 30 times higher than Ethereum for the same 24h window. Percentile estimates are drawn from ~216000 samples per provider versus ~7200 on Ethereum, so tail noise is negligible. The percentile numbers themselves are still relative to the per-slot winner, so the interpretation is unchanged. At Solana's cadence, a p99 above 1 second means the provider is routinely 2 to 3 slots behind the leader, which is the exact window where a keeper or liquidator loses to a co-located competitor.
Why `slotSubscribe` and not `signatureSubscribe` or `logsSubscribe`?
The race we score is head delivery: which endpoint pushes the newest thing first. On Solana that is a slot notification; `slotSubscribe` fires on every slot with the slot number and parent slot in the payload. `signatureSubscribe` targets one specific transaction and `logsSubscribe` filters by program, so neither is a fair head-delivery race across providers.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/ws-head-latency