To avoid losing private keys, exposing private keys, or penalizing the validator, NEVER, UNDER ANY CONDITIONS, use blockchain mnemonics and mainnet configurations in testnet environments, and avoid setting up a test environment on a server running a mainnet validator.

1. Node configuration backup

It is necessary to make a backup copy of the existing configuration, usually it is the folder $HOME/.decimal/daemon/config

The private keys from the backup will be needed next.

2. Download, binary files installation 

The current preferred option is to download a binary for your linux distribution.

The compiled executable can be downloaded from


To download the binary you need to take the folder with the latest date and folder name (from all folders you need to choose the folder with the oldest block and the latest date it will be the folder with the current binary).

To install from source files you need to have go installed at least version 1.18, git

``` git clone [email protected]:decimalteam/go-smart-node.git cd go-smart-node git checkout master make install ```

And for testnet:

``` git clone [email protected]:decimalteam/go-smart-node.git cd go-smart-node git checkout staging # switch to branch for testnet make install ```

3.  Initialization

It is necessary to initialize the local configuration of the node with the command

`dscd init <MONIKER> --chain-id <CHAINID>`
  • MONIKER - some arbitrary node identifier chosen by the node creator
  • CHAINID - blockchain identifier, taken from the genesis (field `chain_id`)

After executing the command, node configuration files will appear in the `$HOME/.decimal/daemon/config` folder:

  • app.toml, config.toml - node configuration as a service
  • genesis.json - empty genesis by default
  • node_key.json - private key for data exchange between nodes
  • priv_validator_key.json - private and public keys of the node to work as a validator

The empty node genesis, i.e. $HOME/.decimal/daemon/config/genesis.json should be replaced with the downloaded genesis

The files node_key.json, priv_validator_key.json must be copied from the backup to the DSC configuration

You need to check and adjust the node parameters

  • in config.toml must have the following values
    ​​- timeout_commit = "5s" - for the correct generation of empty blocks when working as a validator
    - create_empty_blocks = true - for correct generation of empty blocks when working as a validator
    - create_empty_blocks_interval = "0s"
    - persistent_peers = "..." - for proper connection to existing validators (... - exact list is going to be provided on December 14, 2022 in Validators Telegram chat)

For testnet:

persistent_peers = "[email protected]:26656" - for correct connection to existing validators


seeds = ","

Attention! If there is a Decimal node configuration that was previously connected to the testnet, then this node can be restored: you need to copy the node_key.json, priv_validator_key.json files to the DSC node configuration to activate such a node, the mnemonic that was previously used in the Decimal testnet.

!!! After launch, pay attention to the balances, they should be the same as in the previous blockchain. 

4.Genesis download, blockchain replica

Genesis for mainnet should be downloaded in a zip or tar.xz archive, which are available at

For testnet, genesis should be downloaded with the following command (requires curl and jq installed) and saved as `genesis.json` (testnet genesis)

`curl "" | jq '.result.genesis' > genesis.json`

Download a fresh snapshot of the blockchain, example command:

rsync -avPh rsync:// /home/centos/.decimal/daemon/data/ --delete

5. Launch

Performed by the

`dscd start` command.

If the configuration is correct, node state synchronization will start: a fast stream of messages like

` :54AM INF received proposal module=consensus proposal={"Type":32,"block_id":{"hash":"1E0E7A42F373C313CDB2CFEFFD439CE2F58ADD823459038DAEC074FFDD617BDD ","parts":{"hash":"90B658BA659BEFDDAB189C6F28A56954CB12864EE6DD9B66FC1B5FEAB7F4BC85","total":1}},"height":409,"pol_round":-1,"round":0,"signature":"ket6zcb/+ Mfhv23oGE3+FVQIs8jh4zg2cfg6cWFCf8vF+UkbGthiFeIWMXF5IpjEGbixlWN2uXKOL1VmK+wtCQ==","timestamp":"2022-11-25T02:54:36.860957321Z"} server=node 9:54AM INF received complete proposal block hash=1E0E7A42F373C313CDB2CFEFFD439CE2F58ADD823459038DAEC074FFDD617BDD height=409 module=consensus server= node 9:54AM INF finalizing commit of block hash={} height=409 module=consensus num_txs=0 root=02D456451AA48CD3F35427DBEDD4E9F1344391BE5BFF0D6C541675AC2C051477 server=node AM INF burned tokens from module account amount= from=fee_bankcollector module=x 9:54INF minted coins from module account amount= from=fee_collector module=x/bank 9:54AM INF minted coins from module account amount=50000000000000000000del from=validator module=x/bank 9:54AM INF executed block height=409 module=state num_invalid_txs= 0 num_valid_txs=0 server=node 9:54AM INF commit synced commit=436F6D6D697449447B5B31323920383620313636203537203133312031343620313335203136312036302032323720363220313234203139302032353020313338203134203135332032343320313535203233352032353320313332203531203333203434203233382038382037382031333220323033203430203130335D3A3139397D `

When syncing is finished the messages above appear once in 5 sec (approx.) 

6. Registering a node as a validator

This item is only for new validators.

  1. Receive a node public key

From priv_validator_key.json you need to take public key bytes, base64 encoded .

This can be done with

`cat $HOME/.decimal/daemon/config/priv_validator_key.json | jq --raw-output '.pub_key.value'`
  1. Create validator candidate via console using your mnemonic, go to "Masternode" section

( - testnet)

Go through dialogue steps, you will need a public key, node ID. The creator of the node must have some initial supply of coins to delegate the first stake of the node.

At the end of the dialogue, you will need to confirm the transaction for creating the validator.

After the successful completion of the transaction, the node will appear in the list of candidates.

( - testnet)

7. Node Activation/Deactivation

Activation of a node is the procedure for declaring a node as a validator. The node has an obligation to create and sign blocks, in case of missing blocks (more than 12 within 24 blocks range) or double block signing, the stakes of the node will be fined by 1% and 5%, respectively.

For work as a validator on the reward address of the node, a reward is awarded.

Activation can be done either through the console, the "Masternode" tab, or through the cli `dscd tx validator set-online` (requires connection to a running node).

Deactivation - exclusion from the list of validators - can also be done through the console, the "Masternode" tab, or through the cli `dscd tx validator set-offline` (requires connection to a running node).

Systemd file

To manage the node service, you can use the dscd.serivce file of the following form

[Unit] Description=Decimal Smart Chain Node daemon Documentation= [Service] Type=idle User=centos ExecStart=/home/centos/decimal/dscd start Restart=always RestartSec=30s StandardOutput=journal StandardError=journal SyslogIdentifier=DSCD [Install]

Path ExecStart=/home/centos/decimal/dscd needs to be replaced with the one where the binary file of the node is.