RPC failover must account for different chain heads

A backup RPC can be reachable and still serve older state than the primary. Failing over after an approval may therefore make a sufficient allowance appear unchanged.

Record what each read means

Attach chain ID, observed block number and, when available, block hash to important reads. A value read at latest is only as recent as that node's current view. Do not treat a lower block height from a backup as a new authoritative update to a more recent confirmed state.

EIP-1898 allows block identity to be specified for supported state queries. A hash-based selector can provide stronger consistency than independently asking several nodes for latest, although support and historical availability still need checking.

Failover policy

First verify the backup's chain. Then compare its head with the minimum context the operation requires. A balance display may tolerate a short lag; confirming that an approval is available for immediate simulation may require a block at or beyond its receipt.

If the backup cannot serve that state, keep the operation in a waiting or unavailable state instead of prompting another approval. A duplicate approval may cost gas and still fail to fix the underlying stale-node problem.

Historical and pending reads have different requirements. A provider that serves recent blocks well may not retain the state needed for an older reproduction. Keep those capabilities in endpoint configuration.

Test the regression

Mock primary head 100 with an approval in block 99 and backup head 98 reporting zero allowance. The interface must not convert that older response into an approval-required state. Then advance the backup and verify normal recovery. This establishes a freshness invariant without assuming any particular chain's block interval.