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 (preliminary)

The purpose of this preliminary instruction is to give the community an understanding of the process of launching your own validator in the Smartlands Network, the complexity of the task and tech skills required. Basically not much, and 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

4. Install Smartlands Network Validator  image

Smartlands will publish a docker image with prepared validator and all necessary tools available on the Docker Hub, so it will be as easy as running a  single command in the console.

5. Generate a master keypair of validator owner.

To generate your validator owner keypair (don’t forget to store your seed phrase safely and securely!) you will only have to run a single command in the console.

Transfer your SLT (not less than 1000 testnet SLT) to the public key of the validator (keypair generated in the cloud).

6. Create a validator and delegate tokens.

Creation of a validator again is a single console command to create validator and delegate initial stake.

7. Launch validator

Launching your validator would be as simple as running “docker run smartlands-network” command in the console.


Your validator is up and running in the cloud and participating in the proof-of-stake consensus securing the Smartlands Network 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.