Define one comparable event set
Comparing two streams only makes sense when they describe the same events at the same commitment and filtering scope. A feed that excludes failed or vote transactions cannot be scored against an unfiltered feed by raw message counts. Record filter definitions and decoder versions before timing anything.
Capture arrival at one point
event_key = (slot, signature) # transaction-stream example
first_arrival[provider].setdefault(event_key, monotonic_ns())
matched = keys(provider_a) & keys(provider_b)
delta = arrival_b[key] - arrival_a[key]Use a transaction key for transaction updates, not for account updates. Account streams need account identity and their update-order fields. Timestamp immediately after the chosen receive boundary, before variable-cost parsing where possible.
Publish the denominator
- Run both collectors in the same environment and log endpoint regions, connection settings and observation window.
- Count events seen by both providers, only A and only B. Keep unmatched events visible.
- Report median and tail differences for matched events, with the sign convention stated.
- Track client queue depth, CPU saturation and reconnect periods so receiver overload is not attributed to the provider.
Interpret the result narrowly
A relative arrival difference is a result for that event set, client and time window. It does not establish global network latency, transaction inclusion speed or a permanent provider ranking. Repeat with the actual filter workload your application will run. Use a separate correctness collector for finalized outcomes when early updates may later be invalidated.