1. Kusama Proposal: Nomination Pools Incentives.

Nomination pools will be a part of the upcoming 9.22 release in Kusama. See the PR description for more details about the initial parameters being used.

This proposal is to address a potential issue with Nomination Pools usage on Kusama: Unlike Polkadot, Kusama currently has more active nominator slots than actual intention. At the time of this writing, 7360 nominators exist in Kusama, and the maximum number that can be rewarded is 12,500. Recall that the nomination pools are created as a way to allow those who do not meet the stake requirement to also participate in staking.

In short, this limitation does not exist in Kusama (yet). That being said, there are other reasons to want to start a pool or participate in one. This is mentioned in more detail in the April staking newsletter.

Nonetheless, this proposal aims to use the treasury funds to create a small extra incentive for pools being used in Kusama. This will help Kusama fulfill one of its existential objectives: act as an experimental version of Polkadot.

The Nomination Pools are rather easy to incentivize: Each pool is created with an associated “reward account”. Any funds transferred to this account will be claimable by the members of the pool up to that point. In other words, any funds transferred to the reward account is like an airdrop to all the pool members up to that point. See the westend pools page for an example of the reward account.

Note: Members who join after the transfer is made into the reward account do not benefit from it.

Note: Needless to say, a well-functioning pool (nominating active validators) will generate staking reward regardless of the above “airdrop”, and all of the members, including the pool creator, benefit from staking rewards with a same rate as normal staking.

Proposal A: A systematic methodology could be drafted to create the incentive. As an example: The first X pools that are created are eligible for a max reward of Y KSM. The actual reward amount can start from 0 if only the pool exists, and increase linearly until Y if the pool manages to attract Z members. Then, for e.g. 4 consecutive weeks, The pools' states are snapshotted every Sunday at a specific time, and the reward transfer is proposed to the council/democracy as a motion, based on how many members the first X pools have.

Note: Pools are created with a unique, always increasing ID, starting from 1. Thus, the first pool created will have the ID 1, then 2, then 3, etc.

This approach might attract more accounts to join the pools in terms of pure numbers, but it can also be gamed and one potential entity can claim a large amount of rewards. In other words, all of the pools and members can potentially be controlled by one user.

Proposal B: alternatively the Kusama council can rely on the tipping process to identify the pools that are behaving well, and accept a tip for them. This outsources the process of identifying good pools to community members, as there is an incentive for the tipper to propose a reasonable one (because the tipper gets a cut of the tip). In this approach, the council members need to evaluate the proposed pools for tipping manually.

Moreover, a soft deadline should be determined to approve such tips. Naturally, there is no reason to indefinitely transfer bonus tips to Kusama pools. we propose 30 days after the pools are enacted on Kusama to be a reasonable target date to accept the last tip regarding Kusama tips.

To facilitate the evaluation of tips, we propose the following criteria to determine if a pool is well behaving or not:

1. A pool should use its metadata to clearly determine its nomination strategy.
2. The pool roles should be set accordingly. For example, if a pool is claiming that its nomination strategy is determined by a party of X accounts, a multisig of this parity should be set as the pool nominator account. If a pool is claiming that it will never destroy or block itself, it should set its root and state_toggler roles to inaccessible accounts. If a pool is claiming that it will have a constant nomination strategy, it should also destroy its nominator role.
3. Similar to validators, having identities increases the trust between pool operators and members.
4. A pool should have a clear strategy about if and when it might put its state into “Blocked” or “Destroying”.

Note: The ability to explicitly set pool roles to be non-existing is being added here: https://github.com/paritytech/substrate/pull/11411