Validator Rewards

Running a validator node on the Tangle Network allows you to connect to the network, sync with a bootnode, obtain local access to RPC endpoints, and also author blocks. The network rewards successful validators (users running validator nodes and actively producing blocks) by paying a set amount of network tokens as rewards.

How Rewards are Calculated

Era Points

For every era (a period of time approximately 6 hours in length in Tangle), validators are paid proportionally to the amount of era points they have collected. Era points are reward points earned for payable actions like:

• producing a non-uncle block in the Chain.
• producing a reference to a previously unreferenced uncle block.
• producing a referenced uncle block.

An uncle block is a block that is valid in every regard, but which failed to become canonical. This can happen when two or more validators are block producers in a single slot, and the block produced by one validator reaches the next block producer before the others. We call the lagging blocks uncle blocks.

Payments occur at the end of every era.

Era points create a probabilistic component for staking rewards.

If the mean of staking rewards is the average rewards per era, then the variance is the variability from the average staking rewards. The exact TNT value of each era point is not known in advance since it depends on the total number of points earned by all validators in a given era. This is designed this way so that the total payout per era depends on Tangle's inflation model, and not on the number of payable actions (f.e., authoring a new block) executed.

In this case, analyzing the expected value of staking rewards will paint a better picture as the weight of era points of validators and para-validators in the reward average are taken into consideration.

High-level breakdown of reward variance

This should only serve as a high-level overview of the probabilistic nature for staking rewards.

Let:

• pe = para-validator era points,
• ne = non-para-validator era points,
• EV = expected value of staking rewards,

Then, EV(pe) has more influence on the EV than EV(ne).

Since EV(pe) has a more weighted probability on the EV, the increase in variance against the EV becomes apparent between the different validator pools (aka. validators in the active set and the ones chosen to para-validate).

Also, let:

• v = the variance of staking rewards,
• p = number of para-validators,
• w = number validators in the active set,
• e = era,

Then, v ↑ if w ↑, as this reduces p : w, with respect to e.

Increased v is expected, and initially keeping p ↓ using the same para-validator set for all parachains ensures availability and approval voting. In addition, despite v ↑ on an e to e basis, over time, the amount of rewards each validator receives will equal out based on the continuous selection of para-validators.

Payout Scheme

No matter how much total stake is behind a validator, all validators split the block authoring payout essentially equally. The payout of a specific validator, however, may differ based on era points, as described above. Although there is a probabilistic component to receiving era points, and they may be impacted slightly depending on factors such as network connectivity, well-behaving validators should generally average out to having similar era point totals over a large number of eras.

Validators may also receive "tips" from senders as an incentive to include transactions in their produced blocks. Validators will receive 100% of these tips directly.

For simplicity, the examples below will assume all validators have the same amount of era points, and received no tips.

Validator Set Size (v): 4
Validator 1 Stake (v1): 18 tokens
Validator 2 Stake (v2):  9 tokens
Validator 3 Stake (v3):  8 tokens
Validator 4 Stake (v4):  7 tokens
Payout (p): 8 TNT

Payout for each validator (v1 - v4):
p / v = 8 / 4 = 2 tokens

Note that this is different than most other Proof-of-Stake systems such as Cosmos. As long as a validator is in the validator set, it will receive the same block reward as every other validator. Validator v1, who had 18 tokens staked, received the same reward (2 tokens) in this era as v4 who had only 7 tokens staked.

Slashing

Although rewards are paid equally, slashes are relative to a validator's stake. Therefore, if you do have enough TNT to run multiple validators, it is in your best interest to do so. A slash of 30% will, of course, be more TNT for a validator with 18 TNT staked than one with 9 TNT staked.

Running multiple validators does not absolve you of the consequences of misbehavior. Polkadot punishes attacks that appear coordinated more severely than individual attacks. You should not, for example, run multiple validators hosted on the same infrastructure. A proper multi-validator configuration would ensure that they do not fail simultaneously.

Nominators have the incentive to nominate the lowest-staked validator, as this will result in the lowest risk and highest reward. This is due to the fact that while their vulnerability to slashing remains the same (since it is percentage-based), their rewards are higher since they will be a higher proportion of the total stake allocated to that validator.

To clarify this, let us imagine two validators, v1 and v2. Assume both are in the active set, have commission set to 0%, and are well-behaved. The only difference is that v1 has 90 TNT nominating it and v2 only has 10. If you nominate v1, it now has 90 + 10 = 100 TNT, and you will get 10% of the staking rewards for the next era. If you nominate v2, it now has 10 + 10 = 20 TNT nominating it, and you will get 50% of the staking rewards for the next era. In actuality, it would be quite rare to see such a large difference between the stake of validators, but the same principle holds even for smaller differences. If there is a 10% slash of either validator, then you will lose 1 TNT in each case.