Advanced Staking Concepts

New to Staking?

Start your staking journey or explore more information about staking on Polkadot's Home Page. Discover the new Staking Dashboard that makes staking much easier and check this extensive article list to help you get started. You can now stake on Kusama natively with just and earn staking rewards. For additional information, check out this blog post.

This page is meant to be an advanced guide to staking with Kusama. For a more general introduction, checkout the Introduction to Staking page.

Staking Proxies

Kusama makes it possible to create accounts having special permissions also called proxy accounts. For more details about proxy accounts visit the dedicated page on this wiki.

Proxy accounts are special accounts which can sign extrinsic calls made to specific pallets on behalf of the proxied account. There is thus the possibility to create staking proxy accounts that can be used to sign extrinsic calls specific to the staking, session and utility pallets.

Staking on Kusama is not a set-and-forget action, as a nominator you will need to monitor the performance of your validators and make changes if needed. There will be this transactions such as nominating that will be needed to regularly signed. Each time you sign with an account, in the case of hot accounts, you expose the private key of that account to the internet with consequent risk of attack. A hot stash will be exposed all the time a transaction is signed. Even in the case of a cold stash created with a Ledger device, signing with the stash will build a transaction history that might tell something about your habits and preferences, or even your location.

Ideally, accounts with high economic power like the stash must be and remain as isolated as possible. With a staking proxy, the stash account is fully isolated when signing for staking-related transactions. The proxy private key will be used to sign staking-related transactions, the stash private key will stay isolated and the staking transaction history will be built by the proxy.

For a practical perspective we need to use only one account and remember one password to sign for all staking-related transactions. From a security perspective who controls the staking proxy controls our staking actions.

It is important to remember that actions that can be performed by the proxy accounts are limited, and in the case of staking proxy, extrinsic calls to the balances pallet cannot be signed. This means it is not possible to do balance transfers on the proxied account through a staking proxy.

Note that to change the staking proxy you will need to sign with the stash or an any proxy.

Bags List

info

On Polkadot and Kusama, the instance of the pallet Bags-List is named as 'voterList'.

For a demo about bags list see this video tutorial.

In Kusama's NPoS nomination intents are placed in a semi-sorted list called bags-list. The bags list example below uses DOT for explaining the concepts. The Bags-List substrate pallet is designed to be self-maintaining, with minimal effort from the blockchain, making it extremely scalable. The bags list has two primary components, bags and nodes (or nominators' accounts), with bags containing the nodes with bonded balance within a specific range. In the figure below the 1st empty bag will contain nominators whose bonded balance is in the range of 21 - 30 DOT, the 2nd bag 11 - 20 DOT, and the 3rd bag 0-10 DOT. The nomination intents are the nominators' accounts with bonded tokens (in the example shown below, there are eight nomination intents) that will be put inside each of those three bags depending on their stake.

The bags list is semi-sorted, meaning that sorting is only partially done. When the nomination intents are submitted to the network, they are automatically put into each bag based on the number of bonded tokens, but within each bag, those nodes are arranged based on the time they are inserted and not based on their stake (see figure below). When the nomination intent of 19 DOT is submitted, it gets placed at the last spot in the 2nd bag (shown in the yellow circle). The same scenario applies for the node with 8 DOT (green circle) in the 3rd bag. Placing the node above all nodes with a lesser stake requires an additional step (more on this later).

The mentioned two nodes (19 DOT and 8 DOT) have the option to move up in their respective bags, which can put them in front of the nodes with less stake than them (see figure below). This action must be done manually by submitting the putInFrontOf extrinsic within the voterList pallet instance. Moreover, if the node with 19 DOT bonds an additional 2 DOT, that node will be put automatically in the 1st bag (i.e. automatic rebag) because the total number of bonded tokens will now be within the range of the 1st bag. That node with now 21 DOT will be put at the tail end of the 1st bag with the possibility to manually put itself in front of "older" nodes with less than 21 DOT (if there are any).

