Ethereum RPC Redundancy: Coverage, Pair Latency, and Tail Overlap

QuantLoop measures whether a second Ethereum RPC endpoint adds contract-event coverage, lowers effective visibility latency, and reduces P99 tail overlap.

August 2nd, 2026

Redundancy is a property of the provider pair

Most production systems connect to more than one RPC provider. The second connection adds little protection when both streams miss or delay the same contract events.

Standalone provider metrics do not show that overlap. Two providers can each perform well on their own while producing similar delivery gaps and high-latency observations.

A provider with slightly worse standalone metrics can be the better secondary when its event delivery complements the first. QuantLoop therefore compares provider combinations, not only individual providers.

Coverage

Does either stream recover events missed by the other one?

Pair latency

How quickly does the first copy of each event arrive?

Tail overlap

How often are both delivery paths unusually slow on the same event?

Does the second provider increase event coverage?

An endpoint can stay reachable while its event stream disconnects or misses updates. Systems reacting to oracle updates, liquidations, vault activity, or bridge messages need every relevant event; a passing health check only confirms reachability.

QuantLoop measures delivery completeness separately from endpoint availability, as described in 99.99% Uptime Does Not Mean 99.99% Data Delivery.

QuantLoop builds a reference set from the contract events observed across the monitored provider set. It then measures each provider individually and every possible provider pair.

pair_event_coverage = events_delivered_by_either_provider / unique_events

Contract-event coverage by provider pair

Selected results from 66 provider combinations across the monitored contract events. Measured from IAD from July 15 through July 27, 2026 UTC.

Provider pair	Best standalone	Pair coverage	Events recovered	Shared misses
Provider A + Provider B	99.870%	100.000%	51	0
Provider E + Provider F	99.972%	100.000%	11	0
Provider B + Provider C	99.910%	99.997%	34	1
Provider C + Provider D	99.916%	99.985%	27	6
Provider G + Provider H	100.000%	100.000%	0	0

Pair coverage counts an event when either provider delivered it. A shared miss is an event in the reference set that was absent from both streams.

Provider A and Provider B recovered 51 events beyond the stronger standalone stream and covered the full reference set. Provider B and Provider C recovered 34 events but still shared one delivery gap. Provider C and Provider D left six events absent from both streams.

Coverage gains come from non-overlapping misses.

Does the pair expose contract events sooner?

Delivery alone is not enough for a latency-sensitive system. An event can eventually appear on both streams and still arrive too late for a keeper, liquidator, solver, risk engine, or trading system to act on it.

QuantLoop measures event visibility relative to the earliest observed delivery of the same event across the monitored provider set. For each event, the pair's effective latency is the earlier observation from either provider.

pair_visibility_latency(event) =
min(1st_provider_visibility_latency(event),
2nd_provider_visibility_latency(event))

Effective event-visibility latency by provider pair

Pair latency uses the earlier observation from either provider for each contract event.

Provider pair	Faster standalone P99	Pair P99	P99 improvement
Provider H + Provider K	1.622s	0.552s	66.0%
Provider G + Provider H	1.622s	0.799s	50.7%
Provider A + Provider B	3.386s	2.830s	16.4%
Provider B + Provider C	3.321s	3.065s	7.7%
Provider C + Provider D	3.285s	3.241s	1.3%

P99 improvement compares the pair result with the faster standalone provider in the pair.

Provider G and Provider H each delivered every reference event, so the pair added no coverage. It still reduced effective P99 visibility latency from 1.622 seconds to 0.799 seconds. Provider C and Provider D recovered 27 events, but their pair P99 improved by only 1.3%.

A pair can add no coverage and still cut P99 latency by half.

How often are both delivery paths unusually slow on the same event?

QuantLoop compares each delivery path with its own historical P99 threshold. Among events where at least one path exceeded its threshold, the shared tail rate measures how often both did. The calculation includes only events delivered by both providers; missed events remain in the coverage analysis.

shared_tail_rate =
  events_where_a_exceeded_its_threshold
  and_b_exceeded_its_threshold
  / events_where_a_or_b_exceeded_its_threshold

P99 tail overlap by provider pair

Each provider is evaluated against its own historical P99 threshold. The denominator includes only events where at least one provider crossed its threshold.

Provider pair	At least one in P99 tail	Both in P99 tail	Shared tail rate
Provider H + Provider K	741	5	0.7%
Provider G + Provider H	371	46	12.4%
Provider A + Provider B	708	92	13.0%
Provider B + Provider C	810	128	15.8%
Provider C + Provider D	551	358	65.0%

Shared tail rate = events where both providers crossed their own P99 threshold divided by events where either provider crossed its threshold.

Provider H and Provider K shared only 5 of 741 P99-tail events, or 0.7%. Provider C and Provider D shared 358 of 551, or 65.0%.

Provider-specific thresholds matter because providers have different normal latency distributions. A fixed cutoff can classify one provider's routine behavior as a tail event while ignoring a meaningful slowdown from another.

Choosing the second provider

Start with the provider already in use, then compare each candidate secondary by the improvement it adds to the pair.

Standalone metrics

Which provider delivered the most events?

Which provider had the lowest P99 latency?

Which provider had the fewest P99-tail events?

Second-provider selection

Which candidate recovered the current provider's missed events?

Which candidate reduced effective pair P99 the most?

Which candidate had the least P99 tail overlap with the current provider?

Choose the second provider by the additional coverage, lower pair latency, and reduced tail overlap it brings to the existing stream. The strongest standalone provider may not produce the strongest pair.

Choosing a second RPC provider?

See how QuantLoop compares provider pairs using the contracts, event signatures, and deployment region that matter to your system.

See how the assessment works

Limits of external measurement

Low tail overlap means the two delivery paths rarely became unusually slow on the same events during the measurement period. External observation cannot show whether the providers rely on independent infrastructure. They also cannot guarantee that a pair will remain uncorrelated during a future incident.

The results describe how the providers behaved during the measurement period for the selected contract events and region.

That behavior can change as providers alter routing, infrastructure, filtering systems, and subscription delivery paths. Redundancy should therefore be measured from delivered application data and reviewed over time, not inferred permanently.

FAQ

What is Ethereum RPC redundancy?

Ethereum RPC redundancy is the measured improvement from combining two RPC delivery paths. A pair provides stronger redundancy when either stream covers events missed by the other, the first observed copy arrives sooner, and high-latency events overlap less often.

How is RPC redundancy different from failover?

Failover switches traffic after an endpoint is identified as unavailable or unhealthy. Redundancy also covers partial failures that may not trigger failover, such as missed contract events or unusually high event-visibility latency while both endpoints remain connected.

How do you test whether two RPC providers are redundant?

Observe the same contract events from both providers in the application region, build a reference event set, and compare standalone performance with pair event coverage, effective pair visibility latency, and shared P95 or P99 tail rates.

How is pair event coverage calculated?

An event is covered when either provider in the pair delivers it. Pair event coverage is the percentage of reference events observed on at least one of the two streams.

How is pair visibility latency calculated?

For each event, pair visibility latency uses the earlier observation from either provider. This represents the effective latency available to a system consuming both streams.

What is the shared tail rate?

The shared tail rate considers events where at least one delivery path crossed its own historical P95 or P99 visibility-latency threshold. It reports the percentage of those events where both paths crossed their thresholds.

Does a low shared tail rate prove provider independence?

No. It shows that the observed delivery paths rarely entered their latency tails on the same events during the measurement period. It does not prove that the providers have independent cloud dependencies, node fleets, networking paths, or upstream infrastructure.