Archive Node vs Full Node: What's the Real Difference?

The Short Answer: Full vs Archive vs Trace

The core difference between a full node and an archive node is how much historical state they keep. A full node on Ethereum prunes state data older than 128 blocks (about 5 minutes), keeping only the latest state trie and recent block data. An archive node retains every state change since genesis, allowing you to query the state at any historical block. A trace node goes further by storing execution traces for every transaction, enabling deep replay and debugging.

This distinction matters for RPC calls like eth_call, eth_getBalance, and eth_getStorageAt. On a full node, these calls only work for the latest block or a block within the retention window. On an archive node, you can specify any block number and get the exact state at that point. For example, eth_call with a block parameter of 0x1000000 (block 16,777,216) will fail on a full node but succeed on an archive node.

The tradeoff is storage and cost. An Ethereum full node requires about 1 TB of disk, while an archive node can require 2-4 TB or more, depending on the client and pruning settings. This translates directly to higher hardware and operational costs. For many applications, a full node is sufficient, but if you need historical data, you need archive access.

• Full node: stores latest state (last 128 blocks on Ethereum) and can serve current data.
• Archive node: stores all historical state changes, enabling queries at any block.
• Trace node: stores execution traces, enabling replay and deep debugging.

curl -s https://eth.api.onfinality.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x0000000000000000000000000000000000000000","data":"0x"}, "0x1000000"],"id":1}'

How Full Nodes Prune State: The 128-Block Window

To understand why full nodes can't serve historical state, you need to know how Ethereum clients manage state. Ethereum uses a Merkle Patricia Trie to store account balances, nonces, and contract storage. When a block is processed, the trie is updated. To keep disk usage manageable, most clients implement state pruning: they delete trie nodes that are no longer referenced by the latest state. On Ethereum, the default is to keep state for the last 128 blocks, which is about 5 minutes.

This pruning is safe for consensus because the network only needs the latest state to validate new blocks. However, it means that if you query a block older than 128 blocks, the node cannot reconstruct the state because the trie nodes are gone. The node can still serve block headers, transactions, and receipts, but not state.

Other chains have different retention policies. For example, Solana's full nodes (called validators) keep state for the current epoch and can be configured to retain more, but they also prune historical state. Polkadot's full nodes keep state for the last 256 blocks by default, but can be configured to archive all state. The principle is the same: full nodes optimize for disk usage by discarding historical state.

This is why when you use a public RPC endpoint that is backed by a full node, you might get an error like "message":"missing trie node" when querying historical state. The node simply doesn't have the data.

• Ethereum full nodes prune state older than 128 blocks (about 5 minutes).
• Solana validators prune state older than the current epoch by default.
• Polkadot full nodes keep state for 256 blocks unless configured otherwise.

curl -s https://eth.api.onfinality.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x742d35Cc6634C0532925a3b844Bc454e4438f44e", "0x1000000"],"id":1}'

What Archive Nodes Actually Store

An archive node stores every historical state change since genesis. This means for each block, it keeps the entire state trie after that block was processed. This allows you to query the state at any block number, not just the latest. For example, you can call eth_getBalance with a block number from years ago and get the exact balance at that time.

The storage requirement is significantly higher. According to ethereum.org, an archive node requires 2-4 TB of disk space, compared to about 1 TB for a full node. This is because the archive node stores multiple versions of the state trie, and the trie nodes are never deleted.

The exact size depends on the client and its pruning settings. For example, Geth's archive mode stores all state, while Erigon's archive mode uses a different data structure that is more disk-efficient. Some clients also offer a 'snap' sync that can reduce the initial sync time, but the archive data still grows over time.

Because of the larger disk and I/O requirements, archive nodes are more expensive to run. They require faster disks (NVMe SSDs) and more RAM to handle the increased read/write load. This is why many developers choose to use an RPC provider that offers archive access instead of running their own archive node.

• Archive nodes store the full state trie after every block.
• Disk usage: 2-4 TB for Ethereum archive nodes, growing over time.
• Higher hardware requirements: NVMe SSDs, more RAM, and faster CPU.

curl -s https://eth.api.onfinality.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getStorageAt","params":["0x6B175474E89094C44Da98b954EedeAC495271d0F", "0x0", "0x1000000"],"id":1}'

Trace Nodes: The Next Level of Historical Data

A trace node goes beyond archive state by storing execution traces for every transaction. These traces record every step of the EVM execution, including opcodes, gas consumption, and state changes. This enables powerful debugging and analysis tools like debug_traceTransaction and trace_block.

Trace nodes are used by block explorers, analytics platforms, and developers who need to understand exactly how a transaction executed. For example, you can replay a transaction to see why it failed, or compute the gas used by each internal call.

The storage cost is even higher than an archive node because traces are verbose. A trace node can require 5-10 TB of disk for Ethereum, depending on the client and the level of detail stored. Some providers offer trace endpoints as a premium feature.

If you only need historical state (balances, storage, calls), an archive node is sufficient. If you need to debug transactions or analyze execution details, you need a trace node.

• Trace nodes store execution traces for every transaction.
• Enable methods like debug_traceTransaction and trace_block.
• Disk usage can be 5-10 TB for Ethereum trace nodes.

curl -s https://eth.api.onfinality.io -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"trace_block","params":["0x1000000"],"id":1}'

How to Test Whether Your RPC Endpoint Is Archive or Full

