BlockDAG chain snapshots

Available snapshots

The block numbers come from the manifest the node writes into the archive (DATASET-MANIFEST.json). The data itself can run a few minutes past that point; your node continues from wherever it actually ends.

You need free disk space for the archive plus about the same again for the unpacked data, and room for your old data until you delete it.

Step 1: Verify the download

Before unpacking anything, compare the file's SHA-256 with the one listed above. It must match exactly, every character. If it doesn't, the download is damaged or isn't the file published here: download it again, and don't use it.

The commands below are filled in for the latest snapshot. For another one, change the file name and paste its checksum. Run them in the folder you downloaded to. On a file this size each one takes a few minutes.

Linux

echo "7120ef733495f18f9f8562ce9d169d09aa4d5240508cc19464751c9d2b9a3681  blockdag-snapshot-20260927.tar" | sha256sum -c -

Expected output: blockdag-snapshot-20260927.tar: OK.

macOS

echo "7120ef733495f18f9f8562ce9d169d09aa4d5240508cc19464751c9d2b9a3681  blockdag-snapshot-20260927.tar" | shasum -a 256 -c -

Expected output: blockdag-snapshot-20260927.tar: OK.

Windows (PowerShell)

(Get-FileHash .\blockdag-snapshot-20260927.tar -Algorithm SHA256).Hash.ToLower() -eq "7120ef733495f18f9f8562ce9d169d09aa4d5240508cc19464751c9d2b9a3681"

Expected output: True.

Step 2: Put it in your node

The archive holds the contents of a node's node-data/mainnet folder. You replace your chain data with it and keep your node's own identity:

• network.key: your node's network identity
• peerstore/ and recent-peers.json: the peers your node knows
• bdageth/nodekey and keystore/, if you have them

The archive also contains the identity files of the node it was taken from. Don't use them: two nodes with the same identity on the network get in each other's way. The commands below skip them while unpacking and copy yours back.

1. Stop the node and wait until it has fully stopped. With Docker: sudo docker stop node (use your container's name). Unpacking into the folder of a running node corrupts its database.
2. Move your old data aside, unpack the snapshot into an empty node-data/mainnet, and copy your identity files back.
3. Start the node the usual way, for example sudo docker start node.
4. Once it is running and syncing, delete node-data/mainnet.old and the archive to get the space back.

If this is a brand new node with no node-data/mainnet yet, skip the move and the copy-back: the node creates its own identity on first start.

Linux

Run from the folder that contains node-data. Change the archive path to where you saved it.

sudo mv node-data/mainnet node-data/mainnet.old
sudo mkdir node-data/mainnet
sudo tar -xf ~/blockdag-snapshot-20260927.tar -C node-data/mainnet \
  --exclude=network.key --exclude=peerstore --exclude=recent-peers.json \
  --exclude=nodekey --exclude=keystore
for f in network.key peerstore recent-peers.json keystore bdageth/nodekey; do
  if [ -e "node-data/mainnet.old/$f" ]; then sudo cp -a "node-data/mainnet.old/$f" "node-data/mainnet/$f"; fi
done
sudo chown -R --reference=node-data/mainnet.old node-data/mainnet

The last line gives the new files the same owner as your old data, so the node can write to them.

Windows (PowerShell)

Run from the folder that contains node-data. tar is built into Windows 10 and 11.

Rename-Item node-data\mainnet mainnet.old
New-Item -ItemType Directory node-data\mainnet | Out-Null
tar -xf "$HOME\Downloads\blockdag-snapshot-20260927.tar" -C node-data\mainnet --exclude=network.key --exclude=peerstore --exclude=recent-peers.json --exclude=nodekey --exclude=keystore
foreach ($f in 'network.key', 'peerstore', 'recent-peers.json', 'keystore', 'bdageth\nodekey') {
  if (Test-Path "node-data\mainnet.old\$f") { Copy-Item "node-data\mainnet.old\$f" "node-data\mainnet\$f" -Recurse }
}

Step 3: Let it catch up

A snapshot stops at the moment it was taken. Everything produced after that, your node still downloads from its peers once it starts. For the latest snapshot (27 Sep 2026) that is less than a day of blocks. Your node is only up to date once it reaches the current block.

Right after the import, and after every restart, the node rebuilds its headers for 10 to 15 minutes. During that time it can look stuck or broken. That's normal: wait it out before you decide anything is wrong. The node guide shows what the logs look like.

To see how far along you are, ask your node for its block number:

curl -s -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  http://127.0.0.1:18545

The answer is hexadecimal; printf "%d\n" 0x… converts it. It should start near the EVM block listed above (22,581,159) and climb to the latest block on the DagCore explorer.