Zebra chain-state snapshots

Compressed zebrad state archives published by the Zcash Foundation, so a new node can skip Zebra's initial sync.

Loading a snapshot means trusting whoever cut it. A snapshot replaces the blocks Zebra would otherwise download and validate itself, and Zebra does not re-validate the blocks it finds in its cached state — so you are trusting that the node this was cut from validated the chain correctly up to the snapshot height.

These archives are not signed. The sha256 checksum only proves the file you downloaded is the file that was published. It does not prove the Zcash Foundation published it: the manifests are unsigned, and the checksum is served from the same origin as the archive, so anyone able to replace one could replace the other. If your node secures funds or serves other people's wallets, and you cannot afford to trust a third party's validation, sync from genesis instead.

mainnet

Archive	Height	Size	Produced (UTC)	DB format	zebrad	Files	sha256
zebrad-state-mainnet-v28-20260824.tar.zst latest	3459525	251.5 GiB	2026-08-24T23:52:03Z	28.0.0	6.3.0	manifest · sha256	`3678c383eef1…`
zebrad-state-mainnet-v28-20260728.tar.zst	3428101	250.3 GiB	2026-07-28T15:10:21Z	28.0.0	6.2.3	manifest · sha256	`45108a2dd1e9…`

Machine-readable: snapshots.json · SHA256SUMS

testnet

Archive	Height	Size	Produced (UTC)	DB format	zebrad	Files	sha256
zebrad-state-testnet-v28-20260824.tar.zst latest	4299514	8.7 GiB	2026-08-24T22:38:09Z	28.0.0	6.3.0	manifest · sha256	`4eabd27963e2…`
zebrad-state-testnet-v28-20260728.tar.zst	4211516	8.5 GiB	2026-07-28T13:21:14Z	28.0.0	6.2.3	manifest · sha256	`c4f5a769528e…`

Machine-readable: snapshots.json · SHA256SUMS

Using a snapshot

1. Check the database format version first

Open the snapshot's manifest and compare database_format_major_version to the DATABASE_FORMAT_VERSION your zebrad build expects. If they do not match, the snapshot will not load — pick a different one, or a zebrad build that matches. Also make sure you have room: the mainnet archive needs roughly its own size again once extracted.

2. Download and verify

curl -sSO <archive-url>
curl -sSO <archive-url>.sha256

sha256sum -c <archive>.tar.zst.sha256

Do not use an archive that fails sha256sum -c; re-download it. You can also verify several archives at once against a network's SHA256SUMS, from the directory you downloaded them into.

3. Extract into your cache_dir

Stop zebrad first if it is already running against this directory. The archive already contains the state/v<major>/<network>/ path Zebra expects, so extract it straight into cache_dir:

mkdir -p /path/to/your/cache_dir
tar --zstd -xf <archive>.tar.zst -C /path/to/your/cache_dir

To avoid keeping the compressed archive on disk, stream the download straight into extraction instead. This skips the standalone checksum step, so only do it once you have verified the checksum another way:

curl -sS <archive-url> | tar --zstd -x -C /path/to/your/cache_dir

This path has to match exactly. If cache_dir here does not match state.cache_dir in your zebrad.toml, zebrad will not error — it will silently start syncing from genesis instead. Double-check both paths before you extract. This is the most common way this goes wrong.

4. Start zebrad

[state]
cache_dir = "/path/to/your/cache_dir"

Check the logs for the starting height. It should be close to the snapshot's chain_tip.height from the manifest, not genesis. From there zebrad syncs the remaining blocks up to the current tip.

Scripting against this

Each network has a snapshots.json: an array of every published snapshot for that network, newest first, where the newest entry carries "latest" in its roles. There is no latest alias URL — resolve the current archive from the manifest instead:

curl -s https://snapshots.zfnd.org/mainnet/snapshots.json | jq -r '.[0].url'