Quicksync and State-sync

This tutorial provides step-by-step instructions for using Quicksync and State-sync to synchronize the Cronos blockchain network. Cronos users can download the snapshots for the Cronos Chain with different pruning settings from the Chainlayer QuickSync Cronos page to make the syncing process more efficient. The Quicksync process includes downloading and extracting the preferred pruning settings, and decompressing and syncing with Quicksync. On the other hand, State-sync is the fastest way to sync a node to the latest block-height, where the node downloads a data snapshot near the head of the chain and verifies this data. State-sync is suitable for users who want to join the network quickly, but it is not recommended for users who want to query the entire history of the chain. This tutorial provides pre-requisites and step-by-step instructions for using Quicksync and State-sync on Cronos.


IMPORTANT: In order to use Quicksync you need to first complete Step 3-2 and run /cronosd start

Syncing Cronos could be a time-consuming process, that’s why the Chain team has partnered with Chainlayer to provide the “Quicksync” service and make the process more efficient for our users.

Users can visit Chainlayer QuickSync Cronos page and download the snapshots for Cronos Chain with different pruning settings.

Step 1: Quicksync Download

After executing the command ./cronosd start at Step 3-2 Run everything, it starts the node and syncs the blockchain data. When you see it starts to sync from 0, you can terminate the terminal.

Users can visit Chainlayer QuickSync Cronos page and download the snapshots for Cronos Chain with different pruning settings. Both RocksDB and LevelDB snapshots are now available for Cronos Chain.

Step 2: Quicksync Extract

To start with Quicksync, you need to run brew install lz4 to install lz4 in a new terminal. Then download the file with preferred pruning settings directly from Quicksync.


  • Pruned snapshot is the quickest way to get a node running. If you just would like to give it a shot, use it for a validator or sentry node, the pruned snapshot will be a good choice. Pruned snapshots have tx index disabled to save disk/download size, which also will make API queries not work backward in time. If you still want to use a pruned snapshot to start an API node, then you can enable tx index on your end to start indexing blocks from when you startup your node. But you will not be able to query anything earlier than that.


  • Default is a good middle choice between everything. It will work in most use cases, validator, sentry node, API nodes. It has tx index enabled, so you can query block back in time. The only thing that default nodes do not have is the full history from the start of the chain or chain upgrade.


  • For the users who would like to query the old block, you may pick the archive one for complete blockchain data. The archive node will have all the blocks from the chain start or chain upgrade with full indexing. So this is a good option for API nodes if you need to have access to the whole chain history. Archives grow fast in size and might be more sluggish to run, so if you need something simpler default or a pruned kickstarted API node might solve most of the needs out there.

Step 3: Quicksync Setup

In the following steps, we will take as an example the version cronosmainnet_25-1-pruned.20220309.2010.tar.lz4.

  • (Optional) you can download an addressbook to get connected to peers faster. After downloading it, place the new addrbook.json under .cronos/config folder and restart your node to take effect.

  • Now add the cronosmainnet_25-1-pruned.20220309.2010.tar.lz4 inside .cronos

Then perform the following steps:

  • Change the path under .cronos with cd .cronos

  • Decompress with lz4 and tar by lz4 -d /Users/<username>/.cronos/cronosmainnet_25-1-pruned.20220308.2010.tar.lz4 | tar -xv, as below:

Example: Decompress the QuickSync pack with lz4

x data/
x data/application.db/
x data/application.db/84856034.ldb
x data/application.db/83264153.ldb
x data/snapshots/metadata.db/CURRENT.bak
x data/snapshots/metadata.db/MANIFEST-000107
x data/snapshots/metadata.db/LOG


The original data folder under .cronos is overwritten with this step (it takes around 5-7 mins to decompress the pruned version ~50GB).

Step 4: Sync with Quicksync

Example: Restart cronosd start with QuickSync

$ ./cronosd start
6:59PM INF Unlocking keyring
6:59PM INF starting ABCI with Tendermint
6:59PM INF Starting multiAppConn service impl=multiAppConn module=proxy server=node
6:59PM INF Starting localClient service connection=query impl=localClient module=abci-client server=node
6:59PM INF ABCI Replay Blocks appHeight=1813707 module=consensus server=node stateHeight=1813707 storeHeight=1813707


State-sync Pre-requisites

Supported OS

Linux x86_64 is confirmed to work. Other platforms may work but there is no guarantee. We will extend our support to other operating systems after we have stabilised our current architecture.

Prepare your machine

