Run a Validator


Every user of the Network is allowed to become a Validator of the Network, participating in maintaining consensus (producing and validating blocks) and network governance. The users who don’t run validators are incentivised to delegate their tokens (voting power) to reputable network validators. Thus users of the network ultimately determine the set of validators who will ensure the security of the network.

Delegation effectively freezes tokens on the users’ accounts – the value of these tokens will be added to the validator’s voting power, will entitle to the share of network rewards and will be accordingly put at risk, but validator will not be able to transact with these tokens.

The main incentive for running validators and delegating tokens is a block reward paid in the SLT token. Block reward includes fees collected from the transactions, as well as the SLT inflation – according to a schedule. Inflation is intended to incentivise the participation of users in the network governance, namely delegation of their tokens to validators.

In contrast with the blockchains with legacy protocols where the block reward is granted to the validator who first prepared the block, in Smartlands Network the block rewards will be accumulated in a special pool and then will be evenly distributed to validators according to their voting power.

Users who don’t delegate their tokens will suffer from SLT inflation. Validators are required to distribute the received rewards to their delegators, however, every validator will charge a fee from the delegators’ rewards. There are strict rules regulating how the validators determine and update their fee policy.

Operating the Validator requires resources to maintain the full-node: computing power and high-bandwidth internet connection. And network only requires a relatively small set of highly-connected and efficient validators – as otherwise the process of achieving the consensus will be not reliable and the performance of the blockchain will be affected.

We invite everyone willing to become a validator to get familiar with the requirements. If you have any questions, please contact us at, and we will be happy to help you.

The Computing Power

The answer to the questions about the computing power of servers required to run a node is not that simple. Running a node in DPoS consensus blockchain network is a responsible role and in case of a failure, you may be fined and additionally penalized based on the decision of other validators. Therefore insufficient computing power may result in losses, but excess computing power will also result in additional costs. The decision about computing power depends on the amount of staked SLT, risk preferences, current ledger history and network activity, updates that may increase the complexity of transactions. Given that some of the factors are constantly changing the decision must be revisited regularly to stay efficient. And don’t forget about safety considerations. If your validator is hacked, it may be used to attack the network. As a result, you will lose your staked tokens as a penalty for attack on the network or if the attack is successful, the value of your tokens is likely to go down to almost zero.

Once the production network will go live, Smartlands will update the community with recommendations on computing power for validators and timely inform about changes in the network that may cause any changes in requirements for the nodes.

If it is all too complicated for you, staking your tokens with another validator may be a good idea. Nevertheless, you should be extremely careful with choosing a validator, as mistake or willful wrongdoing of such validator will affect your SLT as well.

On the testnet, that will be launched soon, enthusiasts may start with minimal or recommended requirements for a validator of a network based on Cosmos SDK, that are as follows.


  • 1GB RAM
  • 25GB of disk space
  • 1.4 GHz CPU

AWS t3.micro, GCP f1-micro




  • 2GB RAM
  • 100GB SSD
  • x64 2.0 GHz 2v CPU

AWS t3.small, GCP g1-small


How to launch a validator on Smartlands Network (public testnet)

The purpose of this preliminary instruction is to allow prospective community validator operators to understand how to launch the node and operate the validator on the validator on the Smartlands Network public testnet. Basically the complexity of the task is moderate and not much tech skills required, thus a tech enthusiast should be capable to manage it.

1. Get your virtual server in the cloud.

We consider DigitalOcean to be one of the most user-friendly cloud server services, therefore it is used as an example in this instruction. 

In Digital Ocean the virtual servers are called “Droplets”, and here is the instruction to launch your very own one:


How to create Droplet (by DigitalOcean)

Please follow THIS link.

*If you’re not familiar with using SSH keys to connect to a cloud server, you can create a root password for the Droplet (step 9 in the instruction)

To join Smartlands Testnet, the very basic Droplet (as shown in the example, 2GB memory, 50GB storage – all for 10$ / month) will be sufficient.

2. Access the Droplet console

Once the Droplet is launched, you will need to access the console. Tech-savvy community members will prefer to connect to Droplet via SSH (HERE is the instruction for them).

But for the rest of the community there is the simpler way – to access the console via the web interface.

3. Install Docker

Once you have accessed your console, you should install Docker.
Docker is a very popular tool allowing you to launch preconfigured server-side applications (images) such as Smartlands Network validator.

HERE is the convenient instruction prepared by Digital Ocean – how to install Docker on  the  Droplet

Once the docker is installed,  you need to initialize a virtual network for your validator and console wallet. Run the following command:

> docker network create -d bridge smartlands-network-testnet

