Low-Latency Binance Market Data: What the One-Way Numbers Mean

"Low latency" is the most-used and least-defined phrase in market data. Every vendor claims it, almost none say what they measured, from where to where, and against which clock. This guide takes one concrete product — our self-serve low-latency Binance market data for Binance USDT-M and Binance Spot — and spells out exactly what its latency figures are: one-way line latencies from Tokyo, ~69.8 ms to London, ~68.2 ms to Frankfurt, ~67.7 ms to Ashburn and ~64.1 ms to Ohio. What the line covers and what comes on top, why every trade carries the venue's transaction timestamp, how the line relates to the venue-side delay you can measure in any tick file, and how to check the full path yourself before paying for a second day.

Everything below runs on the CryptoStruct archive: every message Kalshi, Polymarket and 35+ crypto venues publish — every Level-2 snapshot and update at full depth, every trade, every contract, every day since we added the venue — captured co-located with nanosecond venue and receive timestamps and a gap-audited event-id chain, in one normalized schema. It is the same capture our own trading engine and enterprise feeds run on, sold as €1 day bundles you buy as a guest in the Data Shop with instant download — no subscription, no minimum, no sales call. Free full-day samples let you run every command in this guide before paying.

Three latencies, not one

A market-data path has three latencies worth separating. The first is the venue's own publication delay: the time between a trade matching inside Binance and the message leaving the exchange — nobody downstream can shorten it. The second is the line: the dedicated route from the capture host next to the exchange to the endpoint you connect at. The third is your on-ramp: the hop from that endpoint to the socket your process reads from, which depends on where you run. A latency claim that does not say which of the three it covers tells you nothing about what your strategy actually sees.

The self-serve feed quotes the second one — the line, the part we build — and says so next to every figure; the other two you can measure from the data itself. Captured at the venue in Tokyo and delivered at our London, Frankfurt, Ashburn or Ohio endpoints over dedicated lines. London, Frankfurt, Ashburn and Ohio are delivery endpoints, not sources — every message is captured next to the exchange in Tokyo and carried over a dedicated route to the endpoint you buy. That is also why the price is per UTC day rather than per message: the dedicated path is what you are paying for.

Measured one-way paths: London, Frankfurt, Ashburn and Ohio

The table lists every delivery endpoint on sale today with its one-way figure. The figures are the same for Binance USDT-M and Binance Spot at an endpoint — both markets ride the same line; only the port differs (Binance USDT-M on port 14004, Binance Spot on port 14003).

Ohio is the shortest path at ~64.1 ms one-way on the basis stated under the table; the spread between the endpoints is a few milliseconds, which is to say: pick the endpoint by where your strategy runs, not by the smallest number. A process in Frankfurt reading from Ohio adds a transatlantic hop that no line figure accounts for. London, Frankfurt, Ashburn and Ohio carry Binance today; more endpoints will follow.

What the line figure covers — and the two Binance clocks

Three things to know about the figure. First, it is the line and only the line: it starts at our capture host next to Binance in Tokyo and ends at our endpoint, so Binance's own publication delay comes before it and the on-ramp to your client comes after it. Second, it is one-way, not a round trip — market data only flows in one direction, so a round-trip figure would be a marketing choice. Third, the rest is yours to measure rather than to trust: every trade carries Binance's transaction timestamp "T", so you can time the full path from the match to your socket against the venue's own clock — and this is the part most comparisons get wrong: against "T", not the event timestamp "E".

Binance stamps every trade twice. "T" is the time the trade matched; "E" is the time the exchange emitted the event that carries it, which is later — sometimes by a lot under load. A latency measured against "E" ignores the venue's own queueing and looks better than it is. Measuring against "T" charges the venue's publication delay to the result, which is what you experience: your strategy cares about when the trade happened, not when the exchange got round to telling you. Our data carries "T" — in the live feed and in every historical file — so that is the clock to measure against. Whenever you compare feeds, ask which clock and which part of the path a number covers; a figure without those answers is not comparable to anything.

The venue-side delay you can measure yourself