You can easily determine whether an RPC endpoint is backed by an archive node or a full node by making a simple eth_call or eth_getBalance request for a very old block. If the node returns a result, it's an archive node; if it returns an error like "missing trie node" or "header not found", it's a full node.

Here's a curl command you can run against any Ethereum RPC endpoint. Replace the URL with your endpoint and choose a block number from the past (e.g., 0x1000000 for block 16,777,216, which is around 2021).

curl -s https://your-rpc-endpoint -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x742d35Cc6634C0532925a3b844Bc454e4438f44e", "0x1000000"],"id":1}'

If the response contains a result field with a hex value, the endpoint has archive data. If it contains an error field, it's likely a full node. Note that some providers may have a separate archive endpoint, so check their documentation.

For other chains, the principle is similar. For example, on Polkadot, you can query state_getStorage with a block hash from the past. On Solana, you can query getAccountInfo with a specific slot, but note that Solana's archive nodes are less common and often require special configuration.

• Use eth_getBalance with an old block number to test archive availability.
• A successful result indicates archive data; an error indicates a full node.
• Check provider documentation for archive-specific endpoints.

curl -s https://your-rpc-endpoint -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x742d35Cc6634C0532925a3b844Bc454e4438f44e", "0x1000000"],"id":1}'

When Do You Actually Need Archive Access?

Most applications only need current state. If you're building a wallet, a DEX frontend, or a simple analytics dashboard, a full node is sufficient. You only need archive access if you have a specific use case that requires historical state.

Common use cases for archive nodes include:

• Historical analytics: Querying balances or storage at a specific past block for research or reporting.

• Auditing and compliance: Proving that a certain state existed at a certain time.

• Smart contract debugging: Replaying transactions or inspecting state changes over time.

• Building indexers: Backfilling data for subgraphs or custom indexers that need historical state.

• Governance and voting: Checking voting power at a past snapshot block.

If you need archive access, you have two options: run your own archive node or use an RPC provider that offers archive endpoints. Running your own archive node gives you full control but requires significant hardware and maintenance. Using a provider is simpler and often more cost-effective, especially for small teams.

At OnFinality, we offer archive RPC endpoints for multiple networks, including Ethereum, Polkadot, and Solana. You can check our network pages for availability and pricing for costs.

• Full node is enough for most dApps that only need current state.
• Archive access is needed for historical queries, audits, and debugging.
• Consider using a managed RPC provider to avoid the operational burden.

Cost and Storage Tradeoffs: Full vs Archive

The primary tradeoff is storage and cost. Here's a comparison table based on typical requirements for Ethereum (as of 2026):

These are rough estimates; actual costs vary based on cloud provider, disk type, and network. Archive nodes require NVMe SSDs to handle the I/O load, which increases cost. Managed RPC providers often charge per request or per month, but they handle the infrastructure for you.

If you're running your own node, consider using a client like Erigon, which is more disk-efficient for archive mode. Erigon can reduce archive storage by up to 50% compared to Geth, according to the Erigon documentation.

For many teams, using a managed RPC provider is more cost-effective than running an archive node in-house, especially when you factor in maintenance, monitoring, and uptime. Check our RPC pricing for transparent costs.

• Archive nodes require 2-4x more disk than full nodes.
• Managed RPC providers can be more cost-effective for archive access.
• Erigon reduces archive storage compared to Geth.

Common Pitfalls and How to Avoid Them

When working with full and archive nodes, developers often run into several pitfalls:

• Assuming all RPC endpoints are archive: Many public endpoints are full nodes. Always test with an old block before relying on historical queries.

• Using eth_call with a block number on a full node: This will fail for blocks outside the retention window. Use eth_call with latest or a recent block.

• Not considering state growth: Archive nodes grow over time. Plan for disk expansion or use a provider that handles scaling.

• Ignoring client differences: Different clients have different pruning and archive behaviors. Test your queries on the specific client you use.

• Overpaying for archive access: If you only need occasional historical queries, consider using a provider with pay-per-request pricing instead of a dedicated archive node.

To avoid these pitfalls, always test your queries against your chosen endpoint and understand the retention policy of the node you're using. For production applications, consider using a managed RPC service that offers both full and archive endpoints, so you can switch as needed.

• Test your RPC endpoint for archive support before relying on historical queries.
• Understand the retention policy of your node or provider.
• Use pay-per-request pricing for occasional archive queries.

Next Steps: Choosing the Right Node for Your Project

To decide between a full and archive node, start by listing your query patterns. If you only need current state, a full node is sufficient. If you need historical state, you need archive access. If you need execution traces, you need a trace node.

Consider the following decision checklist:

• Do you query state at blocks older than 5 minutes? If yes, you need archive.

• Do you need to debug transactions or inspect internal calls? If yes, you need trace.

• Do you have the hardware and expertise to run your own node? If not, use a managed provider.

• What is your budget? Archive nodes are more expensive, but managed RPC can be cost-effective.

Once you've decided, you can either set up your own node using guides like our blockchain node hosting guide or use a managed RPC service. OnFinality offers archive and trace endpoints for multiple networks; check our network pages for details.

For more on accessing historical data, see our article on accessing historical blockchain data. And for optimizing your RPC calls, read about JSON-RPC batching best practices.

• Use the checklist to determine your node type.
• Consider managed RPC for simplicity and cost-effectiveness.
• Explore OnFinality's archive and trace endpoints.