Ethereum Block Visibility Methodology

This page defines how QuantLoop measures regional Ethereum block visibility for its public reports, including how observations are collected, how timestamps are recorded, how visibility spread is computed, and what limitations apply.

Public report metrics are computed over regional probe cohorts using raw block header observations collected from QuantLoop-operated probes.

1. Data Collection

Each probe maintains a WebSocket connection to an Ethereum JSON-RPC endpoint and subscribes to eth_subscribe newHeads.

For every block header received, the probe records:

  • Probe location / region
  • RPC provider
  • Block number
  • Block hash
  • Observation timestamp

Probes rely on the host platform's system clock synchronization. QuantLoop does not currently adjust timestamps using independent clock-offset measurements.

To reduce silent subscription failures, probes reconnect and resubscribe if no block header is received for 60 seconds.

2. Observation Timestamp

The observation timestamp is recorded immediately after the block header message is decoded within the probe process.

This reflects application-level arrival time: the moment a consumer running inside the probe process could act on the decoded header.

Timestamps are currently stored with millisecond precision. Internally, the probe reads the local system clock using nanosecond precision and truncates the value to milliseconds before emission. As a result, reported observation times may be up to slightly less than 1 millisecond earlier than the underlying clock reading.

These timestamps may also include small user-space processing and scheduling delays. These effects are expected in application-level measurement systems and should be interpreted as measurement noise rather than pure network delay.

3. Visibility Metrics

Public report metrics are computed directly from raw block header observations collected during the selected reporting period.

Observations are matched using the canonical (chain_id, block_hash) pair. Competing blocks at the same height, such as during reorgs or temporary head replacements, are treated as distinct block visibility events.

For each block observed by multiple probes in the selected regional cohort, QuantLoop computes the visibility spread:

spread_ms = max(observation_timestamp) - min(observation_timestamp)

Percentiles such as p50, p95, and p99 are computed over the distribution of spread_ms values within the selected reporting period.

Missing observations are tracked separately. If an expected probe in the selected regional cohort does not observe a block within the report's completeness window, that absence is treated as an incompleteness signal rather than being folded into the visibility spread.

4. Interpretation

QuantLoop measures relative block header arrival timing from its own probe vantage points.

It does not claim to measure the exact moment a block was created, propagated across the peer-to-peer network, or accepted by every Ethereum node.

Results should be interpreted comparatively across regions and over time.

5. Independence and Sponsorship

QuantLoop reports are not sponsored provider comparison pages. Providers, infrastructure operators, and third parties do not choose the regions, cohorts, endpoints, metrics, or methodology used in public reports.

Public methodology changes are versioned and documented so that results can be interpreted consistently over time.

6. Limitations
  • Metrics reflect QuantLoop-operated probe locations and monitored endpoints, not every Ethereum node, RPC provider, or network path.
  • Upstream RPC provider behavior, including buffering, routing, and load, may influence observed arrival times.
  • Small clock offsets and drift between regions may contribute to measurement noise.
  • Region coverage may evolve as QuantLoop's measurement infrastructure expands.