How Azul latency is measured.
The live widgets on this site measure real round-trip latency from your browser. This page documents what they do, and what they don’t. The method is the same one chainlist.org uses, so you can cross-verify our numbers against a neutral third party.
What we call
Every measurement is a single JSON-RPC request:
POST <endpoint>
content-type: application/json
{"jsonrpc":"2.0","method":"eth_getBlockByNumber",
"params":["latest",false],"id":1}eth_getBlockByNumber('latest', false) is a lightweight read that every Ethereum-compatible node supports. The false flag returns transaction hashes only (not full transaction bodies). That keeps the response small, so we time the network and node path rather than payload serialization. We time the full client-side round trip with performance.now(), from the moment the request leaves your browser to the moment the response is fully parsed.
How we sample
How often
Each widget refreshes on a fixed 60scadence while it’s on screen. This is a sample, not a flood. We measure steady-state latency, and we don’t load-test anyone’s endpoint.
Why we discard the first request
The first request to any endpoint pays one-time setup costs: DNS resolution, TCP handshake, and TLS negotiation. Those costs aren’t representative of the latency you experience on a warm, keep-alive connection. So the first request is a warm-up and its timing is thrown away, exactly as chainlist does.
Why the median
After the warm-up, we take several warm round trips and report the median. The median shrugs off a single slow sample (a stray GC pause, a momentary network hiccup) in a way that a mean does not. It answers the honest question: what does a typical request feel like?
What we compare against
The widget measures Azul side by side with public Base RPC endpoints from your exact browser and network. Every endpoint runs over the same path, so the comparison is apples-to-apples.
The primary baseline is mainnet.base.org at https://mainnet.base.org, the canonical public endpoint, measured alongside other public providers.
Azul's latency spec
Azul is live on Base mainnet at https://rpc.baseazul.dev. It is built to a single-digit millisecond p50 server-side, with p95 in the low tens. These are the numbers the node is tuned to hold, best from eastern North America.
- p50
- 4ms
- p95
- 15ms
Server-side, single region. A conservative spec the node holds, the live measured envelope sits inside it, verifiable by the same method above.
The milliseconds you see in the widget add your own network distance on top of that server-side figure. Point the same request at https://rpc.baseazul.dev from your machine and you measure the full round trip the same way we do.
What we do NOT measure
Latency-to-block-tip is not the same as transaction inclusion. The widgets measure read round trips only. They do not measure how quickly a submitted transaction lands on chain.
Anywhere we visualize transaction inclusion (the “inclusion race” animation) it is a simulation. It illustrates the mechanism, not a live measurement. We label it as such. We won’t present a simulated race as if it were timed against the live sequencer.
One region, by choice
Azul runs from a single physical region: us-east-1 (Virginia). One server, tuned by hand, beats several half-tuned regions for the traders we serve. That means the round trips you measure depend on where you are. Near the US East Coast, the numbers look great. From Europe or APAC, expect roughly +50–150ms of network distance on top of the server-side figure.
This cuts both ways for every endpoint in the comparison, so the relative ranking stays meaningful. The absolute milliseconds you see are yours, measured from your machine, not a global average.
Cross-verify it yourself
Because we use the same request and the same warm-up/median discipline as chainlist.org, you can open chainlist, find Base, and compare its reported latency for mainnet.base.orgagainst what our widget shows from the same browser. They should be in the same ballpark. If they’re not, trust the one you ran yourself. That is the whole point of measuring from the client.
You saw how we measure.
Same discipline, applied to the part that moves PnL: a dedicated path with a latency SLA in writing, the region you choose, and a number we’ll stand behind. That’s what Edge buys.