# WSS/RPC Measurement Methodology

Version: 1.1
Last reviewed: 2026-08-19

## Purpose

This method compares an operator's actual RPC or WebSocket paths. It does not
claim that one provider is universally faster, and it is not an FRB product
performance benchmark.

## Freeze the test

Record the following before collecting observations:

- provider and endpoint label, without credentials or query tokens;
- chain, network, transport, client, and request or subscription method;
- test region, hosting type, operating system, and network connection;
- UTC start and end time, clock source, and client version;
- warm-up rule, sample count, timeout, retry, and exclusion rules.

Use the same request shape and observation window for every endpoint. Never
publish wallet addresses, API keys, user identifiers, or private transactions.

## Collect raw observations

Write one row per attempt using the companion CSV template. Preserve failures
instead of removing them. Separate these events:

1. DNS and connection setup, when measured.
2. Request sent or subscription established.
3. Provider response or event received.
4. Transaction accepted by an endpoint.
5. Transaction included on chain.
6. Transaction finalized under the network's documented rule.

Endpoint acceptance is not inclusion, and inclusion is not an economic result.

## Report results

Publish the observation window, valid and failed sample counts, median, p95,
p99, timeout rate, reconnect count, and the aggregation code. Report units and
rounding. Explain exclusions and disclose whether connection reuse, caching,
rate limits, or geographic routing may have affected the result.

## Reproduction limits

Results apply only to the documented path and test window. Provider routing,
load, network conditions, client versions, and chain conditions can change.
Independent reruns should use the same frozen inputs and retain their own raw
observations.

## Companion dated observation

The first small public collection window exists to validate this method, not
to rank providers or describe FRB product performance:

- [raw CSV](./rpc-wss-observation-2026-08-19.csv)
- [environment and limitations JSON](./rpc-wss-observation-2026-08-19.json)
- [human-readable summary](./rpc-wss-observation-2026-08-19.md)

It contains five HTTP attempts per documented public Ethereum endpoint and two
requested `newHeads` events per endpoint with documented public WSS access.
The client egress region was not independently verified.

A [second raw CSV](./rpc-wss-observation-2026-08-19-window-2.csv),
[environment and limitations JSON](./rpc-wss-observation-2026-08-19-window-2.json),
and [human-readable summary](./rpc-wss-observation-2026-08-19-window-2.md)
record an independent low-rate window collected about seven hours later with
the same harness and settings. Both windows are from the same date and host;
they validate repeatable collection, not a multi-day trend or provider ranking.
Repeat the method on additional dates before discussing a trend.

## Different-date follow-up

A [third raw CSV](./rpc-wss-observation-2026-08-29.csv),
[environment and limitations JSON](./rpc-wss-observation-2026-08-29.json),
and [human-readable summary](./rpc-wss-observation-2026-08-29.md) record the
same low-rate collection method ten days after the first windows. Failed rows
remain in the raw data.

This adds a different-date observation but does not establish a durable trend.
All three windows are intentionally small and came from the same development
host with an independently unverified egress region. Do not aggregate them into
a provider ranking, uptime claim, or FRB product benchmark.