Archive node vs full node: what historical state means

A full node keeps every block and transaction but only the recent state of the chain; an archive node also keeps every past state, so it can answer what a balance or a contract variable was at any old block. Most apps never need that, but indexers, analytics, audits and backtests do, and the difference decides which RPC calls succeed.

Blocks, transactions and state

Two kinds of data sit in a blockchain node, and they behave differently.

History is the list of blocks and the transactions in them, plus the receipts and logs they produced. It only grows: block 100 never changes once it is final.

State is the current value of everything: every account balance, every nonce, every byte of contract storage. Each block changes some of it. "The state at block 100" is the full picture after block 100 was executed, and it is gone from the node's working copy as soon as later blocks overwrite it, unless the node chooses to keep it.

That choice is the whole difference between the two node types.

What a full node keeps

A full node stores the history and keeps only the last few states. On Ethereum, ethereum.org gives the state of the last 128 blocks as the example: enough to handle a reorganisation of recent blocks and to serve current data.¹ Older states are pruned, because the network does not need them to keep running.¹

A full node can still work out an old state in principle, by re-executing past transactions from a snapshot. That is computationally demanding, and it is the work an archive node avoids.¹

What an archive node adds

An archive node is a client configured to keep all historical states.¹ Ask it for the balance of an address at a block from years ago and it reads the answer from disk instead of rebuilding it. The price is storage: ethereum.org puts an Ethereum archive node at several terabytes, against a few hundred gigabytes for the transactions a full node keeps, depending on the client.¹

ethereum.org also notes that users never need an archive node for a standard interaction with the network.¹ Sending a transaction, reading today's balance or watching new blocks all work on a full node.

Which RPC calls need archive state

The rule of thumb: a call that reads state at a block other than the latest ones needs archive data. A call that reads history does not.

Typical work that needs archive data:

• Indexers and analytics that rebuild a token balance or a position at every block, or read a price from a pool contract at a past block with eth_call.
• Audits and incident analysis that check contract storage before and after an exploit transaction.
• Backtests that ask what an on-chain oracle or vault reported at the time.

Log queries and their ranges

eth_getLogs is the workhorse of indexers, and it does not need archive state. It does have its own limit: the block range per call. A filter over a million blocks is a heavy request for any node, so services cap the range and the client steps through long periods in pieces.

On Blockmetric RPC, one call covers at most 10,000 blocks, and 50 blocks on HyperEVM; long ranges are read in steps, narrowed by address and topics.² The gateway does not keep stateful filters, so a client reads logs with eth_getLogs over a block range or subscribes to them over WebSocket.²

HyperEVM: latest state only on the default RPC

HyperEVM shows how much this depends on the chain. Its official JSON-RPC answers eth_call, eth_getBalance, eth_getStorageAt, eth_getCode, eth_getTransactionCount and eth_estimateGas for the latest block only. Requests that need historical state are not supported on the default implementation; the documentation points to independent archive node implementations and to examples for indexing historical data locally.³

It adds one detail that matters for anyone replaying HyperEVM history: read precompiles (the calls through which HyperEVM contracts read HyperCore data) are recorded only for the calls actually made in each block. Answers to hypothetical precompile reads at an old block can only come from a full replay of the chain.³

Archive data and credits on Blockmetric RPC

The public RPC pages state that archive data is included on every plan, with trace and debug methods on the paid plans and single-transaction traces on every plan.⁴ Usage is counted in credits: one credit per standard request, with weights set per method class (standard reads 1, heavy reads such as eth_getLogs 2, trace and debug 5), and every response reports its cost in the header X-Blockmetric-Credits.⁵ The weight follows the method, not the block a call asks for.

Each plan's monthly credits and requests-per-second limit are listed on the RPC pricing page. The developer overview explains when the market-data API is the better tool: for liquidation, funding or position history, the API already serves computed series, so no archive reads are needed to rebuild them. What we store and since when is on historical data.