QuantLoop Measurement Methodology

QuantLoop runs independent probes across multiple regions. Each probe maintains WebSocket connections to monitored Ethereum JSON-RPC endpoints. Each endpoint-region pairing forms a distinct source, and the probe records when selected Ethereum signals become visible through that source.

For block visibility, probes subscribe to eth_subscribe newHeads. For every block header received, the probe records the source identity, 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 source identity, 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 a defined inactivity window.

QuantLoop also records probe health events, including WebSocket terminations, disconnects, silent subscription stalls, and recoveries. These events provide context for identifying intervals where delayed or missing observations may reflect probe health rather than endpoint behavior.

The observation timestamp is recorded immediately after the relevant WebSocket notification is decoded inside the probe process and becomes available to the measurement application.

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

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.

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 observations collected by QuantLoop-operated probes, independently of RPC provider dashboards, status pages, and vendor-reported availability.

This gives each result a defined measurement perspective: what became visible through the configured sources 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 through its configured sources. 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.