Archive Node

Overview

A full node can validate new blocks using current state and canonical history without storing every intermediate state snapshot. An archive node keeps additional database versions so a request such as “read this contract at block X” can be answered directly.

The storage burden can be very large and grows with network activity. Fast disks, substantial capacity, memory, database tuning, and long synchronization periods are often required. Backups can be impractical if operators attempt to copy the complete database frequently. Archive access does not automatically provide convenient search. Address histories, token transfers, decoded events, and traces may still require an indexer or tracing API. The node supplies authoritative protocol data, while higher-level services transform it into searchable records.

Historical queries should specify block hash or canonical height and account for reorganizations. Contract proxy upgrades also require using the code and ABI active at the requested block. Operators should distinguish archive nodes from snapshots, block explorers, and data warehouses. Each serves a different purpose. Archive-node responses are valuable because they remain tied to validated protocol history, but availability and performance require specialized infrastructure.

The term is sometimes used interchangeably with archival node. Documentation should focus on retained state and supported queries rather than the wording alone. Provider APIs often market archive access even when only selected methods are supported. Applications should test the exact historical calls they require, including traces and contract storage. A fallback provider should use compatible block tags and data retention. If an old state query is critical for accounting or dispute resolution, the organization should preserve its own evidence rather than depend indefinitely on one commercial endpoint.