🤔 Need blocks and a snapshot? Use the bundle API to always get the latest compatible backups.

Mainnet Snapshots

Hourly snapshots of the EOS mainnet so you can instantly sync with the network.

Title Download Size MD5 Checksum
snap_2019-02-23-13-00.tar.gz Wasabi S3 320.85 MiB cd556c7a75a2a6a5242621743c47df1c
snap_2019-02-23-12-00.tar.gz Wasabi S3 320.68 MiB 0b0cd94b31028b3fe57ba4bfb76da6d4
snap_2019-02-23-11-00.tar.gz Wasabi S3 320.53 MiB fa6cfa4f5531108991c574488342373a
snap_2019-02-23-10-00.tar.gz Wasabi S3 320.31 MiB 3949728c83dee66c7d60730a280221a5
snap_2019-02-23-09-00.tar.gz Wasabi S3 320.42 MiB d62fe0de0725ad9bb7d0c9af2d3edd0b
snap_2019-02-23-08-00.tar.gz Wasabi S3 320.26 MiB 230b17aba749ebbdb1650d2b8f77a4b3
snap_2019-02-23-07-00.tar.gz Wasabi S3 319.94 MiB 96645c0c863936eaa7ddd8d2e35e07fd
snap_2019-02-23-06-00.tar.gz Wasabi S3 319.87 MiB 38fc1ad13df1a24001b2ebd59edd1795
snap_2019-02-23-05-00.tar.gz Wasabi S3 319.77 MiB 00d6242c56a6c867bfb1907811e86c89
snap_2019-02-23-04-00.tar.gz Wasabi S3 319.61 MiB c92cecb52f1668548c3f333df392d97a
snap_2019-02-23-03-00.tar.gz Wasabi S3 319.8 MiB f98ecbc140538ae9683d5dd45e377030
snap_2019-02-23-02-00.tar.gz Wasabi S3 319.63 MiB c3e443fe829942372f19e9dc9f18c0a7
snap_2019-02-23-01-00.tar.gz Wasabi S3 319.63 MiB 5625fa4d67f69717e1fb9919452961dd
snap_2019-02-23-00-00.tar.gz Wasabi S3 319.31 MiB 6318eb30b5eeb745c834503dd55e62db
snap_2019-02-22-23-00.tar.gz Wasabi S3 319.48 MiB 83c92f2ee6cce3ab17622955773867d1
snap_2019-02-22-22-00.tar.gz Wasabi S3 319.36 MiB d3def274ed7a496b3efe5452d6716077
snap_2019-02-22-21-00.tar.gz Wasabi S3 319.46 MiB 9b56fb97f27ccfcc87b2dbd1d0bdb03e
snap_2019-02-22-20-00.tar.gz Wasabi S3 319.7 MiB 242f10b3edff2ca1c621bc33dcf7b946
snap_2019-02-22-19-00.tar.gz Wasabi S3 319.5 MiB c6c97bf263f9d977b82ee792fa780846
snap_2019-02-22-17-00.tar.gz Wasabi S3 319.84 MiB 5bb0eecf9c078cf41fc84072ede42cb9
snap_2019-02-22-16-00.tar.gz Wasabi S3 319.89 MiB bf85d08a0144e21c92a1896c9507035c
snap_2019-02-22-15-00.tar.gz Wasabi S3 319.67 MiB bb7bd5439b393a6a2630919b272a97c4
snap_2019-02-22-14-00.tar.gz Wasabi S3 319.57 MiB 7a99c0977f6e70396f21b304a5e98d59
snap_2019-02-22-13-00.tar.gz Wasabi S3 319.63 MiB 878d5cf4a3db7943c59f0a685f8d79e5
snap_2019-02-22-12-00.tar.gz Wasabi S3 319.65 MiB cfaf5725f1c6bc3122f21d8e476ab7b4
snap_2019-02-22-11-00.tar.gz Wasabi S3 319.71 MiB 7e5d5c2e50f4bc2629959937f5b46b69
snap_2019-02-22-10-00.tar.gz Wasabi S3 319.27 MiB a4971064e71694935191c9c67bf0409c
snap_2019-02-22-09-00.tar.gz Wasabi S3 318.49 MiB 6fcca36b267f8e9f15c8953489ac22f3
snap_2019-02-22-08-00.tar.gz Wasabi S3 318.55 MiB 41d3c76a5bfd8253aefec6bdf0555d64
snap_2019-02-22-07-00.tar.gz Wasabi S3 318.7 MiB 80ae1fb0078e0ea16cc28397c1aeab2c
snap_2019-02-22-06-00.tar.gz Wasabi S3 318.44 MiB 39f3dc7581aa0356d662e3ecb5bc679a
snap_2019-02-22-05-00.tar.gz Wasabi S3 318.33 MiB 90a9bbf292f1af934e9225033db289c0
snap_2019-02-22-04-00.tar.gz Wasabi S3 318.08 MiB 4d6c915f752a2485520e29c771b3a87c
snap_2019-02-22-03-00.tar.gz Wasabi S3 318.09 MiB 571b1bc0c6df4642fdd365aebcfc4b14
snap_2019-02-22-02-00.tar.gz Wasabi S3 317.73 MiB 317b35793d7c899557f1dcdb59d05551
snap_2019-02-22-01-00.tar.gz Wasabi S3 317.76 MiB da8cf5de0eb0c26d9c9766392ea8ad5d
snap_2019-02-22-00-00.tar.gz Wasabi S3 317.67 MiB a6a00318c5b521b762cdaf7b185fb650

These snapshots are platform agnostic and taken from our own cluster of API nodes.
They can be used with or without a blocks log.

Using Snapshots

This is a great way to get synced to the network within a minute, you can see the original notes on Github. There are a couple of points to be aware of:

  • The snapshots contain all the consensus state required to bootstrap a node at a given head block, so there's no need for long replays to build state from the blocks log.
  • This sync method is intended for producing nodes, however if you don't intend on supporting history data, it will work perfectly for API/full nodes.

What's The Catch?

After being accustomed to long replay times via Block backups, the near instant snapshot sync seems like magic. But the magic comes at a cost:

  • If you want to support retrospective chain data via the RPC API or P2P, then you must provide a blocks log that contains blocks up to the snapshotted block. The blocks log may contain additional blocks, they will be applied as part of the startup process.
  • These snapshots do not support any plugins, so this doesn't support history data.

How To Use

First, you must do some preparation. Remove the state directory if it exists, then you need to make a decision. If you want to support old chain data, then you must have a blocks directory with a block log containing data up to, or past the head block referenced in the snapshot.

Download the snapshot, uncompress it and start nodeos with the snapshot flag pointing to the absolute location of the fresh snapshot.

The example assumes you have used our automation framework to install and configure the EOS application. It includes handy bash helpers to auto dameonise the nodeos process and capture all output into a single log file.

You can use the one-liner in the example to always download the latest snapshot. We also have a Snapshots API which orders the archives in chronological order, newest first.

# Move to your local eos directory, removing the existing state directory (if relevant)
cd /opt/mainnet
rm -rf state

# Download the latest snapshot
wget $(wget --quiet "https://eosnode.tools/api/snapshots?limit=1" -O- | jq -r '.data[0].s3') -O snapshot.tar.gz

# Uncompress
tar xvzf snapshot.tar.gz

# Start the chain and sync from the provided snapshot
./start.sh --snapshot "$(ls -t snapshots/*.bin | head -n1)"

# Tail the logs to watch the sync in all its glory
tail -f log.txt