Some exchange endpoints (like OKX's WebSocket) sit behind CloudFlare. When you open a connection to a CloudFlare-fronted host, your TCP and TLS handshake terminate at the nearest CloudFlare edge (usually a PoP in your own region), not at the exchange's actual origin server. So the TCP/TLS timings reflect your distance to the CF edge — which for most probes is only a few tens of milliseconds away — rather than the real distance to the matching engine in Tokyo/Hong Kong/etc.

We hide the TCP/TLS columns for every CDN-fronted endpoint — CloudFlare, CloudFront and Imperva alike — to avoid misleading users. The only honest number for those endpoints is the p50 round-trip, which travels all the way from the probe through the edge to the origin and back, whether that's a WebSocket ping or a REST request. That's what the p50 column shows.

Caching is the other trap. An edge that answers from cache returns in a few milliseconds and makes a distant venue look co-located — Bitstamp's REST API reads as 11ms from Dublin cached and 34ms when forced to the origin. Every REST measurement here defeats the cache on each request.

For endpoints that route directly to the exchange's origin (like Binance's WS API / FIX, which go straight to AWS Tokyo), TCP and TLS reflect real probe→origin distance and are shown.

Compare a venue against itself across regions freely — that's what these measurements are for. Comparing two venues head-to-head only works when both are measured the same way, because the three protocols capture different amounts of server-side work:

• WebSocket (ping/pong):pure network round-trip. The server's built-in WS library auto-replies to a ping frame with near-zero CPU work. The number reflects probe→origin→back network distance only.
• FIX:the server has to parse the FIX message, validate its structure, detect the missing auth field, construct a Reject + Logout response, and send it back. That's an extra ~3-4ms of real server-side processing on top of the network RTT.
• REST: a full HTTP request the API has to route, handle and serialise a response for. Like FIX, it carries real server-side work that a ping frame never touches.

From a Tokyo-co-located probe, this shows up as WS ≈ 0.7ms, FIX ≈ 4.6ms— not because FIX is slower, but because we're measuring a lightweight ping on one side and a full protocol request on the other.

The venues charted on REST rather than WebSocket are the ones with no order-capable WebSocket, listed in the section above. Expect their numbers to sit a few milliseconds higher than a WS-measured venue at the same distance, and read the "Measured" column before drawing a head-to-head conclusion.

The "Binance" entry here is binance.com(global entity). It blocks WebSocket + FIX APIs from US IPs and some other regulated regions, so probes in Chicago, Ashburn, San Jose, Ohio, and Johannesburg show no data for WS-primary products. REST still works everywhere, but we don't show it as primary because it's slower and CDN-fronted.

Binance.US (binance.us) is a separate legal entity with its own infrastructure and product set — we don't currently track it. If you're a US-based trader, binance.com numbers don't apply to you.

For each (exchange × product) combination we pick the fastest order-entry pathas the default — that's the number traders actually care about. The headline number is always a path you could actually send an order over. The other endpoints (REST when WS is faster, market-data streams, FIX drop-copy etc.) are still measured in the background and documented below, but surfacing them all in the UI adds noise without helping anyone decide where to host.

Where a product has two equally-legitimate order-entry paths — for example Binance Spot, where FIX is fastest but requires VIP tier and WebSocket API works for everyone else — we show a small toggle so you can switch between them.

Not every venue lets you trade over WebSocket. Bybit, Bitget, Bitstamp, Upbit, Coinbase's INTX derivatives, Bullish and Binance Options all publish market-data streams that accept no orders, so for those the headline number is their REST order path instead. Their streams are still measured and listed below — they're just not what we lead with, because a latency you can't trade on isn't much use.

Every other venue on this map leaves you to infer where its matching engine lives — that inference is most of what these measurements are for. Bullish just tells you: its connectivity documentation names asia-southeast1-a, a specific Google Cloud availability zone in Singapore, as the optimal place to run. It also warns the zone can move elsewhere within the region at any time and without notice, so treat it as current guidance rather than a permanent address.

That also makes Bullish the only venue here whose origin isn't on AWS. Our own measurements are consistent with the published zone, which is a useful sanity check on the method we use everywhere else.

CME is the main venue for regulated BTC and ETH futures in the US. Access is gated via member firms, vendors, or direct connections at CME's Aurora, Illinois datacenter. If you pay for co-location there, fills are measured in microseconds, not milliseconds.

Probable Origin: Appears to run in Asia

Bybit's public streams are market data only — orders go over REST, which is why REST is the headline number for every product. The four WebSocket streams (spot / linear / inverse / option) are still measured and shown below. Everything is CloudFront-fronted. No public FIX API.