QuantLoop
InsightsMethodologyAboutContact

RPC Latency vs Block Visibility Latency

RPC latency measures how fast an endpoint responds.
Block visibility latency measures how quickly new blocks become observable through infrastructure.

Core distinction

Fast RPC responses do not mean early block visibility.

An endpoint can respond to requests quickly while still seeing new blocks later than another endpoint. Response latency and block visibility are separate signals, and they expose different failure modes.

RPC response latency
40 ms
Block visibility latency
+850 ms

The first number measures how quickly the endpoint answered a request. The second measures how much later it became aware of the same block.

RPC latency

How fast did it answer?

A request-response signal. Useful for measuring endpoint responsiveness, backend load, routing, caching behavior, and method-level latency.

Block visibility

When did the block appear?

A propagation signal. Useful for measuring how quickly an endpoint becomes aware of new blocks across providers, regions, and infrastructure paths.

The two metrics answer different questions

Imagine two RPC endpoints. Endpoint A answers an eth_blockNumber request in 40 ms. Endpoint B answers in 90 ms. But for the same new block, Endpoint B exposes the block 850 ms before Endpoint A.

Endpoint A

40 ms

Block 19,000,121 first seen

+850 ms

Faster request path, later block visibility.

Endpoint B

90 ms

Block 19,000,121 first seen

0ms

Slower request path, earlier block visibility.

A simple RPC latency benchmark would rank Endpoint A as faster. But that benchmark measures how quickly the endpoint replies to a request, not how quickly it exposes newly produced blocks.

That is the difference between RPC response latency and block visibility latency.

RPC response latency answers how long the endpoint took to reply to a request.

Block visibility latency answers how much later that endpoint exposed the same block compared with the first observed endpoint.

One block, four visibility times

For each block, QuantLoop measures when each provider exposed the block relative to the first observation in the sample:

block_visibility_latency = provider_observed_at - first_observed_at

For block 24,847,816, observed from Ashburn, the earliest provider in the sample is shown at 0ms. Other providers are shown by how many milliseconds later they exposed the same block.

Timeline showing when four anonymized providers first observed Ethereum block 24,847,816 in Ashburn.
First-seen time by provider for Ethereum block 24,847,816 from a single region.

The last provider exposed the block 318ms after the first observation.

Even from a single region, the same block became visible through different providers at different times. That gap is what block visibility latency captures.

The first-seen leader changes over time

For each block, QuantLoop identifies the first provider to expose it from a given region.

First-seen share shows how often each provider was first.

In this Ashburn sample, leadership changed across days. Provider B had the highest first-seen share on Apr 1 and Apr 2, while Provider A led on Apr 3 and Apr 4.

Daily first-seen share by provider

Apr 1-4, 2026 · Ashburn (us-east)

Apr 1
Apr 2
Apr 3
Apr 4
Provider A
2%
30%
73%
64%
Provider B
72%
48%
22%
35%
Provider C
26%
22%
5%
2%
Percentage of blocks first observed through each provider per day.lowerhigher

There is no universal fastest provider. First-seen leadership depends on region, day, and measurement window.

The provider that wins most often can still have a weaker tail

First-seen share shows who sees blocks first most often. It does not show what happens when a provider is not first.

For each block, QuantLoop compares every provider against the provider that saw that block first. A 0 ms lag means that provider was first for that block.

In this Ashburn sample, Provider A had the highest first-seen share across the period. But Provider B had the tighter tail: 467 ms at p99, compared with 1.4 s for Provider A.

Block visibility latency percentiles

Single-region sample from Apr 1-4, 2026 in Ashburn (us-east).
Lag is measured relative to the provider that saw each block first.

Providerp50p95p99
Provider A18ms219ms1.4s
Provider B41ms227ms467ms
Provider C139ms517ms3.0s

What this means

RPC response time and block visibility measure different dimensions of provider performance.

A provider can answer quickly while still serving an older head. Another provider can answer more slowly while exposing the latest block first.

For latency-sensitive systems, the useful question is not only "how fast did my request return?" It is also "when did this provider make the new block visible?"

Provider performance is not a single number. It changes by region, time window, and tail behavior.

What QuantLoop measures

QuantLoop measures block visibility across providers, regions, and time.

The goal is not to replace RPC latency benchmarks. It is to add the missing layer: when new chain state actually becomes observable through different providers.

This article used a short sample window to explain the methodology. The same approach can be extended across longer periods, more regions, and additional signals.

Fast responses matter. Seeing the chain first matters too.