# Archive reads

Source: https://docs.graphops.xyz/rpc/concepts/archive-reads

Know when a request depends on historical data, so you can check coverage before you build on it
and keep large historical jobs within timeouts and response limits. A request is an archive read
when it asks for state, storage, code, balances, or event logs from older blocks.

Archive coverage varies by network; check the Archive column in
[Supported networks](../networks#supported-endpoints). When a network shows **Yes**, you can
read historical state at past blocks, such as `eth_call` against an older block, and fetch
historical event logs with `eth_getLogs`. On a Bitcoin network, archive access means `getblock`
returns any block since genesis. For example, reading a USDC balance on Ethereum Mainnet at
block `18000000` is an archive read; [Read contract state](../guides/read-contract-state) walks
through that request.

Archive requests are heavier than current-state reads and more likely to reach response-size,
timeout, or organization limits. Credits follow the method's cost class, not the block's age, so an
archive `eth_call` uses the same credits as a current one.

## Archive-sensitive methods

| Method             | Archive use                                                      |
| ------------------ | ---------------------------------------------------------------- |
| `eth_getLogs`      | Historical event backfills over explicit block ranges.           |
| `eth_call`         | Historical contract reads with an explicit block number or hash. |
| `eth_getBalance`   | Historical account balances.                                     |
| `eth_getStorageAt` | Historical storage-slot reads.                                   |
| `eth_getCode`      | Historical contract bytecode reads.                              |
| `eth_getProof`     | Historical account and storage proof reads.                      |

## Range strategy

_Reads of older blocks need archive data and are heavier than current-state reads. Backfill history in narrow, deterministic ranges and persist progress after every successful range, so a retry repeats only one range._

- Range 1: Stored
- Range 2: Stored
- Range 3: In flight
- Range 4: Queued

Split historical work into narrow, deterministic ranges instead of one unbounded `fromBlock` to
`latest` scan:

* Filter by contract address and topic whenever possible.
* Widen ranges only after observing response size and latency.
* Persist progress after every successful range.
* Retry a smaller range after a timeout or response-size error.

[Backfill historical events](../guides/backfill-historical-events) applies this model to a
resumable USDC `Transfer` backfill.

## Next steps

* [Backfill historical events](../guides/backfill-historical-events): Run a resumable log backfill with stored checkpoints.
* [Supported networks](../networks#supported-endpoints): Check archive coverage for your network.
* [Usage and limits](../usage-and-limits): See how method classes affect credit usage.