Jito Latency Benchmarks by Location
These are continuously-measured round-trip times from OrbitServers' Jito-connected locations to nearby Jito transaction-sender infrastructure. We publish the measured minimum, average, and maximum — so you can verify performance before you deploy, not after.
Last measured: 2026-06-28 21:11 UTC
| Location | Jito target | Min RTT | Avg RTT | Max RTT | Status |
|---|---|---|---|---|---|
| FrankfurtGermany | Jito (Frankfurt) | 0.59 ms | 0.61 ms | 0.64 ms | good |
| LondonUK | Jito (London) | 0.19 ms | 0.20 ms | 0.21 ms | excellent |
| AmsterdamNetherlands | Jito (Amsterdam) | 0.13 ms | 0.15 ms | 0.18 ms | excellent |
| New YorkUSA | Jito (New York) | 0.07 ms | 0.09 ms | 0.13 ms | excellent |
| Salt Lake CityUSA | Jito (Salt Lake City) | 0.08 ms | 0.10 ms | 0.11 ms | excellent |
| TokyoJapan | Jito (Tokyo) | 0.80 ms | — | — | good |
A dash (—) means that metric is not currently reported by the live feed for that location. Machine-readable data: /data/jito-latency.json.
Methodology
Latency is measured by continuous network round-trip probing from each OrbitServers location to nearby Jito transaction-sender infrastructure. Results are aggregated over recent rolling windows, and we publish the minimum, average, and maximum round-trip times from those windows.
The public feed is cached for a few seconds and fails open: if our measurement platform is briefly unreachable, the most recent known-good values are shown rather than a blank table or a fabricated number.
Want to verify? Our benchmarking guide walks through it, or run our open-source jito-region-latency tool (npx jito-region-latency) to rank every Jito region by latency from your own server.
Why we show min, average, and max
A single “average latency” figure hides how a connection behaves under stress. For trading and MEV, the tail matters most — so we publish the maximum alongside the minimum and average, giving you the full spread of what we measure rather than a single best-case number.
Limitations
These values are provided for infrastructure evaluation only. Real trading performance also depends on bot code, RPC configuration, Solana network conditions, system and kernel tuning, transaction strategy, and external market conditions. Providers and routes change over time — verify current performance for your own workload.
Methodology FAQ
Benchmark questions, answered
Our network-monitoring platform continuously probes the round-trip time from each OrbitServers location to nearby Jito transaction-sender infrastructure, aggregating the results over recent rolling windows. The figures shown are the minimum, average, and maximum round-trip times from those windows.
Min is the best round-trip time we measure, max is the worst within the recent window, and average is the typical value. Together they show both typical performance and how much the connection varies under load — which matters more for trading than a single headline number. We publish exactly what we measure and never invent figures we cannot stand behind.
Jito operates low-latency transaction-submission infrastructure used by Solana traders, MEV searchers, and arbitrage bots. Lower, more consistent round-trip time to this infrastructure can help latency-sensitive systems submit and react to transactions faster.
The values reflect the latest measured round-trip times at the time the page was loaded. Our live feed updates roughly every few seconds. If the feed is briefly unreachable, the most recent known-good values are shown rather than a blank table.
No. These figures are for infrastructure evaluation only. Real trading performance also depends on your bot code, RPC configuration, Solana network conditions, system and kernel tuning, and market conditions. Network latency is one input among many.
We publish our methodology so you can reproduce comparable measurements from your own host. Public probe scripts are on our roadmap so third parties can independently replicate the tests.