If one decides to send staking rewards to the stash account and automatically bond them (i.e. compounding the staking rewards), the position within a bag does not change automatically. The same scenario applies to a slashing event, i.e., when a nominator gets slashed, their position within a bag does not change. This might result in a scenario where the node is in the wrong bag and needs to be placed in the right bag. To address this issue, any account on-chain can submit the permissionless extrinsic rebag within the voterList pallet instance to update the positions of the nodes that do not belong to their bag and place them in the correct one. To reiterate, actions like bonding/unbonding tokens automatically rebag the nominator node, but events like staking rewards/slashing do not. See the bags-list section for more information.

The bags-list is capable of including an unlimited number of nodes, subject to the chain's runtime storage. In the current staking system configuration, the bags list keeps nomination intents, of which, at most 12500 come out as the electing nominators. See Staking Election Stages section for more info.

This means that only a portion of the nomination intents is kept. Once the nomination period ends, the NPoS election system takes all nomination intents and their associated votes as input, and it outputs a set of validators. The bags are iterated from the most staked to the least staked. If the accounts are not appropriately sorted, this could leave the last touched bag to only be partially iterated. Thus, in some edge cases, the order of the members within a bag is important. Continuing with the example used in the previous figures, there are 8 nomination intents of which only 7 will be kept. If the bags list stays semi-sorted (i.e. no accounts call the putInFrontOf and rebag extrinsics), the nomination of the node with 8 DOT in the 3rd bag will not be considered while that of the preceding node with 5 DOT will be. Nomination of the node with 8 DOT will be kept only if it puts itself in front of the one with 5 DOT. Note how the nomination of the node with 19 DOT in the 2nd bag will be considered regardless of changing its position inside the bag. The sorting functionality of nomination intents using bags is extremely important for the long-term improvements of the staking/election system.

Minimum active nomination threshold to earn rewards is dynamic

Submitting a nomination intent does not guarantee staking rewards. The stake of the top 12500 nominators is applied to the validators in the active set. To avail of staking rewards, ensure that the number of tokens bonded is higher than the minimum active bond. For more information, see the nominator guide.

The "election solution" which is a connected graph between nominators and validators with the stake as edge weights, has to meet certain requirements, such as maximizing the amount of stake to nominate validators and distributing the stake backing validators as evenly as possible. The objectives of this election mechanism are to maximize the security of the network, and achieve fair representation of the nominators. If you want to know more about how NPoS works (e.g. election, running time complexity, etc.), please read here.

Rewards Distribution

info

The general rule for rewards across validators is that two validators get paid essentially the same amount of tokens for equal work, i.e. they are not paid proportional to their total stakes. There is a probabilistic component to staking rewards in the form of era points and tips but these should average out over time.

Validators are paid the same regardless of stake backing them. Validators with less stake will generally pay more to nominators per-token than the ones with more stake. This gives nominators an economic incentive to gradually shift their preferences to lower-staked validators that gain a sufficient amount of reputation. A consequence of this is that the stake across validators will be as evenly distributed as possible which avoids concentration of power among a few validators. In the long term, validators will have similar levels of stake, with the stake being higher for validators with higher reputation. A nominator who is willing to risk more by backing a validator with a lower reputation will get paid more, provided there are no slashing events.

Before distributing rewards to nominators, validators can create a cut of the reward (a commission) that is not shared with the nominators. This cut is a percentage of the block reward, not an absolute value. After the commission gets deducted, the remaining portion is distributed pro-rata based on their staked value and split between the validator and all of the nominators whose stake has backed this validator.

For example, assume the block reward for a validator is 10 DOT. A validator may specify validator_commission = 50%, in which case the validator would receive 5 DOT. The remaining 5 DOT would then be split between the validator and their nominators based on the proportion of stake each nominator had. Note that for this calculation, validator's self-stake acts just as if they were another nominator.

