Staking Update: January 2022

2022-01-31 in  Staking Updates
Avatar by Polkadot

By Kian Paimani, Parity Technologies


Since the last update for November, Polkadot has seen 2 runtime upgrades, namely 9.14 in December and 9.15-1 in January; neither contained changes relevant to staking.  The following updates are proposed to land in 9.16:

  1. Full enablement of the bags list in Polkadot (#4653).
  2. put_in_front_of extrinsic for the bags list (#9829). More on this in the below section.

If everything goes smoothly with the full enablement of the bags list on Polkadot, a proposal to raise the max nominator limit from 22,500 to a high value (e.g. 100k) via a governance motion will likely be put forth. As a reminder, while the limit of total nominators is raised, only the 22,500 highest voters will be used for the election due to memory constraints. (Read on to learn about an upcoming pallet that will help relieve this bottleneck.)


  • There is an ongoing governance discussion regarding setting a minimum validator commission.
  • A misconfiguration was discovered that leads to some random nominators not being considered in the phragmen elections. More on this in the following section.

Phantom Nominators

Following up on reports of nominators missing from the staking election results, a misconfiguration of the staking election system was realized. The issue stems from the fact that the maximum number of voters (validators + nominators) considered for the election snapshot is 22,500 (see VoterSnapshotPerBlock), the maximum number of nominators (see MaxNominatorsCount) is 22,500, and the maximum number of validators (see MaxValidatorsCount) is 1,200.

When the voter snapshot is created, (see get_npos_voters,) first the validators are considered, and then the remaining space is filled up with nominators. In the current set up, the maximum number of voters is VoterSnapshotPerBlock; so in production the maximum number of nominators that are included can be modeled as VoterSnapshotPerBlock - CounterForValidators.

At the time of writing there were 1,004 validators, leaving room for 21,496 (22,500 - 1,004) nominators to be included in the election. However, there were 21,760 nominators, meaning 264 random nominators could not make their way into the election.

Once the bags list is fully enabled, this problem will be fixed because the bags list is sorted and thus will enable the system to efficiently grab the top X nominators by stake. With the above case, the system would grab the 21,496 highest staked nominators from the bags list and the excluded nominators would be the lowest staked, not random.

Put In Front Of Extrinsic

If unfamiliar with the mechanics of the bags list, the September and November updates provide necessary context for the below section.

To recap, when a nominator is inserted into a bag, it is always appended to the end regardless of its stake relative to others in the bag. The put-in-front-of extrinsic then will allow a nominator to move within a bag by specifying another member that it has a greater stake over; the extrinsic then will place the caller directly in front of the other nominator. In practice, moving higher up in the bag is only helpful if the bag is the last to get iterated when creating the election snapshot. This is because only the first portion of a bag is considered when the nominator limit is reached while iterating over a bag's members.

At the moment, only advanced users will take advantage of this feature, but the future goal is that UIs will support this by automatically adding the extrinsic when someone nominates, and also batching it with the option to rebag.

Upcoming: Nomination Pools

The current draft PR can be found here.

A nomination pool will act as a single nominator and its stake will be composed of the pool's members, which are called “delegators” because they delegate their stake to the pool. In the initial v0 implementation, a delegator will at minimum be able to join a pool, regularly claim their portion of rewards, and unbond to leave a pool. For future iterations the proposal is to support features such as directly bonding rewards and participation in democracy.

The pools are designed in such a way that all actions are constant time and I/O complexity relative to the number of delegators. This is crucial as it means that the number of delegators can theoretically be unbounded.

In the short term, nomination pools should allow anyone, who would not normally make it into the top 21,300 nominators participating in elections, to join a pool and earn staking rewards. Thus the pools can dramatically increase the “real” participation in staking and attract users who may have previously been blocked or discouraged.

The aim is to merge the nomination pools in by March and see them live on at least Kusama in the next closest runtime release.

Keep in mind that pools are just one piece of the scaling puzzle. There are other proposals in the pipeline for scaling, including multi-block elections and beyond that staking election parachain(s). Parity is looking for help to reach these goals (and many others), so if you are interested in helping tackle these challenges consider applying here and/or here.

System Upkeep With Extrinsics

The Polkadot staking system has a few areas that require extrinsic intervention to “maintain” the state of the system. This section aims to highlight some of these extrinsics.

  1. rebag: As covered in previous updates, nominators are inserted into a bag when they initially nominate. Over time their stake can change without an auto rebag due to rewards and slashes. When a nominator's stake increases, it is in it’s best interest to rebag itself to a higher bag, so it is expected UIs will eventually recommend necessary rebag ops.
  2. chill_other: The chill_other extrinsic allows anyone to chill a nominator or validator under certain circumstances. When the network hits its nominator limit, any valid, potential nominator is incentivized to chill an existing nominator to make room for themselves. The need for this will soon vanish once the bags list is enabled and the nominator limit is raised.
  3. reap_stash: Data structure of stakers can still exist despite a stash account only having some “dust” amount of balance due to some bugs in the past. In order to remove these data structures from storage, the reap_stash extrinsic must be called. There isn’t any direct incentive for network participants to call this, but the extrinsic is free if it does not error.

In general, the aim with these types of extrinsics is to allow the network to self maintain over time. It is expected that more organic self adjustment will occur as the  ecosystem expands and UIs + wallets improve their ability to appropriately recommend such extrinsics.

By The Numbers

At the time of writing, Polkadot has around 21,700 nominators, and  the minimum number of DOTs to be a nominator has stayed constant at 120 DOTs. While the number of nominators momentarily plateaued as auctions started, it has reverted back to an increasing trend. Kusama is still around 7,000 nominators.

About 1,000 rebags  were executed across here and here. 518 chill_other calls were executed across here and here. And about 1,200 reap stashes were executed across here, here, and here.

Last month’s average minimum amount needed to be a validator in Polkadot was 1.7331 MDOT, and the total amount staked was 619.5936 MDOT. The same metrics for Kusama have been 4.0075 kKSM and 5.0970 MKSM respectively, over the last month.

Related articles
Gov2: Polkadot’s Next Generation of Decentralised Governance

Read the proposal for Polkadot's next-generation governance system - currently known as Gov2 - to discover how it aims to advance the decentralization of the network....

Introducing the Polkadot Staking Dashboard: The Easiest Way to Nominate and Stake Your DOT

Staking your DOT just got a whole lot easier with Polkadot’s new staking dashboard, a user-friendly interface for staking natively on Polkadot....

XCMv2 Audit Completed by Quarkslab

XCMv2 has now been audited for a second time to discover any potential cross-chain security or fairness issues, including logical bugs, denial-of-service, and incorrect lock/unlock or burn/mint on both chains...

Subscribe to the newsletter to hear about updates and events.