QuantLoop Measurement Methodology

QuantLoop runs independent probes across multiple regions. Each probe maintains WebSocket connections to monitored Ethereum JSON-RPC endpoints and records when selected Ethereum signals become visible.

For block visibility, probes subscribe to eth_subscribe newHeads. For every block header received, the probe records the probe region, RPC endpoint, chain identifier, block number, block hash, parent hash, block timestamp, and observation timestamp.

For contract-log visibility, probes subscribe to selected log filters using eth_subscribe logs. For every log received, the probe records the probe region, RPC endpoint, chain identifier, block hash, transaction hash, log index, event name, removal status, and observation timestamp.

These records form the base dataset used to compute visibility latency, observation coverage, replacement, and divergence metrics.

To reduce silent subscription failures, probes reconnect and resubscribe if no block header is received within an inactivity window of 60 seconds.

QuantLoop also records probe health events, including WebSocket terminations, disconnects, silent subscription stalls, and recoveries. This helps separate true delayed block visibility from periods where the observer itself was unhealthy.

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

This is an application-level arrival timestamp. It reflects the moment a consumer running inside the probe process could act on the decoded header.

Timestamps are captured from the probe's local clock at millisecond precision.

These timestamps may include small user-space processing delays, scheduler effects, host clock offset, or provider-side buffering. QuantLoop treats these effects as part of the measurement surface, not as pure peer-to-peer network propagation time.

Because visibility comparisons depend on timestamps from different probes, QuantLoop monitors probe clock offset against external time sources during the measurement window.

Clock-offset monitoring is used as a measurement control. QuantLoop records block observation timestamps as observed and does not rewrite or adjust them after capture.

Visibility metrics are calculated from normalized observation groups.

For block observations, signals are grouped by chain and block hash. Blocks with the same height but different hashes are treated as separate visibility events.

For contract-log observations, signals are grouped by chain, block hash, transaction hash, and log index. Removed logs are preserved as evidence and handled separately when analyzing replaced or reverted views.

For each visibility event, QuantLoop compares when each eligible observer in the selected cohort first saw the signal.

These comparisons produce metrics such as visibility latency, first-seen share, stale-view exposure, and observation coverage.

Visibility latency measures how late a selected view observed a signal compared with the earliest observation of that same signal within the cohort:

Observed visibility latency is summarized using percentiles such as p50, p95, p99, and p99.9. These percentiles can be computed for individual observers, or aggregated by provider, region, or custom grouping.

Missing observations are tracked separately. If an expected observer does not observe a signal within the completeness window, the absence is counted as an observation gap instead of being folded into visibility latency.

QuantLoop separates raw observations from computed metrics. Raw observations are preserved as the evidence layer. Metrics, analyses, and derived signals are generated from that durable record.

This allows historical windows to be replayed, derived metrics to be regenerated, and methodology changes to be compared against the same underlying observations.

Analyses are based on QuantLoop-operated observers, independent of RPC provider dashboards, status pages, and vendor-reported availability.

This gives each result a defined measurement perspective: what the observers saw, from the configured regions and endpoints, during the selected analysis window. Results should be interpreted from that perspective rather than as a universal claim about the entire Ethereum network.

Methodology versions document how that measurement perspective is defined. If QuantLoop changes how signals are observed, matched, compared, or classified, affected results may be recomputed or separated under a newer methodology version.

QuantLoop measures when selected Ethereum signals become visible from its own probe vantage points. Today, those signals include block headers and selected contract logs. It does not claim to measure the exact moment a block was proposed, the exact point a contract log was produced during execution, propagation across the full Ethereum peer-to-peer network, or exposure through every Ethereum node, indexer, or RPC provider.