Run a Validator Node
Create a validator from running node
Last updated
Create a validator from running node
Last updated
Ensure that you have a full node setup and synced.
To check on the status of syncing:
This will give output like this:
The main thing to watch is that the block height is increasing. Once you are caught up with the chain, catching_up will become false. At that point, you can start using your node to create a validator.
At this point, we’ve managed to deploy and start the node. Once the node is fully synced, we can use the CLI tool to turn our Node into a Validator Node.
A validator is created using the [MsgCreateValidator](<https://docs.cosmos.network/v0.47/modules/staking#msgcreatevalidator>) message. The validator must be created with an initial delegation from the operator.
rate: the commission rate charged to delegators, as a fraction. For example, if the validator charges 10% then this value would be 0.1
max_change_rate: max_change_rate defines the maximum daily increase of the validator commission, as a fraction. For example, we can say that when a validator updates the rate then the new rate cannot be, let’s say 20% higher than the previous rate.
To join the validator set we simply send a transaction to the blockchain using the operation key we created above. Note that the operator account (i.e --from) must have sufficient uslf balance to cover the staked amount, as well as, the gas cost.
Let’s describe the most important parameters:
--amount: This is the total amount we’re willing to stake. In reality, what we do is we use the operator key to delegate to our validator. Here we staked 1000000000uslf which is 1000slf.
--node: This is the RPC URL of a full node. We can use the address of our node, as well.
--moniker: The same moniker we used when we initialized the chain. This is the name of the validator that will be shown on the explorer.
--min-self-delegation: The minimum amount of SLFs the validator candidate need to have bonded at all time. Check the section below for details
amount: This is the total amount we’re willing to delegate. Here we staked 1000000000uslf which is 1000slf.
Check the slashing params by running:
This says if you miss 95% (1-min_signed_per_window) of any 100-block window (signed_blocks_window), you will be slashed 0.01% (slash_fraction_downtime).
Basically, if you’ll be offline for 95 blocks then you will be slashed.
new-moniker: The validator's new name (default "[do-not-modify]", remove this flag if you don't want to change the validator name.
identity: The (optional) identity signature (ex. UPort or Keybase).
details: The public validator description.
Revenue received by a validator's pool is split between the validator and their delegators. The validator can apply a commission on the part of the revenue that goes to their delegators. This commission is set as a percentage. Each validator is free to set their initial commission, maximum daily commission change rate, and maximum commission.
Validator commission can be queried with the following API:
For validators, who want to withdraw the commission rewards, run:
The Validators set is defined in the staking module. It is first formed using the initial validators from the . However, this is a dynamic set meaning that new validators can decide to join the set by staking an amount and existing ones can decide to leave.
As you can see the message includes amongst others the commission validator will be charging delegators. Let’s describe the commission rate fields:
max_rate: defines the maximum commission rate that which validator can ever charge, as a fraction. Each validator can send to update the commission rate (at most once within 24 hours). The max_rate will make sure that the new rate does not exceed this value.
At this point, it’s worth mentioning that rewards and commissions are not automatically distributed. Validators and delegators should use the module.
--from: The public key or a key name that we used when we created the .
You might be wondering what is the min-self-delegation. It is basically, the minimum amount of SLFs the validator candidate need to have bonded at all time. If the validator's self-bonded stake falls below this limit, their entire staking pool (i.e. all its delegators) will unbond. This parameter exists as a safeguard for delegators. Indeed, when a validator misbehaves, part of their total stake gets slashed. This included the validator's self-delegated stake as well as their delegators' stake. Thus, a validator with a high amount of self-delegated Atoms has more skin in the game than a validator with a low amount. The minimum self-bond amount parameter guarantees to delegators that a validator will never fall below a certain amount of self-bonded stake, thereby ensuring a minimum level of skin in the game. This parameter can only be increased by the validator operator. More on this
To find validator_operation_address, visit the validator page on .
Delegation can be done with our .
If your validator has been jailed for any reason e.g. liveness checks failed, min self-delegation violated, etc. You can use the slashing module to .
To update the Validator avatar and public description on Explorer, you will need to create a account and generate a 64-bit digit string that helps the Explorer retrieve the Keybase avatar. Then Run: