Skip to main content
Cosmos Hub Snapshots, provided by Unity Nodes. Bootstrap a Cosmos Hub cosmoshub-4 mainnet node in minutes instead of a multi-day full sync, in goleveldb or pebbledb. Pick the database and the variant below - the table and the command update together, so you always see exactly what you are about to download.
Do not skip the priv_validator_state.json backup step in the command. That file records the last height and round your validator signed. Restoring somebody else’s signing state - or an older copy of your own - is the classic way to double-sign and get slashed.The command stops at the first step that fails, so a failed or cut download never restarts gaiad on a partial data/. Your signing state then stays in ~/.gaia/priv_validator_state.json.backup: fix the cause and run the command again starting from the rm -rf line.
A pebbledb snapshot needs both backend settings switched before the node starts - db_backend in config.toml and app-db-backend in app.toml. The pebbledb command in the picker above does it for you. Because the restore replaces the whole data/ folder, this is also how you move an existing goleveldb node to pebbledb.

​
What’s inside

  • data/ folder from a live Cosmos Hub (cosmoshub-4) gaiad full node with pruning (custom / keep-recent=100 / interval=19).
  • wasm/state - the CosmWasm contract bytecode. x/wasm keeps only the code hashes in application.db and the bytecode itself on disk, so a data/-only archive restores a node that cannot execute contracts. It is bundled here so the snapshot is self-sufficient. wasm/cache is deliberately left out: it is a compiled, machine-specific cache your node rebuilds by itself.
Full archive listing: snapshots.unitynodes.com/cosmos-mainnet/

​
Compatible software and settings

​
File names

Each archive is published under a name carrying the chain ID, database backend, block height and UTC creation time, with a matching .sha256 and .txt next to it:
latest.tar.lz4 and latest-pebbledb.tar.lz4 always point at the newest of each, so scripts can use a stable URL. Downloads support HTTP range requests, so aria2c -x8 and resumed curl -C - both work.

​
Verify the download

The .sha256 file is fetched first: it names the dated archive it belongs to, so the file you download is always the one the checksum is for, even if a new snapshot is published during a long download. The last line should read <archive name>: OK. For pebbledb fetch latest-pebbledb.tar.lz4.sha256 instead. To restore from the verified file rather than streaming it, use lz4 -dc "$F" in place of curl -fL <url> | lz4 -dc - in the picker command.

​
FAQ

goleveldb every 4 hours; the pebbledb snapshot for the same height follows about 30 minutes later. The last 2 of each are kept online.
Both. goleveldb and pebbledb, always at the same height.
It is converted from the goleveldb snapshot of the same height with pebblify, using the same pebble library version gaiad itself uses. Before anything is published, every key and value of the converted database is compared against the goleveldb original; a single mismatch stops the release.
Yes. The tarball carries only data/ and wasm/state. There is no config/ directory in it, so no priv_validator_key.json, no node_key.json and no keyring - your identity files are never overwritten by a restore.
No. wasm/state is already inside the snapshots above, so a single download gives you a node that can execute contracts. The standalone wasm.tar.lz4 exists only for topping up a node that is already synced.
Yes, briefly. The goleveldb archive is a cold tar taken with gaiad stopped, so the database is never copied mid-write. The pebbledb conversion works on that finished archive and never touches the running node.
No. On gaiad v28 with pebbledb, IAVL’s background pruning can still be reading when the database is closed during shutdown, and pebble reports that as a panic where goleveldb would just return an error. It happens after the last block is already committed. We reproduced it on our own pebbledb node and restarted from the same data: the node reopened in 20 seconds and kept producing app hashes identical to independent public RPCs.

​
Status and support

The service is monitored around the clock: snapshot freshness, archive size, the pebbledb conversion and public reachability of every download URL all raise alerts on two independent monitoring hosts. If a snapshot looks stale, a download fails or a checksum does not match, write to contact@unitynodes.com. Include the file name you were fetching and the error. We answer with what happened and when it will be fixed.