4. Install Smartlands Network Validator  image

Smartlands has published docker image with a prepared validator and all necessary toolset (console wallet, rest api) to the Docker Hub, so it is as easy as run a single command in the console to download the whole software stack required to operate the node.

Once you accessed the console of your virtual server, run the following commands:

> docker pull smartlands/validator:latest
> docker tag smartlands/validator:latest snapp

5. Initialize the node

Create necessary directories structure where the validator and console wallet files will be located:

> mkdir ~/snd
> mkdir ~/snapp

Initialize the new node with your chosen validator name:

> docker run -it -v ~/snd:/root/.snd snapp snd init <your unique validator name>

Then, you need to amend genesis file and configure the seed nodes for the testnet. The genesis file can be downloaded with the following commands:

> cd ~/snd/config
> curl > genesis.json

Seed nodes needs to be configured in the ~/snd/config/config.toml file manually (straight in the console you can use text editor called nano which is quite convenient).

Add the following main testnet seed node into the seeds property:

Smartlands will regularly update this list of seed nodes. It is also possible for a reliable validators to be included into the list

Also, in order to use console wallet in the different container, you will need to amend laddr property in the [rpc] section to the following valuee:


6. Launching the node

Once the genesis file is in place and the list of seeds is configured, you can start your node with a single command:

> docker run -dit --network=smartlands-network-testnet --name validator -v ~/snd:/root/.snd snapp snd start

Your own node is now running, connected to the Smartlands Network testnet in a “watcher” mode and performing necessary syncing operations to download the blockchain history.

7. Generate your wallet and claim your testnet SLT tokens

In the current bundle, Smartlands is providing the console wallet. By default, the keypair will be located locally in the ~/snapp directory and protected (encrypted) by the password.

To generate the keypair, launch a single command:

> docker run -it -v ~/sncli:/root/.sncli snapp sncli keys add validator-owner-wallet

The wallet will prompt you for a password and will show you the address and the seed phrase. Please write them down in a safe place.

In order to claim testnet SLT, at the current stage of the network development you will need to reach out to the team via address, explain your interest and we will transfer you testnet tokens promptly.

8. Become a validator

First, you need to obtain a public key of your watcher node that will become your validator private key

> docker run -it --network=smartlands-network-testnet -v ~/snd:/root/.snd snapp snd tendermint show-validator

In the console you will see the credentials of your node. Please copy the public address of the validator and use it in the next command.

Once you have enough tokens to create a validator, you need to create and sign a single blockchain transaction that will change your node status from watcher to validator.

> docker run -it --network=smartlands-network-testnet -v ~/sncli:/root/.sncli snapp sncli tx staking create-validator \
    --amount=10000000000slt \
    --pubkey=<validator public key> \
    --moniker="<your unique validator name>" \
    --chain-id=smartlands-testnet \
    --commission-rate="0.10" \
    --commission-max-rate="0.20" \
    --commission-max-change-rate="0.01" \
    --min-self-delegation="1" \
    --gas="auto" \
    --gas-adjustment="1.8" \
    --node="tcp://validator:26657" \

Sign the transaction by entering your wallet password.

Your node is a validator now and is participating in the proof of stake consensus.

9. Test the validator

Run the following command to see your validator in the active validators set (set of validators who are securing the network)

> docker run -it --network=smartlands-network-testnet -v ~/sncli:/root/.sncli snapp sncli query tendermint-validator-set \
    --chain-id="smartlands-testnet" --node="tcp://validator:26657"


Your validator is up and running in the cloud and participating in the proof-of-stake consensus securing the Smartlands Network Public Testnet Chain.


Community Questions on Running a Validator

Welcome to the successive portion of news about validators. Smartlands Network Team is thankful to all community members who expressed their interest in running a validator and came up with thousands of meaningful questions. So, let’s shed some light on those. For your convenience, we’ve decided to group your questions by the narrower topic.

Technicalities & Security

Most of you are probably aware of slashing, but a definition is in order nevertheless. Slashing is a mechanism built into blockchain protocols to discourage validator misbehaviour. The protocol determines a set of conditions which have to be met by validators. If any of the conditions are triggered, slashing penalties are imposed on validators. Managing a validator with a significant stake requires a strong security system to secure your SLT from slashing. If your validator is hacked and it runs malicious code that tries to hack the network, your stake will be slashed. Penalties are thought to be an effective deterrent against validator misconduct. Let us inform you of the slashing conditions for Smartlands Network:


  1. (causing the biggest slashing) – “double signing”, meaning validator intentionally or unintentionally trying to breach consensus and cause chain split;
  2. (causing the lower penalty) – failure to maintain a decent uptime. 

