# 1. **Kusama Proposal:** Nomination Pools Incentives.

Nomination pools will be a part of the upcoming **9.22** release in Kusama. See the [PR description](https://github.com/paritytech/polkadot/pull/5447#issuecomment-1121555294) 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](https://docs.google.com/document/d/1vQ8ki4x_iEyBx-7Ih3OKzk5fBW1XcBlyJVIB41ZbSaA/edit#heading=h.bnm6g854xoms). 

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](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fwestend-rpc.polkadot.io#/staking/pools) 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](https://github.com/paritytech/substrate/pull/11411)*


:
1. A proposal to incentivize nomination pools usage on Kusama with treasury funds.
2. Proposal A suggests a systematic methodology be used to create the incentive, while Proposal B relies on the tipping process to create the incentive.
3. Criteria to determine if a pool is well-behaving or not includes a clearly defined nomination strategy, pool roles, identities, and strategy. 

#1532 Nomination Pools Incentives

No Active Proposals