This proposal is intended to re-think the staking limits that are currently set on Kusama, and alter them such that, whilst keeping _some_ degree of _chaos_ in the backpocket, the chain remains safe over the long term. First, let’s look at the current staking limits of Kusama. 

![alt_text](https://i.imgur.com/Dqq0DwQ.png)

Note that the minimum nominator bond is in PLANKs, meaning that it is actually **0.1KSM**. 

Recall that the NPoS election process, in order to be both successful and safe, contains 4 main steps. 

1. Snapshot creation.
2. Signed submissions from staking-miner.
3. Unsigned submissions from validators, as backup. 
4. Solution verification.

Our experimentation has unraveled that, as it stands now, the bottleneck for the Kusama network (and Polkadot and Westend) is the **third** step, and the largest input data for which this step could be executed, in WASM, without running out of resources (weight, memory, block-length), is when there are at most around **12500** nominators in the system. Note that this number is expectedly lower than Polkadot’s 22500, because Kusama opted to allow for up to **24** nominations per nominator. Thus, we need to assume the worst case in our experimentation, namely that each nominator is indeed using all of their 24 nominations.

To reflect this, we need to alter a runtime type parameter, which can only be done as a part of runtime upgrade, not as a standalone council motion. This is done in the following pull request: 
* [https://github.com/paritytech/polkadot/pull/5000](https://github.com/paritytech/polkadot/pull/5000)

Lastly, since Kusama network is already fully using the bags-list pallet, it can freely open its door to many more _nomination intentions_, being sure that the top 12,500 are selected by the bags-list. To reflect this, we suggest **removing the maximum nominator count limit** entirely, and **keeping the 0.1KSM** as the minimum bond for nominators.

**NOTE**: We might be able to tweak these number to slightly higher values again, once these two pull requests are merged into production: 

* [https://github.com/paritytech/substrate/pull/10340](https://github.com/paritytech/substrate/pull/10340)
* [https://github.com/paritytech/substrate/pull/10821](https://github.com/paritytech/substrate/pull/10821)

Similar to [the corresponding proposal for Polkadot](https://polkadot.polkassembly.io/post/905) with exactly the same argumentation, we also strongly advise the Kusama network to use a reasonable value for minimum validator bond. For that, we suggest an initial value of **1 KSM** as a relatively low starting point, which similarly can be further increased if the need arises. 

All in all, we propose the following call to be enacted on Kusama **after** [PR#5000](https://github.com/paritytech/polkadot/pull/5000) is _merged_ and _enacted_. 

![](https://i.imgur.com/cMrfj69.png)

**NOTE**: minCommission might be altered in [Ref #176](https://kusama.polkassembly.io/referendum/176) to 3% and if executed, should be reflected as well. 


Minimum Validator self-Stake + Other Safety Adjustments

# 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)*


Nomination Pools Incentives

I was informed by Kami from PolkaGate team that they have successfully [submitted the first fast-unstake process in Kusama](https://kusama.subscan.io/extrinsic/0x58baab6ce8d74e1be1743b57d68fad11dcc1eed9ef26b892003291e33dccea18). While this is great, I proposed to them to also test submitting multiple fast-unstake requests in parallel, so that we can test the [batching functionality](https://github.com/paritytech/substrate/pull/12394). Given the minimum nomination bond of 0.1 KSM, this requires a bit of initial funds, which I am suggesting to allocate to this team from the treasury. 

While most of these funds can be returned after the fact, I advocating for considering it a gift to the PolkaGate team, as they have consistently been the first wallet to implement latest staking features, and provider invaluable feedback to myself and the rest of the staking team. 

Tip PolkaGate team for further testing of fast-unstake in Kusama

This is a tip whose proposer address (HL8bEp8YicBdrUmJocCAWVLKUaR2dd1y6jnD934pbre3un1) is shown in on-chain info below. Only this user can edit this description and the title. If you own this account, login and tell us more about your proposal.

whitelist_call

This proposal should enable fast-unstake in Kusama, as explained [here](https://forum.polkadot.network/t/path-to-fast-unstake-in-polkadot-kusama/1539).

Enable conditional fast-unstake service in Kusama

This is a referendum whose proposer address (HL8bEp8YicBdrUmJocCAWVLKUaR2dd1y6jnD934pbre3un1) is shown in on-chain info below. Only this user can edit this description and the title. If you own this account, login and tell us more about your proposal.

No tip found