The line figure sits on top of a delay you can observe directly: how long after a trade matched the exchange actually publishes it. Every CryptoStruct tick file carries two clocks per event — the venue's timestamp and the moment our co-located recorder received the message, both integer nanoseconds UTC. The difference is the exchange-to-capture delta, measured from a machine in the venue's own region, so it is close to the best case any client can see. For Binance USDⓈ-M BTCUSDT trades on one UTC day we measured a 1.45 ms median with a 3.45 ms p99 — the script, the full table and the tails for Kalshi and Polymarket are in Where to run your prediction-market trading bot.

Why this matters for the live feed: the historical files in the shop are recordings of exactly the stream the realtime endpoints deliver — same topics, same normalized schema, same two clocks. A backtest on a €1 day file therefore sees the venue-side delay your production system will see, and the one-way line figure above plus your own on-ramp to the endpoint is what you add on top.

One connection per host — the feed arbitrage is ours

Take all your instruments on one connection. Racing several connections to the same host against each other (feed arbitrage) gains nothing: they are served by the same host from the same feed, so no copy arrives earlier, and the duplicate traffic tends to slow your connection down rather than speed it up. That optimization is already done for you: we run feed arbitrage internally, before the data reaches your endpoint, so every connection delivers the fastest copy we have. Use further connections for independent processes only. A second socket from the same host to the same endpoint receives the same messages a few microseconds apart and competes with the first one for the same NIC and the same CPU; it adds jitter, never information. Independent processes on different hosts are the legitimate reason for further connections, and extra connections are added from your account for exactly that.

Which endpoint to connect to

• Run in or near the endpoint's region: London, Frankfurt, Ashburn and Ohio are AWS or data-centre sites, and the figure in the table ends at the endpoint. The hop from your host to the endpoint is yours to measure.
• Trading Kalshi? Its trading API runs in AWS us-east-2 — the region of the Ohio endpoint, which delivers the Binance feed next to it (see the Ohio endpoint post). Ohio never carries Kalshi data; it carries Binance data to where Kalshi strategies live.
• European execution venues or research desks: London or Frankfurt, whichever is closer to the machine that consumes the stream.
• Need both markets? Buy Binance USDT-M and Binance Spot at the same endpoint — Binance USDT-M adds mark price, index price, funding rate, liquidations, which do not exist on Binance Spot.

Verify it before you buy a second day

1. Baseline the venue-side delay from a tick file: a free full-day sample or a €1 day of the instrument you trade — the two clocks are in every event, the Python snippet is in the latency guide.
2. Buy one UTC day at the endpoint nearest to your host (paid days start at the next 00:00 UTC and the rest of the purchase day is included free, so the first evening is free).
3. Log the receive time of every trade against its "T" timestamp on your own host. The distribution you get is the venue-side delay plus the table figure plus your host's distance to the endpoint — compare medians and p99, never a single reading.
4. Only then decide on a longer run: longer runs cost less per day: −10 % from 14 days, −25 % from 30, −37 % from 180, −50 % from 365. Extend from your account; nothing renews on its own.

How to connect

1. Pick the endpoint and the market in the shop — a single instrument or the whole market; €49 per instrument-day or €99 per market-day.
2. Your API key is created with the first purchase and shown in your account next to the endpoint addresses; keep it in the CRYPTOSTRUCT_REALTIME_API_KEY environment variable, never in a prompt or a repo.
3. Connect over a plain WebSocket (JSON or SBE) — the port selects the market (Binance USDT-M on port 14004, Binance Spot on port 14003 at every endpoint).
4. Follow the connection guide for login, subscribe and keep-alive, or hand a coding agent the machine-readable spec and let it write the client.

Limitations

The self-serve feed covers Binance USDT-M and Binance Spot at the endpoints listed above; enterprise subscriptions already cover further locations and venues. The one-way figures are our line measurements on the stated basis, quoted as approximate values — they are not an SLA, they vary with venue load, and what your process observes also depends on the path from your host to the endpoint and on your own stack. The venue-side delay figure is one UTC day of one instrument and shows a shape, not a guarantee. Market data only: there is no order entry on this product, and nothing here is investment advice.