Sigil publishes content-addressed state snapshots every 1,000 blocks. New validators and RPC nodes can sync state-only from a snapshot, then catch up the block tail from peers. This is the canonical fast-sync path on every network.

​
URL layout

https://snapshots.sigil.ml/<chain-id>/latest.json
https://snapshots.sigil.ml/<chain-id>/<height>.manifest.json
https://snapshots.sigil.ml/<chain-id>/<height>.tar.zst
https://snapshots.sigil.ml/<chain-id>/<height>.tar.zst.blake3
The manifest schema (snapshot-manifest.json): 
{
  "schema_version": 1,
  "chain_id": "sigil-mainnet-1",
  "height": 123000,
  "state_root": "<32-byte hex>",
  "block_hash": "<32-byte hex>",
  "payload_uri": "123000.tar.zst",
  "components": ["smt-state-root", "akashakv", "block-store-delta"]
}

​
Publisher

Mainnet runs sigil-snapshot-publisher as a Kubernetes CronJob defined in k8s/mainnet/62-snapshots.yaml. Configuration:
FlagValue
--source-data-dir/snapshot-source/data
--work-dir/tmp
--interval-blocks1000
--hash-algorithmblake3
--retention-recent-blocks100000
--retention-checkpoint-interval10000
The publisher writes to s3://sigil-mainnet-snapshots/sigil-mainnet-1 and serves it via https://snapshots.sigil.ml/sigil-mainnet-1. Object-store credentials are held in the sigil-snapshot-objectstore Kubernetes Secret, never in source. The CronJob mounts data-sigil-rpc-0 read-only. Production must populate that PVC from an isolated filesystem or CSI snapshot rather than from a live writable RPC database mount when the storage class supports snapshot clones. The publisher refuses writable source data by default; local drills must pass --allow-writable-data-dir explicitly.

​
Retention

  • Keep every snapshot from the last 100,000 blocks.
  • Keep one snapshot per 10,000 blocks before that.
  • Delete older non-checkpoint snapshots after the hash inventory is updated.

​
Restore

  1. Stop the node and preserve the old PVC.
  2. Restore into an empty data directory only.
  3. Start sigil-node with --restore-from <snapshot-uri> and the signed genesis file.
  4. The node verifies the archive BLAKE3 sidecar when present, restores the payload, and checks the manifest state root against genesis for height-zero snapshots or against the restored canonical block header for height > 0.
  5. After restore, normal bootstrap opens the restored AkashaKV stores, then P2P catch-up applies blocks after the snapshot height.
sigil-node \
  --mode rpc \
  --chain-id sigil-mainnet-1 \
  --data-dir /data \
  --genesis /config/genesis.json \
  --expected-genesis-hash "$SIGIL_EXPECTED_GENESIS_HASH" \
  --restore-from https://snapshots.sigil.ml/sigil-mainnet-1/latest.json \
  --state-sync-mode snapshot-then-p2p-catchup \
  --snapshot-base-url https://snapshots.sigil.ml/sigil-mainnet-1 \
  --retain-finalized-blocks 100000
Mainnet RPC pods use the same contract through k8s/mainnet/30-rpc-service.yaml: the ConfigMap supplies state-sync-mode and snapshot-base-url, and the container passes those values as explicit node arguments.

​
State-sync modes

ModeBehaviour
snapshot-then-p2p-catchupRestore the latest finalised snapshot, then fetch headers/blocks from peers. Default.
header-then-state-fetchFuture Merkle-proof state-fetch path. Reserved; production remains on snapshot-restore until the peer state-proof service is enabled.

​
Bandwidth controls

Snapshot endpoints are Cloudflare-proxied and rate-limited per IP. Operators with bulk restore needs can request a signed temporary allowlist token from operator-support.sigil.ml.

​
See also