Skip to main content
This page is for operators who need the full history of the Cosmos Hub, either the archived earlier chains or an unpruned cosmoshub-4 node. It assumes a working gaia install (Join mainnet). At the end you know where each chain’s data is and what a cosmoshub-4 archive node costs to run.

​
The four Hub chains

The Cosmos Hub has had four chain IDs. Each upgrade before cosmoshub-4 was a new genesis exported from the previous chain, so the earlier chains’ state is only available from archives. The legacy archives and linux-amd64 binaries are hosted by CCValidators. Each tar.zst holds a complete node data directory at the chain’s final height. The binary next to it is the gaia release that chain ended on. To query one, extract it and run that binary with --home pointing at the directory. The old binaries and their flags are not covered by these docs. Sizes are the download sizes on 2026-10-15. Verify downloads before use, as with any third party archive. The genesis files for every chain are listed on Genesis files. cosmoshub-4 itself has gone through many in-place software upgrades. A cosmoshub-4 archive node that replays from genesis therefore needs every binary from the chain’s start. That replay is covered under sync options below.

​
What an archive node is

An archive node keeps the application state at every height:
With pruning = "nothing" the node answers --height queries and historical REST calls for any height it has stored. Nothing else distinguishes it from a full node. It runs the same binary and syncs the same way. The min-retain-blocks key in app.toml must stay 0 so CometBFT keeps every block as well. Setting indexer = "kv" in config.toml keeps transactions searchable. Pruning modes and what each keeps are on Database and pruning.

​
Size an archive node

An unpruned cosmoshub-4 node holds every IAVL version since 2021. Its size is measured in terabytes, not gigabytes. The exact figure depends on the backend and on when the node was synced, and it grows with every block. For comparison, the pruned snapshots that providers publish (pruning = "custom", keep 100) were 9 to 16 GiB compressed on 2026-10-15. A pruned data directory is a few times that once extracted. Nobody publishes a maintained archive size, so measure before committing hardware:
Plan for the following regardless of the number:
  • NVMe storage attached to the host, not network block storage, because archive queries and compaction are latency bound.
  • Headroom for growth of at least a year of blocks, and a filesystem that can be extended without a resync.
  • At least 64 GiB of RAM so that compaction and historical queries do not stall block processing.
  • The same backend from the first block onward. Switching from goleveldb to PebbleDB means a full resync of all history, since there is no in-place conversion of historical IAVL versions.
CPU and network requirements otherwise match a normal full node. See System requirements.

​
Sync options for a cosmoshub-4 archive

There are three ways to get the data. Only two of them are practical:
  1. Copy an existing archive. A few operators publish full archive data directories. They are multi-terabyte downloads and are not listed in the chain registry. Ask on the Cosmos Hub forum or in operator channels for a current source. Verify the checksum, and confirm the backend matches your app-db-backend before extracting. Restore steps are the same as on Snapshots.
  2. Replay from genesis. The node starts from the cosmoshub-4 genesis with the gaia version that was current in 2021. It then runs every upgrade in sequence through Cosmovisor. This takes weeks to months. It also requires building each historical release with its own Go version. The upgrade heights and binaries are on Upgrade history.
  3. State sync or a pruned snapshot. Neither produces an archive. Both give the node state from one recent height only. Use them for everything except archives.

​
Serve an archive node

Archive nodes mostly exist to serve historical queries to explorers, indexers, and auditors. The RPC and REST setup is the same as for any public endpoint (Run public endpoints), with two additions. Rate limit /block_search, /tx_search, and abci_query at historical heights harder, because each of those can read gigabytes. Keep the peer-to-peer (P2P) peer count low (10 outbound, 20 inbound), since the node does not need to help others sync.

​
Verify

Query an old height. Proposal 1000’s upgrade executed at height 26131400. An archive node can answer state queries at that height. A pruned node cannot:
An archive node returns the gov module account’s balances at that height. A pruned node returns an error containing version does not exist or failed to load state at height. Check the configured pruning setting if the archive node also fails:

​
Next