What Is an Archive Node? Historical Data for Blockchain Teams

Understand what archive nodes retain, when teams need historical state, and what to verify before choosing an archive data source.

What is an archive node?

An archive node is a blockchain node configured to retain historical state. It can answer questions about an account, contract, or other state value at an earlier block, provided the network, client, and enabled interfaces support that query.

This is different from storing old blocks. A regular full node may keep the blockchain's block and transaction history while pruning intermediate state that is expensive to retain. An archive node preserves the additional historical state needed for queries such as an Ethereum account balance or contract storage value at a specific past block.

The term is not identical across every blockchain. Before ordering an archive node or archive RPC endpoint, confirm what the selected client retains and which methods expose it.

Current balance versus historical balance

On Ethereum, eth_getBalance accepts an address and a block parameter. These requests ask about the same address at different points in the chain:

{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","latest"],"id":1}

{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","0x1000000"],"id":2}

The zero address is an example; replace it with an address relevant to your application. The second request targets block 16,777,216, not the current head. A node may answer the first request but lack the historical state needed for the second, even if it still has that block's transactions. These are request examples, not results measured against a DTEAM endpoint.

The same distinction matters for eth_call and eth_getStorageAt at old blocks. Traces and historical proofs introduce further requirements: confirm the specific client, version, enabled APIs, and retained data rather than assuming the word "archive" guarantees them.

When retained state matters

Both full and archive nodes validate chain data. The practical difference is retention.

A full node is generally the right starting point for current-state reads, transaction submission, recent blocks, and many application workloads. Its client may prune old state to keep storage and maintenance requirements manageable.

An archive node retains substantially more data so that older state remains queryable. That additional history increases storage demand, initial synchronization time, backup complexity, and the time required to rebuild or replace a failed node.

Choosing between a full node and an archive node should begin with RPC methods, not labels. If the application only needs old blocks, transaction receipts, or logs, a full node or another indexed data source may be sufficient. If it must execute state-dependent queries at old block heights, archive data is more likely to be required.

Who needs archive RPC?

Archive RPC is commonly relevant to:

  • Blockchain explorers that display historical account and contract activity.
  • Indexers and analytics platforms that rebuild or compare state over time.
  • Security and incident-response teams investigating past behavior.
  • Auditors and compliance systems that need reproducible historical records.
  • Applications that call contracts or inspect storage at earlier blocks.
  • Data providers serving traces, proofs, or chain-specific historical methods.

Not every workload in those categories requires a dedicated archive node. Some teams need a limited block range, a narrow set of methods, or an indexed database rather than unrestricted node access. Documenting the exact queries prevents overprovisioning and makes provider comparisons meaningful.

Archive node infrastructure requirements

Archive nodes are storage-heavy, but disk capacity is only one part of the design. Disk throughput, database behavior, memory, CPU, client version, network synchronization, and the RPC workload all affect performance.

Operational planning should cover:

  1. The expected database size and growth rate for the selected chain and client.
  2. Initial sync or snapshot strategy and the time required to recover service.
  3. Storage performance under concurrent historical queries.
  4. Monitoring for synchronization lag, database health, disk growth, and RPC errors.
  5. Backup and replacement procedures that have been tested in practice.
  6. Capacity isolation between heavy archive queries and latency-sensitive traffic.

A node that has completed synchronization can still provide poor archive RPC service if large queries saturate storage or block lighter requests. Production deployments may separate workloads or place several nodes behind routing and health checks.

Self-hosted vs managed archive nodes

Self-hosting gives a team control over the client, hardware, retention policy, and access model. It also makes that team responsible for upgrades, chain incidents, storage expansion, monitoring, and recovery.

A managed archive node or dedicated archive RPC service transfers part of that operating work to a provider. The service still needs to be evaluated precisely. "Archive" does not guarantee every method, every historical block, unlimited request capacity, or a specific recovery objective.

Ask a prospective archive node provider to confirm:

  • The supported network, client, and archive configuration.
  • The oldest queryable block or retained history.
  • Supported HTTP, WebSocket, trace, and chain-specific methods.
  • Request, payload, concurrency, and timeout policies.
  • How synchronization health and historical correctness are checked.
  • Whether capacity is shared or dedicated.
  • Failover, maintenance, support, and escalation arrangements.

Testing an archive RPC endpoint

Create a test set from real application queries. Include the oldest required block, several intermediate heights, recent finalized blocks, expensive methods, concurrent requests, and responses large enough to reflect production behavior. A successful latest-balance request does not test archive coverage. Check the JSON-RPC body for errors even when the HTTP status is 200, and compare known historical results with an independent trusted source. Measure latency percentiles and error rates over time rather than accepting a single successful request as proof of coverage.

Also test failure handling. The application should know when to retry, switch endpoints, reduce concurrency, or report that historical data is temporarily unavailable. If archive access is business-critical, one node or one region is rarely a complete availability strategy.

For a broader explanation of the request layer, read what blockchain RPC is. To compare capacity models, see dedicated versus shared RPC.

To scope a dedicated archive node with DTEAM, send the network, earliest required block, exact methods, and expected concurrency. We can assess networks beyond those listed on our site; historical coverage and client capabilities must be confirmed for the requested deployment. DTEAM does not impose artificial request-rate limits or usage quotas on dedicated nodes, but hardware and query complexity determine throughput. See our dedicated RPC service for the service overview.

Sources and further reading