Run a Validator Node
Create a validator from running node
Prerequisites
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.
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.
The Validators set is defined in the staking
module. It is first formed using the initial validators from the genesis file. 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.
Joining Validator Set
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.
As you can see here the message includes amongst others the commission validator will be charging delegators. Let’s describe the commission rate fields:
rate
: the commission rate charged to delegators, as a fraction. For example, if the validator charges 10% then this value would be 0.1max_rate
: defines the maximum commission rate that which validator can ever charge, as a fraction. Each validator can send MsgEditValidator to update the commission rate (at most once within 24 hours). Themax_rate
will make sure that the new rate does not exceed this value.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.
At this point, it’s worth mentioning that rewards and commissions are not automatically distributed. Validators and delegators should use the delegation module.
Check the logs of your node and make sure that it is synced with the latest block. Avoid sending the create-validator transaction if the node is not fully synced. In any other case, you risk your validator getting jailed and part of the staked amount being slashed.
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 staked1000000000uslf
which is1000slf
.--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--from
: The public key or a key name that we used when we created the operation key.
It's recommended to create a validator with a small amount of SLF token first, then verify things. Then you can delegate more tokens later. This will prevent unexpected issues leading to losing tokens.
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 here
Delegate tokens to a validator
To find validator_operation_address, visit the validator page on Self Chain Explorer.
amount
: This is the total amount we’re willing to delegate. Here we staked 1000000000uslf
which is 1000slf
.
Delegation can be done with our staking application.
Slashing
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.
Unjail
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 unjail.
Edit Validator Details
To update the Validator avatar and public description on Explorer, you will need to create a keybase.io account and generate a 64-bit digit string that helps the Explorer retrieve the Keybase avatar. Then Run:
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.
Validator Commission
What is the Validator Commission?
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:
If the flag --commission
is removed, you will claim only the delegator rewards.
Last updated