Thus, a percentage of the reward goes thus to pay the validator's commission fees and the remainder is paid pro-rata (i.e. proportional to stake) to the nominators and validator. If a validator's commission is set to 100%, no tokens will be paid out to any of the nominators. Notice in particular that the validator is rewarded twice: once in commission fees for validating (if their commission rate is above 0%), and once for nominating itself with own stake.

The following example should clarify the above. For simplicity, we have the following assumptions:

• These validators do not have a stake of their own.
• They each receive the same number of era points.
• There are no tips for any transactions processed.
• They do NOT charge any commission fees.
• Total reward amount is 100 DOT tokens.
• The current minimum amount of DOT to be a validator is 350 (note that this is not the actual value, which fluctuates, but merely an assumption for purposes of this example; to understand how the actual minimal stake is calculated, see here).

	Validator A
Nominator (4)	Stake (600)	Fraction of the Total Stake	Rewards
Jin	100	0.167	16.7
Sam	50	0.083	8.3
Anson	250	0.417	41.7
Bobby	200	0.333	33.3

	Validator B
Nominator (4)	Stake (400)	Fraction of the Total Stake	Rewards
Alice	100	0.25	25
Peter	100	0.25	25
John	150	0.375	37.5
Kitty	50	0.125	12.5

Both validators A & B have 4 nominators with a total stake 600 and 400 respectively.

Based on the above rewards distribution, nominators of validator B get more rewards per DOT than those of validator A because A has more overall stake. Sam has staked 50 DOT with validator A, but he only gets 8.3 in return, whereas Kitty gets 12.5 with the same amount of stake.

To estimate how many tokens you can get each month as a nominator or validator, you can use this tool as a reference and play around with it by changing some parameters (e.g. how many days you would like to stake with your DOT, provider fees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accurate since staking participation is changing dynamically, it works well as an indicator.

Oversubscription, Commission Fees & Slashes

There is an additional factor to consider in terms of rewards. While there is no limit to the number of nominators a validator may have, a validator does have a limit to how many nominators to which it can pay rewards. In Kusama this limit is currently , although this can be modified via runtime upgrade. A validator with more than nominators is oversubscribed. When payouts occur, only the top nominators as measured by the amount of stake allocated to that validator will receive rewards. All other nominators are essentially "wasting" their stake - they used their nomination to elect that validator to the active stake, but receive no rewards in exchange for doing so.

Note that the network slashes a validator for a misbehavior (e.g. validator offline, equivocation, etc.) the slashed amount is a fixed percentage (and not a fixed amount), which means that validators with more stake get slashed more DOT. Again, this is done to provide nominators with an economic incentive to shift their preferences and back less popular validators whom they consider to be trustworthy.

Also, note that each validator candidate is free to name their desired commission fee (as a percentage of rewards) to cover operational costs. Since validators are paid the same, validators with lower commission fees pay more to nominators than validators with higher fees. Thus, each validator can choose between increasing their fees to earn more, or decreasing their fees to attract more nominators and increase their chances of being elected. In the long term, we expect that all validators will need to be cost-efficient to remain competitive, and that validators with higher reputation will be able to charge slightly higher commission fees (which is fair).

Slashing

Unresponsiveness

For every session, validators will send an "I'm online" heartbeat to indicate they are live. If a validator produces no blocks during an epoch and fails to send the heartbeat, it will be reported as unresponsive. Slashing may occur depending on the repeated offenses and how many other validators were unresponsive or offline during the epoch.

Validators should have a well-architected network infrastructure to ensure the node runs to reduce the risk of slashing or chilling. A high availability setup is desirable, preferably with backup nodes that kick in only once the original node is verifiably offline (to avoid double-signing and being slashed for equivocation - see below). A comprehensive guide on validator setup is available here.

Here is the formula for calculating slashing due to unresponsiveness:

Let x = offenders, n = total no. validators in the active set

min((3 * (x - (n / 10 + 1))) / n, 1) * 0.07

The examples demonstrate how to calculate the slashing penalty for unresponsiveness.

note

In all of the examples, assume that there are 100 validators in the active set.

No slashing would enact if <= 10% of all validators are unresponsive.

For example, if exactly 10 validators were unresponsive, the expression 3 (x - (n / 10 + 1))) / n would be 3 (10 - (100 / 10 + 1)) / 100 = 3 * (10 - (10 + 1)) / 100 = -0.03 which is rounded to 0.