To run Cronos Mainnet nodes, you will need a machine with the following minimum requirements:

  • 4-core, x86_64 / ARM architecture processor

  • 16 GB RAM

  • 1 TB of storage space.


The fastest way to get a node synced to the latest block-height, is by using State-sync. With state-sync your node downloads a data snapshot near the head of the chain and verifies this data. This leads to drastically shorter times to join the network.

Keep in mind that the blocks before state-sync trust height will not be queryable. So, in order to run a full node, it is better not to use state-sync, but use Quicksync‘s archive snapshot instead.


State-sync depends on the ability to pull a snapshot from its persistent-peers, so there is some amount of timing and luck involved with this method. Although it is the fastest way, it is not always going to work, in case state-sync is not syncing, we recommend to use quicksync, although it takes longer time to download the snapshot, this method is more guaranteed to work.

Step 1. Get the latest cronosd binary

The latest Cronosd version release is cronosd v0.8.0

  • Install the Cronos Mainnet binaries from github:

curl -LOJ
tar -zxvf cronos_0.8.0_Linux_x86_64.tar.gz


  • Check that cronosd is effectively installed:

./bin/cronosd version 


Step 2. Configure cronosd

  • Initialize cronosd. Replace the [moniker] with an ID for your node.

./bin/cronosd init [moniker] --chain-id cronosmainnet_25-1


  • Download and replace the Cronos Mainnet genesis.json by:

curl > ~/.cronos/config/genesis.json


  • Verify the sha256sum checksum of thegenesis.json. You should see OK! if the sha256sum checksum matches.

if [[ $(sha256sum ~/.cronos/config/genesis.json | awk '{print $1}') = "58f17545056267f57a2d95f4c9c00ac1d689a580e220c5d4de96570fbbc832e1" ]]; then echo "OK"; else echo "MISMATCHED"; fi; 


  • Replace the following parameters in the ~/.cronos/config/config.toml file, by executing:

LATEST_HEIGHT=$(curl -s | jq -r .result.block.header.height); \
TRUST_HASH=$(curl -s "$BLOCK_HEIGHT" | jq -r .result.block_id.hash)

sed -i.bak -E "s|^(enable[[:space:]]+=[[:space:]]+).*$|\1true| ; \
s|^(rpc_servers[[:space:]]+=[[:space:]]+).*$|\1\",\"| ; \
s|^(trust_height[[:space:]]+=[[:space:]]+).*$|\1$BLOCK_HEIGHT| ; \
s|^(trust_hash[[:space:]]+=[[:space:]]+).*$|\1\"$TRUST_HASH\"| ; \
s|^(persistent_peers[[:space:]]+=[[:space:]]+).*$|\1\",,,\"| ; \
s|^(seeds[[:space:]]+=[[:space:]]+).*$|\1\"\"|" ~/.cronos/config/config.toml


Step 3. Run everything

  • Now that cronosd has been configured, we are ready to start the node:

./bin/cronosd start

1:40AM INF Unlocking keyring
1:40AM INF starting ABCI with Tendermint
1:40AM INF service start impl=multiAppConn module=proxy msg={} server=node
1:40AM INF service start connection=query impl=localClient module=abci-client msg={} server=node
1:40AM INF service start connection=snapshot impl=localClient module=abci-client msg={} server=node
1:40AM INF service start connection=mempool impl=localClient module=abci-client msg={} server=node
1:40AM INF service start connection=consensus impl=localClient module=abci-client msg={} server=node
1:40AM INF service start impl=EventBus module=events msg={} server=node
1:40AM INF service start impl=PubSub module=pubsub msg={} server=node
1:40AM INF service start impl=IndexerService module=txindex msg={} server=node
1:40AM INF Version info block=11 p2p=8 server=node tendermint_version=0.34.20
1:40AM INF This node is not a validator addr=DB03363D854BA491F280177BE33DE527F7542094 module=consensus pubKey=/L3Qe1oaNfrDael3QAmILSz5bLre9NAmKd48wd4eW8w= server=node
1:40AM INF P2P Node ID ID=d799c596250f27b5435775fdabb86d469dc5a784 file=/home/ubuntu/.cronos/config/node_key.json module=p2p server=node
1:40AM INF Adding persistent peers


This will take a couple of minutes, if your node manages to state-sync, you should see that snapshot chunks are being downloaded, and your node starts signing blocks.

To check the current node syncing status:

./bin/cronosd status 2>&1 | jq '.SyncInfo.catching_up'


That’s it! You are now running a synced node on Cronos Mainnet!