Glassnode Latency Monitor — Real-Time Crypto Trading Infrastructure Latency

Live network latency from probes worldwide to crypto trading infrastructure and blockchains (Solana, SUI, Hyperliquid, Arbitrum One, Robinhood Chain, Base, X Layer). 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.

← Back to map

About Base Latency

Real-time latency monitoring for the Base sequencer.

What is Base Latency?

Base is Coinbase's Layer 2, built on the OP Stack. Every transaction on it is ordered by a single sequencer, and there is no other way onto the chain — whether a transaction arrives through a public RPC provider or is submitted directly, it must reach that sequencer to be included.

How To Read These Numbers

Base's sequencer sits behind Cloudflare, so every measurement includes a hop to a nearby edge server before it reaches the sequencer itself. That adds roughly the same overhead wherever a probe sits, which lifts the whole picture rather than reshuffling it: comparing one location against another stays meaningful, but the absolute figure is higher than a direct connection would give. Connection setup timings reach the edge, not the sequencer.

Why It Matters: Flashblocks

Base builds its blocks in 200-millisecond slices called Flashblocks. Transactions are ordered by a combination of priority fee and arrival time — the fee competes for position, but arrival time decides which slice you make at all.

Once a Flashblock is built, its ordering is locked: a transaction that arrives later cannot buy its way into an earlier one, whatever fee it pays. Paying for priority raises the price of speed rather than removing the need for it — between two transactions paying the same fee, the one that gets there first is included first. That distance is what this map measures.

Methodology

Targetmainnet-sequencer.base.org
MeasurementEach probe submits a fixed signed transaction via eth_sendRawTransaction.
MetricTime to first byte of the sequencer's response over a warm connection — network round trip plus a few milliseconds of validation. p50 over 60-second windows.

Research Project Disclaimer

Base Latency is a research project provided for informational and educational purposes only. The latency metrics displayed are measured from specific geographic probe locations using our distinct server environments. Actual latency may differ. Real-world network performance depends on numerous factors including ISP routing, local network congestion, and hardware. These numbers should be viewed as estimates and directional baselines. This project is not affiliated with or endorsed by Base or Coinbase.

Want this data programmatically?
A REST API for all latency data is in the works. Join the waitlist and we'll email you once at launch