note

The minimum value between 0 and 1 is 0. 0 multiplied by 0.07 is 0.

If 14 validators are unresponsive, then slashing would occur, as > 10% of validators are unresponsive.

The slashing penalty would be min((3 (14 - (100 / 10 + 1))) / 100, 1) 0.07 = min((3 (14 - 11))/100, 1) 0.07 = min(0.09, 1) * 0.07 = 0.6%

Similarly, if one-third of the validator set (around 33/100) are unresponsive, the slashing penalty would be about 5%.

The maximum slashing that can occur due to unresponsiveness is 7%. After around 45% of the validators go offline, the expression 3 (x - (n / 10 + 1))) / n will go beyond 1. Hence, min((3 (x - (n / 10 + 1))) / n, 1) * 0.07 will be ceiled to 7%.

Equivocation

GRANDPA Equivocation: A validator signs two or more votes in the same round on different chains.

BABE Equivocation: A validator produces two or more blocks on the Relay Chain in the same time slot.

Both GRANDPA and BABE equivocation use the same formula for calculating the slashing penalty:

Let x = offenders, n = total no. validators in the active set

min( (3 * x / n )^2, 1)

As an example, assume that there are 100 validators in the active set, and one of them equivocates in a slot (for our purposes, it does not matter whether it was a BABE or GRANDPA equivocation). This is unlikely to be an attack on the network, but much more likely to be a misconfiguration of a validator. The penalty would be min(3 * 1 / 100)^2, 1) = 0.0009, or a 0.09% slash for that validator (i.e., the stake held by the validator and its nominators).

Now assume that there is a group running several validators, and all of them have an issue in the same slot. The penalty would be min((3 * 5 / 100)^2, 1) = 0.0225, or a 2.25% slash. If 20 validators equivocate, this is a much more serious offense and possibly indicates a coordinated attack on the network, and so the slash will be much greater - min((3 * 20 / 100)^2, 1) = 0.36, or a 36% slash on all of these validators and their nominators. All slashed validators will also be chilled.

From the example above, the risk of nominating or running many validators in the active set are apparent. While rewards grow linearly (two validators will get you approximately twice as many staking rewards as one), slashing grows exponentially. A single validator equivocating causes a 0.09% slash, two validators equivocating does not cause a 0.09 * 2 = 0.18% slash, but rather a 0.36% slash - 4x as much as the single validator.

Validators may run their nodes on multiple machines to make sure they can still perform validation work in case one of their nodes goes down, but validator operators should be extremely careful in setting these up. If they do not have good coordination to manage signing machines, equivocation is possible, and equivocation offenses are slashed at much higher rates than equivalent offline offenses.

If a validator is reported for any one of the offenses they will be removed from the validator set (chilled) and they will not be paid while they are out. They will be considered inactive immediately and will lose their nominators. They need to re-issue intent to validate and again gather support from nominators.

Slashing Across Eras

There are 3 main difficulties to account for with slashing in NPoS:

• A nominator can nominate multiple validators and be slashed via any of them.
• Until slashed, the stake is reused from era to era. Nominating with N coins for E eras in a row does not mean you have N*E coins to be slashed - you've only ever had N.
• Slashable offenses can be found after the fact and out of order.

To balance this, we only slash for the maximum slash a participant can receive in some time period, rather than the sum. This ensures protection from overslashing. Likewise, the period over which maximum slashes are computed is finite and the validator is chilled with nominations withdrawn after a slashing event, as stated in the previous section. This prevents rage-quit attacks in which, once caught misbehaving, a participant deliberately misbehaves more because their slashing amount is already maxed out.