There is no appeal process. Uptime is the only KPI for validators. Please mind that the ability to handle network transactions volume impacts the uptime.

To recap, the key requirements (minimal or recommended) for a validator of a network based on Cosmos SDK were established as follows:


  • 1GB RAM
  • 25GB of disk space
  • 1.4 GHz CPU

AWS t3.micro, GCP f1-micro



  • 2GB RAM
  • 100GB SSD
  • x64 2.0 GHz 2v CPU

AWS t3.small, GCP g1-small


*applicable to the mainnet launch. When mainnet transaction volume increases, the requirements will substantially change.

It is totally fine to run a validator on the cloud as a permanent solution providing that a validator sticks to the above system recommendations. At present, there are no other restrictions, apart from the aforementioned requirements. Note that you won’t have to install anything on your laptop for this matter if you want to delegate your tokens. It’s also worth mentioning that there are service cloud providers enabling an individual to monitor your validator from your mobile device. With respect to the country of residence, anyone complying with the requirements is eligible to run a validator. If you think in favour of running multiple instances of validator, we see no obstacles on your way. However, you would need to hold a particular amount of SLT which equates to 1000 SLT/a validator. Validators don’t have to go the extra mile in terms of commitments. If a validator makes up their mind to shut down their account, they cease to get rewards. Delegators, on the other hand, will need to resort to another validator.

Subsequently, launching a validator requires some manual effort but running is automated. You will only have to update it manually.

If you stick to a delegator side (in our case – SLT holder), you should bear in mind certain criteria while choosing a validator to delegate your tokens to. You will need to take responsibility for checking the background of the validator based on their reputation, server setup, etc. Keep in mind that being a delegator is not an activity deprived from taking risks. Should a validator misbehave, delegators will be slashed respectively in proportion to the delegated stake. Delegators are to actively monitor the actions of their validators and participate in governance. It is not assumed that validators reject delegators.

Delegators don’t have to transfer their SLT to your account but only delegate SLT. If your validator is shut down, delegators will just stop getting rewards and will have to choose another validator.

As far as the ratios of validators to oracles concern, initially, there will be more validators, but when Smartlands Network becomes popular, there should be at least one Compliance oracle for each jurisdiction. Therefore, at a later stage, there should be more oracles than validators.

Some of you were wondering what sensitive info could be lost given that the machine is hacked. In reality, validator has its own separate account from the one that delegates the stake (even if you run your own validator). Consequently, if the server misbehaves, staked tokens will be slashed so you may lose your tokens without losing your private key.

There is plenty of documentation across the Internet regarding recommended validator configuration which relates to overall security. We will also publish guidelines close to the mainnet launch.

Testnet & Mainnet

What regards the quantity of validators Smartlands Network is looking for, we aim at partnering with 10 professional validators and those willing to run a validator from our friendly tech-savvy community. At the moment, we’re inviting everyone to join our testnet. Further, you’re welcome to come along to the mainnet. Equally important, a validator can join Smartlands Network on the mainnet exclusively. Much to our beliefs, with Smartlands Network rising popularity only more and more validators are expected.

For the first year of mainnet operations, the conservative estimate is to have 10-30 validators. You can run multiple validators if you are capable to maintain a sufficient stake for them, i.e. attract delegators.

For the initial testnet launch everybody will be able to claim tokens regardless of the purpose (e.g. it’s ok to claim test tokens to try out staking/running the validator).

The rewards won’t be bonded by default so validators could sell SLT to cover up operational expenses.


There are of course some rewards for becoming a validator. Smartlands token model is planned to be used for staking and network fees (e.g. fees paid to compliance oracles who will manage regulated assets). Special benefits in SLT are to be provided to the most active validators on the network. Besides, there will be an extra reward for early-bird validators. Not to mention the daily rewards for closing blocks. The reward distribution is also automated in the validator code.

Some might expect to break even after one year of running a validator. We’d say the situation will depend on many variables, including the stake of SLT. High inflation during the first year is a good start.


Wrapping it all up, there are clear risks for both parties, validators and delegators. The latter should be careful with opting the former. The former should be confident in their computing power and conscious of being compensated for their work respectively.

We plan on disclosing further details soon along with the elaborate tutorial.



We invite everyone willing to become a validator to get familiar with the requirements. If you have any questions, please contact us at, and we will be happy to help you.


NB! This material is provided to familiarize yourself with the basic requirements for running your own validator on the Smartlands Network testnet. Launching the node and running the validator will only be possible after the official launch of the Smartlands Network testnet. Please follow the announcements in the official Smartlands Network channels.