Validator Node-running and Token Incentives
Validator nodes are nodes that have registered to the Radix network to potentially be included in consensus on transactions. Each epoch (lasting approximately 2 hours), a set of 100 validator nodes are selected by the amount of stake delegated to them. This "validator set" conducts consensus for that full epoch.
In consensus, each validator is regularly called upon to propose new transactions from the mempool, with frequency weighted by their delegated stake. Validators also vote on transactions with voting weight based on delegated stake.
Validators are crucial infrastructure for the Radix network. Good validator nodes participate in consensus correctly, quickly, reliably – and draw delegators to stake XRD tokens to increase overall PoS-based security.
Therefore, to incentivize good validator node operation, the Radix protocol includes an incentive mechanism called "emissions". Each epoch, new XRD tokens are emitted and credited to good validator nodes and the delegators that have staked to them. Emissions thus provide an automatic financial incentive for decentralized network infrastructure.
On this page, we describe how to participate in this system as a validator node-runner.
Earning emissions XRD tokens as a validator node-runner is relatively simple, but the mechanisms and options are important to understand completely; errors here may easily result in no emissions received, and a loss of reputation with the Radix community.
In short, the primary way in which a validator node-runner receives emissions XRD tokens (other than choosing to stake their own XRD) is by specifying a "validator fee". This is a percentage that is taken by the validator node-runner from the total emissions otherwise due to all the validator node’s stakers at the end of each epoch.
There are four steps to operating a validator node that may produce incentive emissions XRD tokens via the validator fee:
Install and connect a full node: An Introduction to Radix Nodes
Maintain consistent near-100% uptime of your validator node: Maintaining High Validator Node Uptime
Being a successful and profitable validator node runner isn’t simply a matter of getting connected – steps 3 and 4 are especially important! Securing a "top 100" amount of delegated stake means building trust and communication with the Radix community. And part of building this trust is assuring the community that you can consistently provide the very high uptime required for them to receive emissions XRD by staking to your node.
Running a Radix validator node-runner should be seen as a significant commitment to operating a mature, stable, performant piece of server architecture – and embedding yourself as a pillar of the Radix community.
When you register, there are important options that you must set for your validator node. In addition to the name and info URL metadata that are provided for stakers, the following three options are also specified when you register your validator (and may be updated later). These options define your node’s relationship with stakers and if (and how) you will receive emissions via the validator fee.
A validator node-runner may set an
owner address for their validator node, which may be any Radix address. The
owner address has three purposes:
If the node-runner has set a validator fee (see below) greater than zero, then any resulting emissions XRD tokens will be credited to the
owneraddress (and automatically staked to the node from that address until unstaked).
allowDelegation(see below) is set to
falsefor the validator node, then only the owner address may delegate new stake to the node.
When a user queries information on a validator node ID (through the Radix Explorer, for example), the
owneraddress is provided, as is the amount of stake delegated from that address in particular.
owner address may be updated at any time. At the beginning of each epoch, the
owner address that will be credited with any validator fee emissions is set for that full epoch. However, the
allowDelegation restriction (see below) immediately applies to the latest
owner address, regardless of epoch changes.
By default, the
allowDelegation is a boolean flag that a validator may set for their validator node. The purpose of the flag is to specify who the node-runner wishes to accept delegated stake from.
truemeans that any Radix address may delegate stake to the node.
falsemeans that only the validator node’s specified
owneraddress may delegate new stake to the node; delegating from any other address is invalid.
By default, the
If a node-runner sets the flag to
false while existing stake is delegated to the node, that stake remains valid. The existing stake continues to be credited with emissions and contributes to the validator node’s selection for the validator set at each epoch. Only new delegated stake is halted.
Therefore, a validator node runner may choose to immediately set the flag to
false if they truly wish to only use their own stake. This is the case for validator nodes run by the Radix Foundation itself.
A validator node runner may start with it set to
true, but change it to false
false at a later time if they feel that their node has received more delegated stake than they are comfortable with, or to encourage stakers to delegate to other validators with less stake to benefit network security. We strongly discourage staking to nodes with more than 5% of total stake, so choosing to limit your own node’s stake in this way is encouraged good Radix citizen behavior.
If you wish to ensure no staking to your node other than your own, it is recommended to set the flag to
A validator node-runner may set a
validatorFee for their validator node, which is a decimal percentage between 0% and 100%. Setting the fee to 0% means the validator node takes none of the emissions fees earned by the node’s delegators.
validatorFee may be specified to up to two decimals of precision. For example:
2 ✔ 0.75 ✔ 0.1234 ✖ (The API will truncate this value to 0.12)
validatorFee is by default set to 100%. The node-runner may specify a new
validatorFee at any time, and the latest value will be immediately reflected in the validator ID information (and so will be visible on the Radix Explorer and Desktop Wallet). However, there are different rules for how the fee takes effect:
Lowering the validator fee will take effect at the beginning of the next epoch. Emissions will be split between validator and delegators based on the new value starting in that following epoch.
Raising the validator fee will initiate a delay, starting at the beginning of the next epoch. Once the delay period completes, emissions will then be split between validator and delegators based on the new value. Setting the validator fee to a value that is more than 10% higher, absolute, is invalid. For example:
2% ⟹ 10% ✔ (+8%) 2% ⟹ 12% ✔ (+10%) 2% ⟹ 13% ✖ (+11%)
The delay period is in epoch time, equal to approximately 2 weeks. If a change in fee is requested before the previous one has taken effect, it simply replaces that request. If the fee is being raised, this restarts the delay for it taking effect.