I Benchmarked 9 Crypto Exchange APIs From a US Datacenter (p50/p95/p99)

I run automated trading strategies and kept choosing exchanges based on vague "low latency" marketing claims. So I built a benchmark to actually measure it. Here is REST API latency to 9 exchanges, measured from a US-east datacenter, with the method and raw data open so you can reproduce or challenge any number.

Method

• 9 exchanges, measured from a US-east datacenter


• 50 samples each, keep-alive HTTPS GET to each exchange's public ticker endpoint


• TLS handshake timed separately so it does not pollute request timing


• plain Python standard library, no dependencies


• ranked by p95, because tail latency is what costs you when markets move, not the median

First surprise: two big exchanges block US datacenters entirely

Before latency even mattered, two of the largest exchanges refused to respond from US infrastructure:

• Binance.com returns HTTP 451 (unavailable for legal reasons)


• Bybit returns HTTP 403

If you are building on US-hosted infra, that constrains your options before you write a line of code.

The results

Latency in milliseconds, ranked by p95. Snapshot as of 2026-07-07; the live version re-runs every 2 hours.

Takeaway 1: the median lies

Kraken's median is a healthy 15ms, but its p99 blows past 60ms. Gemini's median is 25ms, but its p99 crosses a full second. If you size your timeouts and retry logic off the median, you get burned in exactly the volatility you built the bot for. Rank on p95 and p99.

Takeaway 2: "serves US" and "fast from US" are different questions

OKX (back in the US after its settlement) and Crypto.com both legally serve US customers, but they sit at 185 to 260ms from US-east. Their API endpoints are simply far away. Regulatory access and network proximity are two separate things, and only one of them shows up in a latency test.

Reproduce it, and what it does not cover

Known limitations, because they matter:

• Single datacenter (US-east). Latency is location-dependent, so your colo will differ. This is a relative comparison from one honest vantage point.


• This measures public-endpoint REST latency, not authenticated order-placement latency. That is the number that really matters for execution, and it is the next benchmark.


• Each run is n=50.

The numbers auto-refresh every 2 hours from the same box, and the raw JSON plus the script are published so you can re-run it yourself. Live table and method: https://fillbench.com/exchange-api-latency

What would you want measured next: authenticated order round-trip, or websocket latency and stability?