Simple Payouts

Kusama makes stakers claim their rewards for past eras by submitting a transaction. This naturally leads to spreading out reward distribution, as people make transactions at disparate times, rather than updating the accounts of all stakers in a single block.

Even if everyone submitted a reward claim at the same time, the fact that they are individual transactions would allow the block construction algorithm to process only a limited number per block and ensure that the network maintains a constant block time. If all rewards were sent out in one block, this could cause serious issues with the stability of the network.

Simple payouts require one transaction per validator, per era, to claim rewards. The reason Kusama requires this is to avoid an attack where someone has several thousand accounts nominating a single validator. The major cost in reward distribution is mutating the accounts in storage, and Kusama cannot pay out several thousand accounts in a single transaction.

Claiming Rewards

Kusama stores the last 84 eras of reward information (e.g. maps of era number to validator points, staking rewards, nomination exposure, etc.). Rewards will not be claimable more than 84 eras after they were earned. This means that all rewards must be claimed within a maximum of 84 eras, although under certain circumstances (described below) this may be as low as 28 eras.

If a validator kills their stash, any remaining rewards will no longer be claimable. Before doing this, however, they would need to first stop validating and then unbond the funds in their stash, which takes 28 eras. If a validator were to immediately chill and start unbonding after rewards are calculated, and nobody issued a payout for that era from that validator in the next 28 eras, the reward would no longer be claimable.

Advanced How-to Guides

In order to be absolutely sure that staking rewards can be claimed, users should trigger a payout before 28 eras have passed. See this page for more information about how to claim rewards using the Polkadot-JS UI.

FAQ and Cautionary Notes

1. Rewards expire after 84 eras. On Polkadot, that's about 84 days. On Kusama, it is approximately 21 days. Validators should claim all pending rewards before killing their stash in the event the validator decides to chill -> unbonds all -> withdraws unbonded. Nominators will not miss out on rewards if they claim the pending rewards for a validator within 28 days. Essentially, the deadline to ensure you get staking rewards is 28 eras. If the validator verifies its intent and does not unbond and withdraw, the 84 era timeline holds.
2. Claiming rewards (or neglecting to claim rewards) does not affect nominations in any way. Nominations will persist after claiming rewards or after the rewards expire.
3. Rewards are not minted until they are claimed. Therefore, if your reward destination is "stash, increasing amount at stake", then your staked amount does not reflect your rewards until you claim them. If you want to maximize compounding, then you will need to claim often or nominate validators which regularly claim for you.
4. Staking operations at the end of an era are closed to allow the off-chain validator election to take place. See Off-chain Phragmén for more information.

Staking Miner

caution

The staking-miner code is experimental and it is still in the development phase. Use is at your own discretion, as there is a risk of losing some funds.

At the end of each era on Polkadot and Kusama, using NPoS, a new set of validators must be elected based on the nominator preferences. This is a computationally intensive process, hence the usage of the term "mining" for computing the solution. The validators use off-chain workers to compute the result and submit a transaction to propose the set of winners. This can also be delegated to stand-alone programs, whose task is to mine the optimal solution. Staking miners compete with each other to produce election solutions which consist of a validator set, stake distribution across that set, and a score indicating how optimal the solution is. Staking miners run any given staking algorithms (as of now, sequential Phragmén or PhragMMS, subject to change if improved algorithms are introduced) to produce results, which are then sent as a transaction to the relay chain via a normal signed extrinsic. The transaction requires a bond and a transaction fee. The best solution is rewarded, which the least covers the transaction fee, and the bond is returned to the account. The bond and the fee are lost if the solution is invalid.

Staking miner uses a pallet called pallet_election_provider_multi_phase and can only produce solutions during the SignedPhase of the pallet's life cycle. Once the SignedPhase is over and the UnsignedPhase starts, only the off-chain workers can provide election results.

