Advanced Staking Concepts · Polkadot Wiki (2024)

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

Staking Proxies​

Polkadot makes it possible to create accountshaving special permissions also called proxy accounts. For more details about proxy accountsvisit the dedicated page on this wiki.

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

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

Ideally, accounts with high economic power like the stash must be and remain as isolated aspossible. With a staking proxy, the stash account is fully isolated when signing for staking-relatedtransactions. The proxy private key will be used to sign staking-related transactions, the stashprivate 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 forall staking-related transactions. From a security perspective who controls the staking proxycontrols 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. Thismeans 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​

In Polkadot's NPoS nomination intents areplaced in a semi-sorted list called bags-list.TheBags-List substrate pallet is designed to be self-maintaining, with minimal effort from theblockchain, 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 specificrange. In the figure below the 1st empty bag will contain nominators whose bonded balance is in therange of 21 - 30 DOT, the 2nd bag 11 - 20 DOT, and the 3rd bag 0-10 DOT. The nomination intents arethe nominators' accounts with bonded tokens (in the example shown below, there are eight nominationintents) 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 nominationintents are submitted to the network, they are automatically put into each bag based on the numberof bonded tokens, but within each bag, those nodes are arranged based on the time they are insertedand 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 scenarioapplies for the node with 8 DOT (green circle) in the 3rd bag. Placing the node above all nodes witha 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 actionmust be done manually by submitting the putInFrontOf extrinsic within the voterList palletinstance. Moreover, if the node with 19 DOT bonds an additional 2 DOT, that node will be putautomatically in the 1st bag (i.e. automatic rebag) because the total number of bonded tokens willnow be within the range of the 1st bag. That node with now 21 DOT will be put at the tail end of the1st 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 samescenario applies to a slashing event, i.e., when a nominator gets slashed, their position within abag does not change. This might result in a scenario where the node is in the wrong bag and needs tobe placed in the right bag. To address this issue, any account on-chain can submit thepermissionless extrinsic rebag within the voterList pallet instance to update the positions ofthe nodes that do not belong to their bag and place them in the correct one. To reiterate, actionslike bonding/unbonding tokens automatically rebag the nominator node, but events like stakingrewards/slashing do not. See the bags-list section for moreinformation.

The bags-list is capable of including an unlimited number of nodes, subject to the chain's runtimestorage. In the current staking system configuration, at most 22500nominators in the bags-list come out as the electing nominators. SeeStaking 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 itoutputs a set of validators. The bags are iterated from the most staked to the least staked. If theaccounts are not appropriately sorted, this could leave the last touched bag to only be partiallyiterated. Thus, in some edge cases, the order of the members within a bag is important. Continuingwith the example used in the previous figures, there are 8 nomination intents of which only 7 willbe kept. If the bags list stays semi-sorted (i.e. no accounts call the putInFrontOf and rebagextrinsics), the nomination of the node with 8 DOT in the 3rd bag will not be considered while thatof the preceding node with 5 DOT will be. Nomination of the node with 8 DOT will be kept only if itputs itself in front of the one with 5 DOT. Note how the nomination of the node with 19 DOT in the2nd bag will be considered regardless of changing its position inside the bag. The sortingfunctionality of nomination intents using bags is extremely important for thelong-term improvements of thestaking/election system.

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

Rewards Distribution​

Validators are paid the same regardless of stake backing them. Validators with less stake willgenerally pay more to nominators per-token than the ones with more stake. This gives nominators aneconomic incentive to gradually shift their preferences to lower-staked validators that gain asufficient amount of reputation. A consequence of this is that the stake across validators will beas evenly distributed as possible which avoids concentration of power among a few validators. In thelong term, validators will have similar levels of stake, with the stake being higher for validatorswith higher reputation. A nominator who is willing to risk more by backing a validator with a lowerreputation 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 anabsolute value. After the commission gets deducted, the remaining portion is distributed pro-ratabased on their staked value and split between the validator and all of the nominators whose stakehas backed this validator.

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

Thus, a percentage of the reward goes thus to pay the validator's commission fees and the remainderis paid pro-rata (i.e. proportional to stake) to the nominators and validator. If a validator'scommission is set to 100%, no tokens will be paid out to any of the nominators. Notice in particularthat the validator is rewarded twice: once in commission fees for validating (if their commissionrate 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 actualvalue, which fluctuates, but merely an assumption for purposes of this example; to understand howthe actual minimal stake is calculated, seehere).

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 thanthose of validator A because A has more overall stake. Sam has staked 50 DOT with validator A, buthe 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 thistool as a reference and play around withit by changing some parameters (e.g. how many days you would like to stake with your DOT, providerfees, compound rewards, etc.) to have a better estimate. Even though it may not be entirely accuratesince staking participation is changing dynamically, it works well as an indicator.

Commission Fees & Slashes​

The network slashes a validator for a misbehavior. The slashed amount is afixed percentage (and not a fixed amount), which means that validators with more stake get slashedmore DOT. Again, this is done to provide nominators with an economic incentive to shift theirpreferences 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 apercentage of rewards) to cover operational costs. Since validators are paid the same, validatorswith lower commission fees pay more to nominators than validators with higher fees. Thus, eachvalidator can choose between increasing their fees to earn more, or decreasing their fees to attractmore nominators and increase their chances of being elected. In the long term, we expect that allvalidators will need to be cost-efficient to remain competitive, and that validators with higherreputation will be able to charge slightly higher commission fees (which is fair).

Simple Payouts​

Polkadot makes stakers claim their rewards forpast eras by submitting a transaction. This naturally leads to spreading out reward distribution, aspeople make transactions at disparate times, rather than updating the accounts of all stakers in asingle block.

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

Simple payouts require one transaction per validator, per era, toclaim rewards. The reason Polkadot requiresthis is to avoid an attack where someone has several thousand accounts nominating a singlevalidator. The major cost in reward distribution is mutating the accounts in storage, andPolkadot cannot pay out several thousandaccounts in a single transaction.

Claiming Rewards​

Polkadot stores the last 84 eras of rewardinformation (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 allrewards must be claimed within a maximum of 84 eras, although under certain circ*mstances (describedbelow) this may be as low as 28 eras.

If a validator kills their stash, any remaining rewards will no longer be claimable. Before doingthis, 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 arecalculated, and nobody issued a payout for that era from that validator in the next 28 eras, thereward would no longer be claimable.

FAQ and Cautionary Notes​

1. Rewards expire after 84 eras. On Polkadot, that's about 84 days. On Kusama, it is approximately21 days. Validators should claim all pending rewards before killing their stash in the event thevalidator decides to chill -> unbonds all -> withdraws unbonded. Nominators will not missout on rewards if they claim the pending rewards for a validator within 28 days. Essentially, thedeadline to ensure you get staking rewards is 28 eras. If the validator verifies its intent anddoes 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 youclaim them. If you want to maximize compounding, then you will need to claim often or nominatevalidators which regularly claim for you.
4. Staking operations at the end of an era are closed to allow the off-chain validator election totake place. See Off-chain Phragmén for more information.

Staking Miner​

At the end of each era on Polkadot and Kusama, using NPoS, a new set of validatorsmust 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 useoff-chain workers to computethe result and submit a transaction to propose the set of winners. This can also be delegated tostand-alone programs, whose task is to mine the optimal solution. Staking miners compete with eachother to produce election solutions which consist of a validator set, stake distribution across thatset, and a score indicating how optimal the solution is. Staking miners run any given stakingalgorithms (as of now, sequential Phragmén or PhragMMS, subject to change if improved algorithms areintroduced) to produce results, which are then sent as a transaction to the relay chain via a normalsigned extrinsic. The transaction requires a bond and a transaction fee. The best solution isrewarded, which the least covers the transaction fee, and the bond is returned to the account.The bond and the fee are lost if thesolution is invalid.

Staking miner uses a pallet called pallet_election_provider_multi_phase and can only producesolutions during theSignedPhaseof the pallet's life cycle. Once the SignedPhase is over and theUnsignedPhasestarts, 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 forthe 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 andthe 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 beoptimized for better distribution equaling a higher security score. The staking miner does not actas a validator and focuses solely on the election result and optimization of the solution. Itconnects to a specified chain and keeps listening to new signed phase of the election pallet inorder to submit solutions to the NPoS election. When the correct time comes, it computes itssolution and submits it to the chain. The default miner algorithm is sequential Phragmén with aconfigurable 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 aresubmitted and queued on the chain as a RawSolution. Once submitted, a solution cannot be retractedby 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 ofpallet::Config::SignedMaxSubmissionswill be stored on-chain and they will be sorted based on score. Higher the score the more optimalthe election solution is. TheSignedMaxSubmissions variablecan be modified 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 worsesolution is discarded, the deposit of the outgoing solution is returned, and the new solution isstored 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 queuewill be checked usingPallet::feasibility_checkwhich ensures the score is indeed correct, and marks them as valid or invalid. By checking eachsolution in the queue, the queue will be reorganized by score. The highest valid score will berewarded. Invalid solutions with higher score than the winning solution will be slashed. The rest ofthe solutions will be discarded and their deposit will be returned. Once the staking miner with awinning solution is ready to be rewarded the runtime will automatically executefinalize_signed_phase_accept_solutionwhich 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 sumof SignedDepositBase +SignedDepositByte + SignedDepositWeight. All good solutions are subjectto receiving a SignedRewardBase. For more information about deposit values see theChain State Values page.

Further Resources​

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

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