Glassnode Latency Monitor — Real-Time Crypto Trading Infrastructure Latency

Live network latency from probes worldwide to crypto trading infrastructure and blockchains (Solana, SUI, Hyperliquid). Built for traders, HFT firms, market makers, and arbitrage operators choosing where to co-locate.

What we measure

Why infrastructure location matters

For trading firms racing to be first into a price move, physical distance to exchange matching engines and blockchain validators dominates total latency. A server in the wrong city can lose by tens to hundreds of milliseconds — enough to lose every arbitrage and MEV opportunity to better-located competitors. This site publishes the actual measured numbers, continuously, so operators can make data-driven hosting decisions instead of guessing.

Probe infrastructure

Probes deployed worldwide across Asia (Tokyo multi-AZ, Seoul, Hong Kong, Singapore), Europe (Amsterdam, Dublin, London, Frankfurt), the Americas (Ashburn, Ohio, Chicago, San Jose, São Paulo), and Oceania/Africa (Sydney, Johannesburg). Probes run on Fly.io and AWS bare-metal instances.

CEXHyperliquidPrediction MarketsSolanaSUIOracleGlassnode Studio→
← Back to map

About SUI Latency Map

Real-time latency monitoring across the SUI validator network.

What We Measure

SUI Latency Map continuously measures network latency from probes deployed around the world to all active SUI mainnet validators.

  • Voting power geography: where the network's stake is concentrated by country and city
  • Best co-location: which probe locations reach a quorum of voting power fastest

Why It Matters

SUI commits a transaction only after a quorum of validators by voting power has signed it. Unlike chains with a single rotating leader, the optimisation here is minimising the time to reach that quorum — not the time to a specific node. For market makers, arbitrage bots, and any latency-sensitive infrastructure on SUI, knowing where in the world to host directly affects how fast their transactions land.

A Note on Validator Reachability

A small number of validators firewall their public submission port and only accept connections from peer validators or from clients on a permissioned list. That is an operator policy choice, not an outage — those validators are still fully participating in consensus.

A Note on Shared-Object Transactions

For transactions that touch shared objects (DeFi swaps, AMM interactions, etc.), add roughly 400ms for consensus ordering on top of the latency shown here. That consensus delay is network-wide — it does not depend on where you host. The geographic optimisation captured by this map applies regardless: time-to-quorum is the only part of total transaction finality that your infrastructure location can influence.

Research Project Disclaimer

SUI Latency Map is a research project provided for informational and educational purposes only. The latencies shown measure network distance to validator submission endpoints — they do not include client-side transaction signing, consensus ordering, or finality. Numbers should be treated as estimates and directional baselines.