Archive-capable nodes must retain historical application state and indexes. A node bootstrapped from a state-sync snapshot does not have pre-snapshot historical state, so a full archive node must replay from genesis if it is expected to serve complete historical queries.

​
Archive configuration

Archive settings live in two files in the node home: app.toml and config.toml. Set the pruning strategy in app.toml:
"nothing" keeps all historic state and is the archive strategy. Do not add pruning-keep-recent or pruning-interval beside it: they apply only when the strategy is custom, so here they are inert and imply a retention limit the node never applies. Block retention is a separate control, also in app.toml:
0 prunes no blocks. It governs CometBFT block pruning only, not application state pruning. Retain historical ABCI responses and transaction indexes in config.toml:
Enable EVM historical indexing on archive RPC profiles in app.toml:
Keep CometBFT state sync disabled in config.toml:
[statesync] in config.toml controls whether this node bootstraps from a snapshot; an archive node must never do that. [state-sync] in app.toml controls the snapshots this node serves to other nodes, and is safe to enable here.
Do not run deploy.sh state-sync on an archive node. It wipes local data/, bootstraps from a snapshot, then re-disables [statesync] — leaving a config that reads correct on a node with no pre-snapshot history.

​
RPC and debug policy

The default public EVM namespace allowlist in app.toml is:
A private archive or operations node can add debug, txpool, and personal:
debug_traceTransaction needs only debug in the [json-rpc] api list. The trace type comes from the tracer config in each request, so leave [evm] tracer at its default empty value. A non-empty value such as "json" attaches that tracer to every EVM transaction, eth_call, and gas estimate the node executes ("json" logs a per-opcode trace to stderr), and is meant only for local debugging. Check the node’s [json-rpc] api list before relying on txpool or debug methods.

​
Archive sizing and backups

The current archive data footprint is roughly 1 TB and grows about 10 GB/month. Provision more disk than that: 4 TB minimum and 8 TB recommended for an archive node, as listed in Hardware Requirements, so there is spare capacity for growth, compaction, upgrades, logs, and backup staging. Run archive backups monthly.

​
Application alternatives

Most applications do not need an archive node. Use: