Why a Chainlist RPC can fail at an older block

A Chainlist RPC can fail at an older block because the server behind the endpoint may not retain the historical state your request needs. An RPC endpoint is a connection to a node: your wallet or app sends it a method and parameters, and the node returns data or an error. A wallet may choose an endpoint listed on chainlist, but the URL identifies a server, not a guarantee about its historical database. To diagnose the failure, first identify which data the method asks the node to retrieve.

Why can an RPC read recent blocks but fail on old ones?

Reading a block and reading the network’s state at that block are different jobs. A block contains its number, timestamp, transactions and other recorded data. State is the result of applying transactions up to that point: account balances, contract code and storage values.

Nodes can keep block and transaction history while pruning older state to save storage. A request such as eth_getBlockByNumber may succeed for an old block because the block data is available. A call such as eth_call, or a balance query at that same block, may fail because it needs the state that existed then. Some nodes can reconstruct older state by replaying transactions from a stored checkpoint, but that takes extra work and may not be supported for every request.

An archive node retains historical states to answer these queries directly. Think of a regular node as keeping recent snapshots and enough records to rebuild some older ones; an archive node keeps the older snapshots ready. Endpoints differ in how much history they retain, so two RPC URLs for the same network can give different results.

What should you check when a Chainlist RPC fails?

Start with the request and the error, not just the age of the block. Check that the endpoint is for the intended network, then compare a recent-state request with the same request at the older block. If the recent call succeeds and the old one returns a missing-state or unavailable-history error, the endpoint likely lacks that historical state or cannot reconstruct it.

• Check the method. A block lookup may need only block data; a contract call or balance lookup needs state at the requested point.
• Check the block argument. Confirm the number or hash is valid for that chain and is being sent in the format the method expects.
• Check the error text. “Method not found” points to API support; a timeout or rate-limit response points to access or capacity; a missing historical state points to retained data or reconstruction.
• Compare endpoints. Send the same request to another endpoint for the same network. If only one fails, the problem is likely its configuration or service limits.

When choosing a Chainlist RPC for a historical query, check whether its provider documents archive access or historical-state support. An endpoint that works for sending transactions or reading the latest balance may still be unsuitable for older contract calls. Providers may also restrict old queries by plan, method or request volume, so an error can reflect policy as well as node storage.

How can you make the historical query work?

Use an endpoint that supports archive-state queries when the method needs old state. Keep the original block number or hash fixed while comparing endpoints; otherwise, a moving “latest” value changes the question being tested. If the old block lookup works but a state call does not, switching to another ordinary endpoint may not help unless that endpoint retains or can rebuild the required state.

For occasional research, a provider with documented historical access may be enough. For a product that repeatedly reads old balances or contract storage, make historical-state support part of the endpoint requirement and test the exact methods and block range the application uses. The key change is the data requested: old block records can remain available after old state has been pruned. Check what the method needs, then choose an endpoint that can serve it.