Runtime: Nomination Pools

[mochet]

Problem

The current staking system is quite complex, and even with a vastly improved UI/UX it still has a limitation in that end users need to pay attention to complex issues and choose validators that are high quality. There is no incentive for wallet providers to add our staking functionality to their wallets as the current staking system doesn't allow for this (unless the wallet provider operates a validator themselves). We currently have quite a low amount of tokens staked and this is likely caused by how difficult the staking process is. While we are introducing a better UI/UX within Pioneer it will still remain a complex thing compared to the in-app staking that can be seen from other projects which can allow for smartphone users and extension users to stake their tokens quite effortlessly.

Solution

Nomination pools are a feature on substrate and technically speaking the functionality could be added to our runtime. There is desire from some on the council for this feature but there is the question of priority and probably some really complex development considerations that have to be discussed.

Benefits

It seems that one of the revenue streams of some wallet development teams is to operate nomination pools on behalf of their customers. Optimistically, having this feature would provide incentive for wallets to add and feature our project and also for users to stake. This could perhaps even include hardware wallet developers. If you sort the current nomination pools on Polkadot (https://polkadot.subscan.io/nomination_pool) the top one is Talisman and the 5th is Nova wallet - this gives some indication of how much to expect wallet providers may be able to help in increasing the amount staked.

[kdembler]

Discussed briefly with @mnaamani, he said that adding the nomination pools pallet itself shouldn't be a huge effort but we should bundle that with Substrate version upgrade (since it contains fixes for nomination pools), which is a slightly bigger effort because it will also need updates to our apps. We need to upgrade Substrate at some point anyway though.

[jen4ph]

Thank you @kdembler for providing an update.

When Mokhtar said that this feature should be a part of a major runtime upgrade, does it mean that we need to wait for another runtime to have this apart from the Nara we are having soon? Isn't Nara a major upgrade? So perhaps plus at least maybe at least 6 months after Nara? I'd say that is quite long.

Also, it was mentioned that the substrate version we are on is a bit old. I'd like to know the possible issues or consequences we might face if we stay at this version for a longer period?

Last question, pardon me as I don't really understand the technicality of this but is it not possible for us to have this feature integrated with Nara(if it is a major upgrade)?

Thanks in advance for answering my questions :)

[kdembler]

@jen4ph thanks for your questions.

Nara is a major upgrade but there are couple of reasons why this shouldn't be part of Nara:

1. Nara is feature frozen for some time now. We are not adding anything new and only testing existing code, making sure everything works properly. We will only introduce bugfixes if necessary.
2. Including this into Nara would make Nara delayed by at least couple months to account for development and necessary QA. I think we should try to get CRT out as soon as possible and also change the council term duration at the same time.
3. I don't think we should bundle too many changes into a single upgrade, rather do multiple smaller ones. This makes testing easier and reduces the risk of something going wrong.

Regarding Substrate version, I don't think there are any critical consequences if we don't update (although I don't think anybody tracks Substrate releases to notice critical bugs being fixed @mnaamani?). However, new versions will bring improvements adding new features, making the blockchain more resilient, fixing some possible bugs etc. If we stay on an older version for too long, it may be hard to use tools/external services or have other people integrate with us, because our API can be quite outdated compared to the latest version which others will expect.

Lastly, I don't think at least 6 months after Nara is a fair estimate. This really depends on what exactly we scope out for the next upgrade but just for nomination pools I'm sure we could squeeze it in Q2.

[traumschule]

There is no incentive for wallet providers to add our staking functionality to their wallets as the current staking system doesn't allow for this (unless the wallet provider operates a validator themselves).

@mochet Please explain this, it's not obvious why they'd need to deploy a validator (instead of a non-public endpoint). The staking system if exposed correctly would let you select any of the available pools or be your own nominator (>41k).

Nomination pools are a new feature for Polkadot’s staking system that allows users to pool their DOT tokens together on-chain to nominate validators and receive rewards, significantly improving the system’s scalability. Now, anyone with as little as 1 DOT can receive rewards for staking natively on Polkadot. One downside of nomiantion pools is no ability to auto compound rewards. Each pool member needs to claim their rewards manualy or give permissions for other accounts to do it for them.

But following the launch of Polkadot’s Relay Chain in 2020, rapid scaling of the network in 2021 and an increase in demand for staking participation put a strain on this innovative staking system. To ensure the network's security, a maximum number of 22,500 nominators was introduced and governance passed a series of motions that gradually increased the minimum nomination amount to 160 DOT↗. This limit was eventually lowered back down to 10 DOT↗, but the minimum amount needed to be part of the top 22,500 nominators and earn rewards is now dynamically determined and is still somewhere around 170 DOT at the time of writing.

To remedy the system’s scalability issues and remove the limitations introduced on participating as a nominator, several improvements to Polkadot’s staking system↗ were developed over the past year. The most significant and exciting of these is the nomination pools feature, which launched first on Kusama and is now live on Polkadot.

So as i understand it the main feature is that the minimum is lowered and pools can have names etc.

BWT polkagate offers their own extension.

[mochet]

@mochet Please explain this, it's not obvious why they'd need to deploy a validator (instead of a non-public endpoint). The staking system if exposed correctly would let you select any of the available pools or be your own nominator (>41k).

Because if they don't run a validator then they have no incentives. Nomination pools are what provide an incentive (far better than just running a validator) to the wallet providers to advertise Joystream and it's "staking product" because it can result in a continuous revenue stream for the wallet providers. If they just feature our staking system (which they won't because there is no incentive to do so) then they get nothing out of it.

[mnaamani]

I think adding nomination pools combined with updating the bags thresholds is advisable. https://github.com/Joystream/joystream/issues/5034

I would also recommend we deploy an instance of Staking Dashboard for joystream https://github.com/paritytech/polkadot-staking-dashboard

[kdembler]

@mnaamani agreed but I think we need the upgraded Substrate for nomination pools?