Solana Sender Latencyby Location
Measured round-trip time from every OrbitServers data center to the regional endpoints of Jito, Helius Sender, Astralane, Nozomi (Temporal), and bloXroute — so you can put your server where your sender is.
First scheduled measurement pending — the table fills in automatically once probes run.
| Location | Jito Block Engine | Helius Sender | Astralane | Nozomi (Temporal) | bloXroute |
|---|---|---|---|---|---|
| FrankfurtGermany · Jito edge | —ms | —ms | —ms | —ms | —ms |
| LondonUK · Jito edge | —ms | —ms | —ms | —ms | —ms |
| AmsterdamNetherlands · Jito edge | —ms | —ms | —ms | —ms | —ms |
| New YorkUSA · Jito edge | —ms | —ms | —ms | —ms | —ms |
| Salt Lake CityUSA · Jito edge | —ms | —ms | —ms | n/a | n/a |
| TokyoJapan · Jito edge | —ms | —ms | n/a | —ms | —ms |
| AshburnUSA | n/a | n/a | n/a | —ms | n/a |
| Los AngelesUSA | n/a | n/a | n/a | —ms | n/a |
Average RTT in milliseconds, with the measured min–max underneath. "n/a" means the service publishes no endpoint in that region (nothing local to measure — we never ping a stand-in host); a dash (—) means no successful measurement yet for that pair. Machine-readable data: /data/sender-latency.json.
The senders in this benchmark
Jito Block Engine
Jito's block engine accepts bundles and transactions through regional endpoints (Amsterdam, Frankfurt, New York, Salt Lake City, Tokyo and more). Jito-specific numbers live on our dedicated Jito benchmark page.
Helius Sender
Helius Sender is Helius's dedicated low-latency transaction submission service, with regional endpoints in Salt Lake City, Newark, London, Frankfurt, Amsterdam, Singapore, and Tokyo (per the Helius docs).
Astralane
Astralane operates a low-latency Solana transaction gateway with regional edges including Amsterdam, Frankfurt, New York, and Los Angeles.
Nozomi (Temporal)
Nozomi is Temporal's transaction submission service. We measure its direct endpoints (Newark, Ashburn, Los Angeles, Frankfurt, Amsterdam, London, Tokyo) rather than the Cloudflare-fronted variants, so the number reflects their servers, not a CDN edge.
bloXroute
bloXroute's Solana Trader API submits transactions through regional endpoints in New York, the UK, Germany, Amsterdam, and Tokyo.
Methodology
Looking-glass nodes inside each OrbitServers data center ping each service's published regional endpoint on a schedule and record the minimum, average, and maximum round-trip time per run. Only published same-region endpoints are measured — where a service has no endpoint in a region, the cell says "n/a" rather than substituting a host from another city.
This is network latency, nothing more. It does not measure transaction landing rates, tip effectiveness, or throughput — those depend on each service's internals and your workload. CDN-fronted hostnames (for example 0slot's) are excluded because a ping would measure the CDN edge, not the service.
Want the same measurement from your own connection or against a custom host? Run the live latency checker. Deploying next to a sender edge? Every OrbitServers city is a bare metal site, and the Solana trading and ShredStream pages cover the rest of the stack.
Common Questions
Solana Sender Latency — FAQ
ICMP round-trip time (min, average, and max) from each OrbitServers location to each service's published regional endpoint, measured by our looking-glass nodes on a schedule. It is network latency only — it says nothing about transaction landing rates, tips, or priority fees, which depend on each service's internals.
Your transaction has to cross the network between your server and the sender's endpoint before the sender can do anything with it. Placing your server in the same city as the endpoint turns that hop into a sub-millisecond LAN-scale trip instead of tens of milliseconds of internet.
0slot's published hostnames resolve to shared Cloudflare anycast IPs, so a ping would measure the nearest Cloudflare edge rather than 0slot's actual servers. Publishing that as "0slot latency" would be misleading, so we leave it out until direct hosts are available.
Use our latency checker: it runs live probes from every OrbitServers location to your connection, to any of these senders, or to a custom host you specify — the same measurement method as this page, on demand.
A scheduled job re-measures every sender-location pair roughly every 30 minutes. Each cell keeps its most recent successful measurement, and the page shows when the snapshot was last generated.
Latency is only one axis — fees, tips, throughput, and landing behaviour differ per service and change often, so benchmark them against your own workload. What this table tells you reliably is where each service has an edge and how close our locations sit to it, which decides where your server should live.