Measurement Methodology

This page defines what QuantLoop measures, how observation timestamps are recorded, how propagation metrics are computed, and the key limitations to consider when interpreting results.

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:

Region (probe location)
Block number
Block hash
Observation timestamp

Probes run on dedicated cloud instances using standard system time synchronization.

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 could act on the decoded header).

Timestamps may include small processing and scheduling delays. These effects are expected in user-space systems and are part of the measured signal.

3. Propagation Metrics

Observations across regions are matched using the canonical (chain_id, block_hash) pair.
Competing blocks at the same height (e.g. during reorgs) are treated as distinct propagation events.

For each block observed in multiple regions:

spread_ms = max(observation_timestamp) - min(observation_timestamp)

Percentiles (e.g., p50, p95, p99) are computed over the distribution of spread_ms within a selected time window.

4. Interpretation

QuantLoop measures relative cross-region header arrival timing from its own vantage points.

It measures header arrival timing as observed by its probes. It does not claim to measure the exact moment a block was created or when the entire network converged.

Results should be interpreted comparatively across regions and over time.

5. Limitations

Upstream RPC provider behavior (buffering, routing, load) may influence observed arrival times.
Small clock offsets and drift between regions may contribute to measurement noise.
Region coverage may evolve as infrastructure expands.