Why milliseconds matter in crypto trading
A liquid perpetual orderbook changes hundreds of times per second. Every price you see is already history — the only question is how stale it is. That staleness is latency: the round-trip time between your trading server and the exchange's matching engine.
In arbitrage the stakes are concrete. A spread window often lives for a few hundred milliseconds. If your order takes 300 ms to reach the exchange, the book has moved by the time it arrives — you fill at a worse price, and the slippage quietly eats the edge you were trying to capture.
Latency is physics, not software. A signal in fiber from Frankfurt to Tokyo and back takes roughly a quarter of a second no matter how optimized your code is. The only real fix is moving the server next to the exchange.
Where crypto exchanges actually host their servers
AWS Tokyo
Most major venues run their matching engines in a handful of cloud regions in Asia. Binance, Gate.io, KuCoin, Bitget, HTX and CoinEx respond fastest from AWS Tokyo (ap-northeast-1); MEXC and Hyperliquid are also reported to run there.
Singapore · Hong Kong
Bybit and Phemex are hosted in Singapore (ap-southeast-1). OKX sits closest to Hong Kong (ap-east-1).
Europe
The derivatives veterans live in Europe: Deribit's engine is in London, and Poloniex also responds fastest from Europe. The map below shows the four hosting hubs.
Where the matching engines live
Major crypto exchanges cluster in four hosting hubs
Binance
Bitget
Gate.io
KuCoin
HTX
CoinEx
MEXC
Hyperliquid
Bybit
Phemex
OKX
Deribit
PoloniexHubs are derived from our multi-region latency measurements; MEXC and Hyperliquid are publicly reported locations.
Latency by the numbers
We measured the round-trip time of a REST ticker call to each exchange from multiple AWS regions. The pattern is stark: the same request that takes 10–35 ms from the region next to the matching engine takes 200–500+ ms from the wrong continent — a 10–20× difference.
Treat the numbers as indicative round-trips for comparing regions, not as guarantees: WebSocket feeds are faster than REST in absolute terms, but the regional proportions stay the same.
Round-trip latency: co-located vs wrong continent
REST ticker call, measured from eight AWS regions
| Exchange | Fastest from | Best region | Worst region |
|---|---|---|---|
 Upbit |
Seoul ap-northeast-2 | ~10 ms | ~360 ms |
| DeribitArbitron |
London eu-west-1 | ~10 ms | ~464 ms |
 Bitvavo |
Frankfurt eu-central-1 | ~15 ms | ~996 ms |
| BybitArbitron |
Singapore ap-southeast-1 | ~16 ms | ~304 ms |
| Gate.ioArbitron |
Tokyo ap-northeast-1 | ~16 ms | ~381 ms |
 Kraken |
Frankfurt eu-central-1 | ~18 ms | ~64 ms |
 LBank |
Hong Kong ap-east-1 | ~18 ms | ~372 ms |
 Coinbase |
Singapore ap-southeast-1 | ~19 ms | ~84 ms |
| KuCoinArbitron |
Tokyo ap-northeast-1 | ~19 ms | ~509 ms |
 Bitstamp |
Frankfurt eu-central-1 | ~20 ms | ~337 ms |
 Bitfinex |
Frankfurt eu-central-1 | ~22 ms | ~118 ms |
 Okcoin |
Hong Kong ap-east-1 | ~22 ms | ~318 ms |
 Coincheck |
Tokyo ap-northeast-1 | ~23 ms | ~696 ms |
| BinanceArbitron |
Tokyo ap-northeast-1 | ~23 ms | ~424 ms |
 Coinone |
Seoul ap-northeast-2 | ~24 ms | ~367 ms |
| BitgetArbitron |
Tokyo ap-northeast-1 | ~24 ms | ~495 ms |
 EXMO |
Frankfurt eu-central-1 | ~24 ms | ~479 ms |
| PhemexArbitron |
Singapore ap-southeast-1 | ~25 ms | ~369 ms |
 ALP.COM |
Frankfurt eu-central-1 | ~25 ms | ~793 ms |
 Zaif |
Tokyo ap-northeast-1 | ~26 ms | ~400 ms |
 BitMEX |
London eu-west-1 | ~26 ms | ~362 ms |
 Bithumb |
Seoul ap-northeast-2 | ~27 ms | ~304 ms |
 LATOKEN |
Frankfurt eu-central-1 | ~28 ms | ~762 ms |
 Bitbank |
Tokyo ap-northeast-1 | ~31 ms | ~739 ms |
 HitBTC |
Frankfurt eu-central-1 | ~32 ms | ~517 ms |
 BTCBOX |
Tokyo ap-northeast-1 | ~34 ms | ~559 ms |
| OKXArbitron |
Hong Kong ap-east-1 | ~35 ms | ~440 ms |
 AscendEX |
Tokyo ap-northeast-1 | ~40 ms | ~498 ms |
 bitFlyer |
Tokyo ap-northeast-1 | ~44 ms | ~391 ms |
 Indodax |
Singapore ap-southeast-1 | ~46 ms | ~1180 ms |
 BigONE |
Hong Kong ap-east-1 | ~46 ms | ~338 ms |
 WhiteBIT |
Frankfurt eu-central-1 | ~46 ms | ~496 ms |
| CoinExArbitron |
Tokyo ap-northeast-1 | ~47 ms | ~462 ms |
 CEX.IO |
Frankfurt eu-central-1 | ~49 ms | ~861 ms |
 BEQUANT |
London eu-west-1 | ~54 ms | ~855 ms |
 zondacrypto |
