Archive node vs full node: what each can answer

Last updated: September 22, 2026

At a glance

What you see

A balance, eth_call or eth_getProof at a recent block works, but the same call at an older block fails, while block and transaction data for that old block is still readable. On other chains, old blocks themselves stop being available.

Why this happens

ethereum.org describes a full node as one that "stores full blockchain data (although this is periodically pruned so a full node does not store all state data back to genesis)", and an archive node as one that "stores everything kept in the full node and builds an archive of historical states" — needed for queries like "an account balance at block #4,000,000". Geth's --gcmode defaults to full, with archive as the alternative. State is one boundary; indexes are another: Geth keeps its transaction-hash and log indexes for the most recent 2,350,000 blocks by default (--history.transactions and --history.logs). Non-EVM chains draw the line per node too: a Solana node reports "the lowest confirmed block slot still available in this node's ledger" through getFirstAvailableBlock, and a regular TON liteserver "does not store the entire block history".

What to do

1. Classify the failing read: state at a block (balance, storage, call, proof) needs archive state; lookups by transaction hash or log filters depend on the node's indexes; block reads depend on retained blocks.
2. On EVM chains, read state at a recent block to confirm the call itself works before blaming history.
3. On Solana, compare the slot you need with getFirstAvailableBlock.
4. For deep history, use a node configured for it (archive state, full indexes) rather than retrying a pruned one.

When this is not our problem

Pruned state and bounded indexes are how node software is configured, whoever operates it, Triport included; the method reference for each network says what it serves. No retry turns a pruned node into an archive.