RPC Failover

Overview

RPC Failover switches blockchain RPC traffic from an unhealthy, slow, rate-limited, or inconsistent endpoint to an alternative endpoint. Failover does not guarantee equivalent chain state because providers can differ in node client, archive support, indexing, mempool view, and block lag.

The main risks include stale reads, broadcasting duplicates, inconsistent pending state, false-positive failover, and dependence on correlated providers. It can be automatic or operator-controlled and may occur per request, network, region, or provider. The RPC Failover implementation should distinguish node acceptance, transaction broadcast, execution, confirmation, and indexed visibility where those stages apply.

In production, teams should define ownership and apply health scoring, chain ID verification, block-lag checks, capability tests, endpoint priority, circuit breakers, and failback controls. Provider failover for RPC Failover should not create a second transaction or replace a verified chain result with stale node data.

Useful measures include failover success rate, endpoint availability, block divergence, traffic shift time, and post-failover error rate. RPC Failover is closely connected to Dedicated RPC Endpoint, RPC Monitoring, and RPC Retry. When nodes disagree during RPC Failover, the application should preserve both observations and defer irreversible action until the authoritative chain state is clear.

The RPC Failover recovery procedure should distinguish a rejected RPC call from a transaction that was broadcast but not acknowledged. For RPC Failover, the client should retain chain, method, block or transaction reference, provider response, and the final on-chain observation.

Testing RPC Failover should include provider disagreement, reorganization or indexing delay, malformed data, and an unavailable node when relevant to the method.