Measured, not claimed
Solana RPC Benchmarks
Latency, time to first shred and transaction landing rate, measured from our own regions against the live leader schedule. Every number on this page comes with its region, sample size and date, and the method is published below so you can reproduce it.
Measurements in progress
The first published run is being collected
We publish figures only once a run has been completed and reviewed. The methodology is already final below; results appear here, with their dates and sample sizes, as soon as the first run lands. Until then this page stays out of search indexes on purpose.
Methodology
Each measurement is taken by a probe running on a server inside one of our regions, so the figures reflect what a customer co-located with us would see rather than what our own racks see. Probes run against the same target set at the same time, on the same schedule, so rows in one run are directly comparable.
RPC request latency
Round-trip time for a fixed set of read methods (getLatestBlockhash, getAccountInfo on a warm account, getSlot) sent sequentially with a one-second gap, over a persistent HTTPS connection, for at least one hour per run. We report p50, p95 and p99 of the run and discard the first 30 seconds as warm-up.
Time to first shred
The gap between the leader's first shred for a slot (timestamped from the Turbine broadcast received by an independent listener in the same region) and the moment each target's feed delivers the first transaction from that slot to the probe. Measured per slot over the run and reported as percentiles. Slots where the leader skipped are excluded.
Transaction landing rate
A minimal self-transfer is signed against a fresh blockhash and sent through each target every five seconds. A transaction counts as landed if it is confirmed within the slot it was sent for or the following slot; later confirmations and expiries count as not landed. Reported as the share landed over the run, grouped by the region of the scheduled leader at send time.
Exclusions and versioning
Runs taken during a target's announced maintenance window are dropped. Network-wide outages that affect every target are noted in the run and retained. Any change to the method bumps the methodology version; rows from different versions are never shown in the same table.
Read the background
- What is Shredstream: why the first shred is the earliest observation point.
- Network infrastructure for low-latency Solana trading: where the milliseconds go.
- Provider comparisons: feature and pricing side by side.
Frequently asked questions
Three things, each from probes we run in our own regions against the live leader schedule: round-trip latency of common RPC methods, time from a leader broadcasting a block's first shred to our feed delivering it, and the share of test transactions that land in the slot they were sent for. Every row states the region, the target, the sample size and the date.
Because we publish numbers only when we have them. Until a measurement run has been completed, reviewed and added to the dataset, the page stays out of search indexes rather than show placeholder figures. The methodology is published first so the numbers can be checked against it when they arrive.
Yes. The methodology section describes the probe design, the sample sizes and the exclusion rules. Run the same method from your own location and you should see the same ordering between providers, with absolute figures that differ by your distance to the leaders.
Each published run carries its own date. We add runs when something changes: a new region, a client upgrade, or a competitor change worth re-measuring. The methodology version is bumped whenever the method itself changes, so rows from different versions are never compared silently.