[**motion 286**](https://polkadot.polkassembly.io/motion/286) is up for vote! Please vote ASAP: this proposal removes the limits on members in nomination pools on Polkadot to fulfil the goal of the recently approved [referendum 78](https://polkadot.polkassembly.io/referendum/78). Preimage is submitted: The proposal had a mistake and did not lift the limit of maximum members per pool, therefore the pools are still unusable on Polkadot.

Make sure to vote soon on this external motion for the community to vote in referenda queue after!

Removing members' limit for the community to join nomination pools

Nomination pools are just around the corner for Polkadot, and this suggests some changes to be applied to the staking system.

First, let’s recap on the current status quo: Currently, nominators can freely set their intention to nominate in Polkadot, as long as they meet two limits: a minimum of 10 DOTs is staked, and a maximum of 50_000 nominators is not filled. This creates a nomination market, where in every era, the top 22_500 nominators from this open market are chosen to participate in the election process, and possibly receive staking rewards (if other conditions like over-subscription are not met).

> This is a complicated and involved process. Nomination pools are exactly here to combat this and provide a simpler experience for DOT-holders to participate in staking. 

Based on this, let’s cluster Polkadot nominators into two groups: **active** (in the top 22500), and **waiting**. The main concern at this point is to

1. Encourage all existing waiting nominators to join pools. This is mainly a task for the Wallet/UI development ecosystem, and is beyond the scope of this discussion. 
2. Prevent too many waiting nominators to be created. The reason being that I speculate that most of these nominators have **erroneously** in the waiting queue, and prefer joining pools instead. 

To achieve the second goal, we can set the nomination limits (10 DOTs, 50_000) such that the system is not so *inviting* to waiting nominators. In other words, the system should try and prevent nominators from being created, if they are certainly going to end up being in the waiting queue. 

For example, we empirically know that the actual amount of DOTs needed to be an active nominator is around 130 DOTs as of this writing. Therefore, we can set the minimum nomination limit to a higher value such as 50.

Note that keeping a buffer of waiting nominators is a positive factor for Polkadot's economic security. It allows for buffer of waiting nominators to be ready, should a (malicious) cluster of nominators decide to chill all at once, preventing nothing at stake issues. Therefore, I am not suggesting lowering 50_000 as well, and find that a reasonable bound. But, with nomination pools, I do think we should immediately forward anyone with less than e.g. 50 DOTs to join pools instead, and the way to do that is to immediately reject their nominate transaction. 



Proposal: Slightly higher nomination limits

Polkadot community, the time has finally come: 

Nomination pools can go live any time now in Polkadot. This is a great milestone, removing any barrier for native relay chain staking for DOT-holders. The only topic to discuss is the configurations that will be used. Here are my opinions on this: 

**1 DOT to join a pool**. I actually used to suggest 5 DOTs for a slightly higher sybil resistance, but I think the 5x factor here is not that big of a difference, and allowing staker holders to join pools with at little as 1 DOT is a nice milestone. Moreover, this sybil attack is not really viable as we can easily lift the limit on maximum members (mentioned below) and then it would have no effect.

**200 DOTs to create a pool**. This is not a *cost* or *deposit*. It is actually the initial collateral/stake of the pool, and by setting it to 200, it will ensure that all pools have an initial stake that’s more than the minimum that’s needed to earn rewards (~170 as of now). This initial stake still earns rewards for the creator of the pool, and can be unstaked once the pool is being dissolved. 

**Maximum of 64 pools and 16k members in all pools**. These are only there so that if there is a bug, we can easily migrate the data and perform a fix. If we reach these limits, they can trivially be lifted to a higher value. Moreover, if pools work fine for e.g. ~6 months, we can proceed with lifting them altogether. 

I have worked hard on communicating that: “**Pools are designed to be infinitely scalable**”, I am suggesting these limits only out of extra caution. 

Discussion: Polkadot Nomination Pools Initial Configuration

Nomination pools will be live on Polkadot within the next 10 days, and I want to suggest using a small amount of treasury funds to incentivize the creation of the initial pools. Moreover, the early pools ought to be high quality, have clear name, purpose and description, giving DOT holders who wish to join pools a good number of options to join from. 

This is to signal to the community my intention to repeat the process of incentivizing the creation of high quality nomination pools, by proposing council tips for them, exactly as done for Kusama. You can find the full description [here](https://kusama.polkassembly.io/post/1532). 

Please note that tipping is an entirely permissionless process. I intend to open tip for a number of pools that I see fit as I did for Kusama, but I want to emphasize that anyone can do this. So, if the council shows signs of support here, anyone could propose a tip for the pools that are exceptionally good in the first days and weeks.

To recap, main criteria that I (merely) *suggest* are as follows: 

> * A pool should use its metadata to clearly determine its nomination strategy.
> * 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.
> * Similar to validators, having identities increases the trust between pool operators and members.
> * A pool should have a clear strategy about if and when it might put its state into “Blocked” or “Destroying”.


Discussion: Nomination Pools Incentives

The recent proposal to update staking parameters ([#162](https://polkadot.polkassembly.io/motion/162)) was related to increasing the limits for the nominators. The reason that the community has opted to do this so far, is that the supply and demand of the number of nominator slots that Polkadot can serve are not aligned, and there are many more people who wish to nominate than the number of spots available. 

The same limitation has always existed on the set of validator candidates of the network as well. Let us briefly recap: Having the intention to validate is fully permissionless and anyone is allowed to do so. Nonetheless, a limited (or better put: _finite_) number of spots are available for validator candidates to enter the NPoS election, and potentially become active validators of the network (and author blocks). The following figure illustrates this 3 step process:  

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

To make sure this process happens smoothly, we propose introducing a **minimum bond for validators as well**. This bond will ensure that those validator spots (first column of the previous figure) cannot be filled trivially. Moreover, if they do become filled, the network’s token holders and governance can respond by increasing the aforementioned minimum validator bond, combined with the permissionless ‘chill_other’ transaction that can remove stakers who are below the corresponding stake limit.

Speaking of chilling, the important implication of this proposal is that if and when enacted, validator candidates who do not meet the minimum validation bond **will also be susceptible to the chill_other transaction**. Therefore, we highly recommend validators to react timely, and move a reasonable amount of funds to their self-stake.

Similarly, we recommend the network governance to make sure the majority of the validators have updated their stake, or at least have had the chance to be informed and react. 

Lastly, as for the amount of the minimum bond, we propose a starting amount of **500 DOTs**. Two notes should be emphasized about the proposed value: 



1. The Polkadot community has had multiple rounds of discussion about a fair minimum validators stake from an _economical_ and _incentives_ point of view. Nonetheless, we want to assert that the limit proposed here should be mostly interpreted from a technical point of view, and our primary concern for this proposal is to defend against potential sybil attacks on the validator candidacy process. 
2. This value is merely a starting point, to set a precedence. Keeping the previous technical aspect in mind, the governance of the chain can always decide to increase or decrease it as it sees fit, based on the demand and supply. 

This is an open discussion for the entire community to participate. Particularly, I hope the validator community comes back to feedback before this is moved forward to actually being proposed to the governance of Polkadot.

Minimun Validators self-Stake

I (@kianenigma) write the original `polkadot-portfolio` as a CLI app earlier this year. The objective was simple: read-only, in detail portfolio app for the entire Polkadot ecosystem, relying only on onchain data (and soon light clients). 

A few months ago, I asked an old friend/former-colleague of mine Hosein (13HCnHKxS26NreRYiH5LCeyTQzQvXDCcS9hC5G6nhnSj1KFS - https://github.com/HoseinEmrani) to write a UI for it. This is still ongoing, but we've reached a point where there is a MVP  that can be used. I am opening this tip to express my support for Hosein's work and plan to continue opening tips every now and then once we reach a major milestone.

The project as a while is more of PoC and I don't see it being used in an enterprise manner, because of its onchain-data-only nature. Nonetheless, if parachain teams help us with implementing custom logic related to their chain, it can someday become a good minimal alternative to other Portfolio apps out there (e.g. sub.id and talisman). 

Polkadot-Porfolio MVP

This is a tip whose proposer address (1eTPAR2TuqLyidmPT9rMmuycHVm9s9czu78sePqg2KHMDrE) 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.

Dear council,

I am proposing a tip to Kami (@nick1979:matrix.org) for a very clever modification of the Polkadot.JS browser extension entitled [Polkadot.JS+](https://github.com/Nick-1979/polkadot-Js-Plus-extension). The extension offers additional functionality in the areas of transfers, crowdloans, account management and staking.

Details on the extension's functionality are best obtained [here](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki/How-To's) and for ease a few photos are found below:

![](https://github.com/Nick-1979/polkadot-Js-Plus-extension/raw/master/packages/extension-plus/docs/screenshots/accountsPage00.PNG)
![](https://github.com/Nick-1979/polkadot-Js-Plus-extension/raw/master/packages/extension-plus/docs/screenshots/nominatedValidators00.PNG)
![](https://github.com/Nick-1979/polkadot-Js-Plus-extension/raw/master/packages/extension-plus/docs/screenshots/accountsPage00.PNG)

The project's source is open and the recipients address can be verified the bottom of the repo.

> Original note taken from Will | Paradox in his closed [Kusama tip](https://kusama.polkassembly.io/tip/0x0c7a244df0c6e04ca8659d69b3207dc77fa8c8d8b39e1d06bfb59a01e6349045).

 Tip for a modified version of the Polkadot.JS extension that provides additional features for transfers and staking.

in preparation for the crowdloan unlock on October 24th, as discussed in <a href="https://forum.polkadot.network/t/adjusting-polkadots-ideal-staking-rate-calculation/3897">this forum post</a>, it was concluded to propose slightly increasing the ideal staking rate in Polkadot, such that the network can accommodate the new DOT that is being unlocked into the staking system, without reducing staking rewards.&nbsp;
In short, what this proposal does is:&nbsp;
For the current situation, the ideal staking rate would then be calculated as: 0.75 - min(45,60)/300 = 0.6, i.e., 60%.
You can find the full steps to reproduce the proposal in <a href="https://hackmd.io/ykunWzXYR-Kaz_cM2KNIlg">https://hackmd.io/ykunWzXYR-Kaz_cM2KNIlg</a>. It is merely a 1 liner change to the former Polkadot runtime that was version 9430.&nbsp;
The enactment time is set to <a href="https://polkadot.subscan.io/block/17840000">this</a> block, which is roughly 2 days before the funds unlock from crowdloans.&nbsp;
The corresponding fellowship referendum to whitelist the call is <a href="https://collectives.polkassembly.io/member-referenda/24">https://collectives.polkassembly.io/member-referenda/24</a>.&nbsp;