Measured, not claimed

Solana RPC Benchmarks

Name: OrbitFlare Solana RPC benchmarks
Creator: OrbitFlare
License: https://creativecommons.org/licenses/by/4.0/

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.

Results

Methodology version 1.0 · last updated 2026-07-27

Shredstream vs Jito ShredStream

Raw shred delivery, first-detection latency · Frankfurt · 10,014 transactions · July 2026

Benchmark

Win rate: share of transactions delivered first

OrbitFlare · FRA95.93%
Jito ShredStream · FRA4.07%

latency behind the first feed

Endpoint	p50	p95	p99	First detections
OrbitFlare · FRA	0.00 ms	0.00 ms	1.21 ms	9,606
Jito ShredStream · FRA	6.51 ms	17.74 ms	28.77 ms	408

Both feeds measured side by side on the same host in Frankfurt. Delays are per transaction, relative to whichever feed delivered it first. 10,014 valid transactions, zero backfill on either feed.

GeyserBench: OrbitFlare shreds vs Helius shreds vs Jito ShredStream

Independent GeyserBench run, first-detection win rate and median latency · Frankfurt · 1,000 transactions · 1 March 2026

Verified

Win rate: share of transactions delivered first

OrbitFlare · FRA52.90%
Helius · FRA41.90%
Jito ShredStream · FRA5.20%

latency behind the first feed

Endpoint	p50	p95	p99	First detections
OrbitFlare · FRA	0.00 ms	n/a	n/a	1,000
Helius · FRA	0.19 ms	n/a	n/a	1,000
Jito ShredStream · FRA	1.79 ms	n/a	n/a	1,000

Run by the third-party GeyserBench tool from Frankfurt across three endpoints and 1,000 signatures in 1 minute 55 seconds, marked verified by the tool. It reports win rate and median latency only.

GeyserBench (runs.solstack.app) · Run c72e86ac-3a1...648ac · Duration 1m 55s

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.

Shred delivery, side by side

Two raw shred feeds are consumed on the same host in the same region. For every valid transaction seen on both, we record which feed delivered it first and how far behind the other feed was. We report the share of transactions each feed delivered first (win rate) and the percentiles of the delay behind the first feed. A feed that is first on a transaction has a delay of zero for it. Transactions seen on only one feed, and any backfilled data, 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.

Sources

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.