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 , Solana Foundation leads slot push lag at 0.3 ms (p50, 24h) on Fastest Solana WebSocket slotSubscribe push, live slot-push lag across RPC 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.
Frequently asked
What is the fastest free Solana RPC over WebSocket right now?
Solana Foundation currently wins most per-slot races on Solana with a median lag of 0.3 ms versus the earliest arrival (p50, 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