Running the staking miner requires passing the seed of a funded account in order to pay the fees for the transactions that will be sent. The same account's balance is used to reserve deposits as well. The best solution in each round is rewarded. All correct solutions will get their deposit back and the ones that submit invalid solutions will lose their deposit.

NPoS election optimization

A basic election solution is a simple distribution of stake across validators, but this can be optimized for better distribution equaling a higher security score. The staking miner does not act as a validator and focuses solely on the election result and optimization of the solution. It connects to a specified chain and keeps listening to new signed phase of the election pallet in order to submit solutions to the NPoS election. When the correct time comes, it computes its solution and submits it to the chain. The default miner algorithm is sequential Phragmén with a configurable number of balancing iterations that improve the score.

Signed Phase of the election pallet

The election provider pallet pallet_election_provider_multi_phase is divided into two phases, signed and unsigned. At the end of the pallet's timeline, the function elect() is called.

                                                                   elect()
                +   <--T::SignedPhase-->  +  <--T::UnsignedPhase-->   +
  +-------------------------------------------------------------------+
   Phase::Off   +       Phase::Signed     +      Phase::Unsigned      +

Solutions provided by the staking miner can only be submitted during the signed phase. Solutions are submitted and queued on the chain as a RawSolution. Once submitted, a solution cannot be retracted by the originating account.

RawSolution struct definition:

pub struct RawSolution<S> {
    pub solution: S, // The solution itself
    pub score: ElectionScore, // The claimed score of the solution.
    pub round: u32, // The round at which this solution should be submitted.
}

A maximum of pallet::Config::SignedMaxSubmissions will be stored on-chain and they will be sorted based on score. Higher the score the more optimal the election solution is. On both Polkadot and Kusama the 'SignedMaxSubmissions' is set to submissions. This variable can be modified if needed through governance.

Upon arrival of a new solution:

1. If the queue is not full, it is stored in the appropriate sorted index.
2. If the queue is full but the submitted solution is better than one of the queued ones, the worse solution is discarded, the deposit of the outgoing solution is returned, and the new solution is stored in the correct index.
3. If the queue is full and the solution is not an improvement compared to any of the queued ones, it is instantly rejected and no deposit is reserved.

Upon the end of the SignedPhase, no more solutions can be submitted and the solutions in the queue will be checked using Pallet::feasibility_check which ensures the score is indeed correct, and marks them as valid or invalid. By checking each solution in the queue, the queue will be reorganized by score. The highest valid score will be rewarded. Invalid solutions with higher score than the winning solution will be slashed. The rest of the solutions will be discarded and their deposit will be returned. Once the staking miner with a winning solution is ready to be rewarded the runtime will automatically execute finalize_signed_phase_accept_solution which reward account associated with the winning solution.

Queue
+-------------------------------+
|Solution(score=20, valid=false)| +-->  Slashed
+-------------------------------+
|Solution(score=15, valid=true )| +-->  Rewarded, Saved
+-------------------------------+
|Solution(score=10, valid=true )| +-->  Discarded
+-------------------------------+
|Solution(score=05, valid=false)| +-->  Discarded
+-------------------------------+
|             None              |
+-------------------------------+

Deposit and reward mechanics

The staking miners are required to pay a deposit to post their solutions. Deposit amount is the sum of SignedDepositBase +SignedDepositByte + SignedDepositWeight. All good solutions are subject to receiving a SignedRewardBase.

Deposit

Current deposit(SignedDepositBase) is which is a fixed amount.

Current deposit per byte(SignedDepositByte) is and the total is variable depending on the size of the solution data. For example, a solution weighing 200KB would yield 200 x 0.00000032551 = 0.000065102 KSM.

And the weight deposit(SignedDepositWeight) is currently set to 0 and has no effect.

Reward

Current reward(SignedRewardBase) is which is a fixed amount.

Further Resources

If you want to run a staking miner on your validator, refer to the repository provided in the resources section below.

• Staking Miner repository
• Election Pallet definition
• Signed phase parameter configuration on Polkadot