Frankfurt eu-central-1 | ~56 ms | ~1035 ms |
 ProBit Global |
Tokyo ap-northeast-1 | ~58 ms | ~491 ms |
 NovaDAX |
London eu-west-1 | ~58 ms | ~370 ms |
 Mercado Bitcoin |
N. Virginia us-east-1 | ~61 ms | ~277 ms |
 YoBit |
Frankfurt eu-central-1 | ~62 ms | ~439 ms |
 Foxbit |
N. Virginia us-east-1 | ~62 ms | ~388 ms |
 DigiFinex |
Hong Kong ap-east-1 | ~66 ms | ~460 ms |
| HTXArbitron |
Tokyo ap-northeast-1 | ~70 ms | ~392 ms |
 One Trading (Bitpanda Pro) |
London eu-west-1 | ~70 ms | ~1064 ms |
 Coinmate |
London eu-west-1 | ~72 ms | ~860 ms |
 Luno |
London eu-west-1 | ~77 ms | ~1285 ms |
 Binance.US |
N. Virginia us-east-1 | ~78 ms | ~383 ms |
| PoloniexArbitron |
London eu-west-1 | ~85 ms | ~437 ms |
 Bit2C |
Frankfurt eu-central-1 | ~104 ms | ~979 ms |
 Gemini |
London eu-west-1 | ~116 ms | ~338 ms |
 Bitso |
N. Virginia us-east-1 | ~121 ms | ~519 ms |
 OceanEx |
Hong Kong ap-east-1 | ~121 ms | ~385 ms |
 Independent Reserve |
Singapore ap-southeast-1 | ~159 ms | ~444 ms |
 BTC Markets |
Tokyo ap-northeast-1 | ~283 ms | ~450 ms |
 Paymium |
Frankfurt eu-central-1 | ~349 ms | ~1685 ms |
 BL3P |
Frankfurt eu-central-1 | ~468 ms | ~680 ms |
| MEXC *Arbitron |
Tokyo ap-northeast-1 | — | — |
| Hyperliquid *Arbitron |
Tokyo ap-northeast-1 | — | — |
* Publicly reported location, not measured. Figures are indicative REST round-trips from our multi-region measurements — the fastest and slowest of eight AWS regions per exchange, for comparing regions, not SLAs. Defunct exchanges are excluded.
Server location by exchange
ALP.COM server location
AscendEX server location
BEQUANT server location
BigONE server location
Binance server location
Binance.US server location
Bit2C server location
Bitbank server location
Bitfinex server location
bitFlyer server location
Bitget server location
Bithumb server location
BitMart server location
BitMEX server location
Bitso server location
Bitstamp server location
Bitvavo server location
BL3P server location
BTC Markets server location
BTCBOX server location
Bybit server location
CEX.IO server location
Coinbase server location
Coincheck server location
CoinEx server location
Coinmate server location
Coinone server location
Deribit server location
DigiFinex server location
EXMO server location
Foxbit server location
Gate.io server location
Gemini server location
HitBTC server location
HTX server location
Independent Reserve server location
Indodax server location
Kraken server location
KuCoin server location
LATOKEN server location
LBank server location
Luno server location
Mercado Bitcoin server location
NovaDAX server location
OceanEx server location
Okcoin server location
OKX server location
One Trading (Bitpanda Pro) server location
Paymium server location
Phemex server location
Poloniex server location
ProBit Global server location
Upbit server location
WhiteBIT server location
YoBit server location
Zaif server location
zondacrypto server locationHow latency becomes slippage
A market order's life is: your server sees a price, decides, sends the order, and the exchange matches it against whatever the book looks like when it arrives. Latency taxes every step. In 300 ms a liquid perpetual book can refresh completely — the price you acted on simply no longer exists.
The damage is not theoretical. In our production measurements, a single fill executed on stale data once cost nearly 0.8% in slippage — several times a typical arbitrage spread. A well-placed server turns that into a rounding error.
Distance also degrades what you see, not just what you send: a far-away server receives every orderbook update late, so each decision is made on an old book. Co-location fixes both directions at once.
Choosing a server location for two-leg arbitrage
Trading a single venue is easy: put the server in the region next to it. Two-leg arbitrage is more subtle, because the two exchanges may live in different regions — and both legs have to fill.
The right rule is to minimize the worst leg, not the best one. A location that gives you 16 ms to one exchange and 200 ms to the other is worse than one that gives you 25–90 ms to both: the slow leg sets your real execution quality.
Examples from the table above: for Binance + Bybit, Tokyo (≈23 / 91 ms) beats Singapore (≈206 / 16 ms). For OKX + Binance, Hong Kong balances both. For Deribit + Poloniex — both hosted in Europe — London is the only sensible answer.
Rule of thumb: both venues in Tokyo → Tokyo. Mixed Asian venues → Tokyo or Hong Kong. European derivatives venues → London. When in doubt, Tokyo covers the largest share of major exchanges. You can check which venue pairs currently show tradable spreads in the live arbitrage scanner.
Server location on Arbitron
Your own server
Every Arbitron account runs on its own dedicated trading server with its own IP address, placed in the cloud regions where the exchanges themselves live — not on shared infrastructure on the other side of the planet.
You pick the region
You are able to choose the region your server is deployed in — Tokyo, Singapore, Hong Kong or Europe — so the venues you actually trade are milliseconds away, not continents.
No extra hops
Market data and order execution run directly between your server and the exchanges' APIs, with no extra hops. See how Arbitron works for the full architecture.