# Polkadot: The Staking Pinkpaper

## Nomination Pools 2.0

Nomination pools are in a stable state where they can reasonably fulfill the main role they were designed for: allowing almost all DOT holders to stake.

Moreover, a number of simple improvements are expected to happen in the near future:

* Permissionless claiming of rewards, simulating an auto-compounding pool as long as the pool operator or someone triggers the transaction.
* Optional commissions for pool operators, hopefully making the previous point economically feasible ([PR](https://github.com/paritytech/substrate/pull/12608)).
* Ability to `rebond` while unbonding into a pool, similar to direct nomination.

That being said, there are a number of major improvements that we foresee:

* Governance participation while you are in pools.
* Ability to join multi-pools.
* Ability to switch pools without the need to wait for a full unbonding period.
* Pools that are auto-compounding by default, as opposed to the current scheme that is "non-compounding".

## Multi-Page NPoS

> By NPoS, we mean the protocol that dictates the "active validator set", and their exposure table (list of nominators who back each) per era. This is the "source of truth" for both slashing and rewards.

┌──────────────┐
│              │
│  valiadtors  │
│              │            ┌────────────┐           ┌──────────────────────┐
└──────┬───────┘            │            │           │                      │
       │                    │            │           │                      │
       ├────────────────────►    NPoS    ├───────────►    Exposure Table    │
       │                    │            │           │                      │
       │                    │            │           │                      │
┌──────┴───────┐            └────────────┘           └──────────────────────┘
│              │
│  nominators  │
│              │
└──────────────┘

The end goal is to do the entire NPoS process in a multi-page fashion. If the protocol decides to allocate more blockspace to this process, we can expect to have a larger input (validator and nominators) and both a larger output (exposure table).

In short, this allows Polkadot to have a significantly larger number of nominators. Moreover, the NPoS system would then be ready to be deployed on a parachain.

## "Operators" as First Class Citizen

The current NPoS protocol (as defined above) does not understand any notion of validator operator (via looking at e.g. identities). It only operates and optimizes the validator set based on raw account ids.

> If you look at the stake distribution on Polkadot based on individual accounts, it looks very good, but once you take into account how many of those accounts [belong to the same oeprator](https://nominator.dwellir.app/validation), it starts to fall apart.

We want to formalize the notion of "operator" deep into the NPoS protocol. That is, ALL validator are considered to be an operator, and run `n` nodes. By default, `n == 1` for all. Some validators would opt to chose an `n > 1`. Nominators only express their approval of the operator, not individual nodes.

The benefits of this are multifold:

1. Nominating an operator is now easier, as a nominator does not need to care about which node of the operator. The nominator can still express "I want to back operator `x` up to `y` of their nodes".
2. Operators need to worry less about evenly distributing their nominators' stake between their nodes. We expect the stake distribution to improve even further when doing this.
3. The network would have a less chance of facing "nothing at stake" in the occurrence of slashing.
4. Last, but perhaps most importantly, once Polkadot has this, the protocol can express constrains such that it disincentives a single known operator from growing too large.

> Alfonso's notes

## No Controller Accounts

Controller accounts were introduced way before proxies were made, and serve a very similar function. We Strongly believe that proxies are the future, and an important gateway to more usability of the overall ecosystem.

> Imagine, have many proxies on hot-wallets and rarely using stash accounts.

In this spirit, we want to deprecate the controller concept from staking. This will result in less code (ergo, less possibility of error) and more efficient execution on the protocol side, and pushes us toward embracing the use of proxies in the UIs.

> A simple analysis on Polkadot shows that among tens of thousands of bonded accounts in staking, less than a thousand have a distinct controller account set.

## Fast(er)-Unstake

Polkadot and Kusama will soon be equipped with a feature that allows "unexposed[^1]" stakers to unstake much faster. The requirement for all stakers to wait 28 days is too strict, even if they end up being exposed.

We strive to move toward a better UX by allowing fast(er) unstake for all stakers as long as the security guarantees of the chain are not significantly affected.

This will most likely translate to a constrain on the amount that is being unstaked, and as long as it respected, unstaking can happen faster.

For example, at any point in time, the first 5% of the total staked amount can be unstaked with 7 days of bonding duration. The next 2.5% with 14 days, and the rest with 28 days.

## Brand New Slashing

> Jeff's notes: https://hackmd.io/w37x4CahQhaGJNlq-yQBnA

## Staking Parachain

https://github.com/paritytech/polkadot/issues/323

[^1]: not present anywhere in the exposure table of any era within the bonding duration