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.

Before proceeding, we strongly recommend reading the Staking and Incentive Rewards Guide for more about how staking and emissions work and how these rewards are calculated.

Also, see for more general questions and answers.

How to Earn Emissions 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:

  1. Install and connect a full node: An Introduction to Radix Nodes

  2. Register the node as a validator, and set its node metadata and validator fee options: CLI method, Docker method, systemd method

  3. Secure sufficient delegated stake to reach the top-100 validator nodes by stake: What is Radix staking?, How to choose validators to stake to?

  4. 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.

Important Validator Node Options

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.

owner Address

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 owner address (and automatically staked to the node from that address until unstaked).

  • If allowDelegation (see below) is set to false for 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 owner address is provided, as is the amount of stake delegated from that address in particular.

The 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 owner address is set to the node’s own internal “wallet” address, but it is strongly encouraged to specify another address, such as one created in the Radix Desktop Wallet. This is good security practice, separating your node’s key from the key protecting an address used to hold or stake meaningful quantities of tokens.

allowDelegation Flag

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.

  • Setting allowDelegation to true means that any Radix address may delegate stake to the node.

  • Setting allowDelegation to false means that only the validator node’s specified owner address may delegate new stake to the node; delegating from any other address is invalid.

By default, the AllowDelegation flag is set to false when a node is first registered.

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 false immediately at the time of first registration as a validator. If it is not set, the default is true, allowing any address to delegate stake to the node.

validatorFee Percentage

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.

The 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)

The 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.