[NPoS] Nomination pools: Allow funds to be used for democracy #454

kianenigma · 2022-08-17T17:28:24Z

Edited:

Nomination pool currently works by 1) moving the funds from delegator to pool account, and 2) stake from pool account.
What we really want though is, 1) delegate the funds from delegator to pool account, and 2) stake from pool account.

Delegate the funds would imply similar pool functions with a very important difference that instead of funds moving from delegator to pool account, the funds will be locked in delegator's account and can be used for participating in governance voting.

In #408, staking pallet will enable the functionality of delegation of funds to another account (such as pool account) which will enable nomination pools to achieve the delegate and stake strategy. By utilising the delegated funds as if they belong to the pool, the pool account gains the ability to stake these funds as a direct nominator.

The text was updated successfully, but these errors were encountered:

kianenigma · 2022-11-21T09:42:04Z

If this approach works, we should also make it workable for crowdloan funds.

forgetso · 2023-08-23T09:39:36Z

This is an important issue. Most people want the ease of use associated with nomination pools but are prevented from participating in proposal decisions as a result.

forgetso · 2023-08-28T09:25:03Z

Thanks for the update @kianenigma

Ank4n · 2023-09-07T10:15:10Z

Update: The rough plan is to achieve this in two steps:

Delegation Primitive in staking: Refer issue [NPoS] Staking: Users can delegate their fund to a target which can nominate on their behalf. #408. This will expose a new DelegatedStakeInterface for NominationPool to use. Compared to StakingInterface that allows an account to be a direct nominator, DelegateStakingInterface allows an account (called delegator) to delegate its stake to another account (delegatee). In delegation based staking, the funds are locked in the delegator's account and gives the delegatee the right to use the funds for staking as if it is a direct nominator.
NominationPool switches to use DelegatedStakeInterface: Once enabled for a runtime, this will allow new pool members to first delegate funds to the pool account and then stake. The delegated funds are frozen in user's account and can be used for governance. At this stage, for users whose funds are transferred to the pool account previously can invoke a migrate call that will transfer their share of stake in the pool to their account (tokens will stay frozen).

The first part is actively worked on in this branch. I am currently implementing a way to do a partial_withdraw of unlocking funds in a staking ledger (required for delegated staking) and then will move on to trying to use this with NominationPools pallet to validate the DelegatedStakeInterface makes sense. Both issues can be released in separate PRs though.

michalisFr · 2023-10-02T15:38:00Z

Since this is already being worked on, this is mostly for the sake of discussion, but let me post an alternative solution.

With the current way that pools work (funds being sent to the pool), pool members could opt in to delegate their funds in the pool to the pool (to keep things simple delegating is binary, either their whole stake or nothing). A new capital variable for the pool would need to be introduced that would keep track of the total delegated balance (from the members that have opted in). Then the pool (through its owner account) would be able to vote in referenda with this capital. The conviction should be limited to None, otherwise pool members may not be able to unbond.

Basically this wouldn't be a delegation per se, but an internal mechanism of pools that allows them to have a capital (not necessarily equal to the pool account's balance) with which the pool can vote in referenda.

Is what I'm describing possible? What would be the benefits and drawback compared to the solution you're working on @Ank4n?

Some pros of the solution you work on that I can think of:

Funds remain in the user's account -> increased "sense" of security and similar experience to solo staking
User can decide for themselves how to vote or delegate their vote
Doesn't centralise voting power in the hands of pool operators (as my proposal does). But given that delegation is encouraged, I consider this more of a con than a pro (see my second point below).

Some pros of my proposed solution:

Simpler implementation (I think)
Users that join a pool some times do it as a simpler solution to staking, even if they can stake solo. These users are not likely to participate in governance. On the other hand, pool operators are likely to vote in referenda and if they carry the votes of their pool's members, this would lead to increased participation. In other words, it would be a simple way for pool members to delegate their votes, even simpler than the current delegation method.

Ank4n · 2023-10-12T12:21:35Z

@michalisFr Sorry for the late response (i am in a retreat currently), but sounds a decent idea. Especially if we make it even simpler and allow all pool funds to be used in governance by the pool operator. A pool can signal at the time of creation whether the pool funds will be used for governance. The only con I see is that delegators can't independently vote on a referenda but that may not necessarily be a bad thing.

Polkadot-Forum · 2023-10-16T06:40:27Z

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/retail-nominators-the-foundation-of-dot-demand-until-polkadots-next-chapter/4252/16

michalisFr · 2023-10-16T11:21:37Z

@michalisFr Sorry for the late response (i am in a retreat currently), but sounds a decent idea. Especially if we make it even simpler and allow all pool funds to be used in governance by the pool operator. A pool can signal at the time of creation whether the pool funds will be used for governance. The only con I see is that delegators can't independently vote on a referenda but that may not necessarily be a bad thing.

Hey @Ank4n! No worries. Thanks for the response.

This is indeed an even simpler solution. How would you handle existing pools and members though? If this was to be allowed for existing pools (as it should IMO), some members might disagree with their pool's decision, but leaving a pool is not easy.

Anyway, these are implementation details. I don't want to take up more of your time with this. Unless you're actually thinking of going with this model over the one you're already working on :)

Polkadot-Forum · 2023-11-16T14:18:37Z

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/frame-monthly-update/4628/1

muddlebee · 2024-01-19T13:13:01Z

hey @Ank4n any estimated timeline for this? I'm a community mod at Polkadot discord, we are getting frequent queries about when this will be live.

Ank4n · 2024-01-19T13:54:04Z

hey @Ank4n any estimated timeline for this? I'm a community mod at Polkadot discord, we are getting frequent queries about when this will be live.

Hey @muddlebee, unfortunately this turned out to be a much bigger change and we had some back and forth on how we want to implement this without adding regression to current staking logic. But there is progress on it in this PR and seems to be the approach we are settling on. My current target is to get this to Westend in Q1 but for Kusama and Polkadot, I would say Q2 (with audit).

Ank4n · 2024-01-19T14:01:06Z

Update: Moved it to Q1 2024 in the roadmap.

Polkadot-Forum · 2024-01-19T17:34:05Z

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/monthly-governance-incentive-referendum-1-buffet/5764/2

sourabhniyogi · 2024-01-20T11:49:21Z

hey @Ank4n any estimated timeline for this? I'm a community mod at Polkadot discord, we are getting frequent queries about when this will be live.

Hey @muddlebee, unfortunately this turned out to be a much bigger change and we had some back and forth on how we want to implement this without adding regression to current staking logic. But there is progress on it in this PR and seems to be the approach we are settling on. My current target is to get this to Westend in Q1 but for Kusama and Polkadot, I would say Q2 (with audit).

@Ank4n In your Q1 2024 delivery (exciting, thank you for moving it up!), can you explain what exactly will be locked by a pool operator who votes on referenda with a certain level of convictionVoting, if pool funds can be used for governance?

Ank4n · 2024-01-31T15:22:42Z

hey @Ank4n any estimated timeline for this? I'm a community mod at Polkadot discord, we are getting frequent queries about when this will be live.

Hey @muddlebee, unfortunately this turned out to be a much bigger change and we had some back and forth on how we want to implement this without adding regression to current staking logic. But there is progress on it in this PR and seems to be the approach we are settling on. My current target is to get this to Westend in Q1 but for Kusama and Polkadot, I would say Q2 (with audit).

@Ank4n In your Q1 2024 delivery (exciting, thank you for moving it up!), can you explain what exactly will be locked by a pool operator who votes on referenda with a certain level of convictionVoting, if pool funds can be used for governance?

I am not sure if I understood the question. Once this is live, funds contributed to nomination pool would be held (reserved) in user's own account instead of being transferred to the pool's account. Any pallet such as pallet-conviction-voting that looks at total balance and uses freezes (locks) would be able to reuse these held funds. Did that answer your question?

Polkadot-Forum · 2024-02-19T07:02:04Z

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/decentralized-voices-program-luke-schoen/6111/6

Polkadot-Forum · 2024-03-04T08:36:45Z

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/opengov-improvements-on-the-technical-level/6578/3

bkchr · 2024-03-04T10:18:09Z

@Ank4n @gpestana can someone of you give an update on the status of this issue?

Ank4n · 2024-03-04T10:25:24Z

PR here #2680. Its very close to being ready.

This is the first PR in preparation for #454. ## Follow ups: - #3904. - #3905. Overall changes are documented here (lot more visual 😍): https://hackmd.io/@ak0n/454-np-governance [Maybe followup](#4217) with migration of storage item `VirtualStakers` as a bool or enum in `Ledger`. ## Context We want to achieve a way for a user (`Delegator`) to delegate their funds to another account (`Agent`). Delegate implies the funds are locked in delegator account itself. Agent can act on behalf of delegator to stake directly on Staking pallet. The delegation feature is added to Staking via another pallet `delegated-staking` worked on [here](#3904). ## Introduces: ### StakingUnchecked Trait As the name implies, this trait allows unchecked (non-locked) mutation of staking ledger. These apis are only meant to be used by other pallets in the runtime and should not be exposed directly to user code path. Also related: #3888. ### Virtual Bond Allows other pallets to stake via staking pallet while managing the locks on these accounts themselves. Introduces another storage `VirtualStakers` that whitelist these accounts. We also restrict virtual stakers to set reward account as themselves. Since the account has no locks, we cannot support compounding of rewards. Conservatively, we require them to set a separate account different from the staker. Since these are code managed, it should be easy for another pallet to redistribute reward and rebond them. ### Slashes Since there is no actual lock maintained by staking-pallet for virtual stakers, this pallet does not apply any slashes. It is then important for pallets managing virtual stakers to listen to slashing events and apply necessary slashes.

Polkadot-Forum · 2024-05-01T07:32:11Z

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/paritytech-update-for-april/7646/1

Polkadot-Forum · 2024-05-04T20:13:49Z

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/paritytech-update-for-april-2024/7646/2

This is the second PR in preparation for #454. ## Also see - **Precursor** #3889. - **Follow up** #3905. Overall changes are documented here (lot more visual 😍): https://hackmd.io/@ak0n/454-np-governance ## Changes ### Delegation Interface Provides delegation primitives for staking. Introduces two new roles: - Agent: These are accounts who receive delegation from other accounts (delegators) and stakes on behalf of them. The funds are held in delegator accounts. - Delegator: Accounts who delegate their funds to an agent authorising them to use it for staking. Supports - A way for delegators to add or withdraw delegation to an agent. - A way for an agent to slash a delegator during a slashing event. ### Pallet Delegated Staking - Implements `DelegationInterface`. - Lazy slashing: Any slashes to an Agent is posted in a ledger but not immediately slashed. The agent can call `DelegationInterface::delegator_slash` to slash the member and clear the corresponding slash from its ledger. - Consumes `StakingInterface` to provide `CoreStaking` features. In reality, this will be `pallet-staking`. - Ensures bookkeeping for agent and delegator are correct but leaves the management of reward and slash logic upto the consumer of this pallet. - While it does not expose any calls yet, it is written with the intent of exposing these primitives via extrinsics. ## TODO - [x] Improve unit tests in the pallet. - [x] Separate slash reward perbill for rewarding the slash reporters? - [x] Review if we should add more events. --------- Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com> Co-authored-by: georgepisaltu <52418509+georgepisaltu@users.noreply.github.com>

Third and final PR in the set, closes #454. Original PR: #2680 ## Precursors: - #3889. - #3904. ## Follow up issues/improvements - #4404 Overall changes are documented here (lot more visual 😍): https://hackmd.io/@ak0n/454-np-governance ## Summary of various roles 🤯 ### Pallet Staking **Nominator**: An account that directly stakes on `pallet-staking` and nominates a set of validators. **Stakers**: Common term for nominators and validators. Virtual Stakers: Same as stakers, but they are keyless accounts and their locks are managed by a pallet external to `pallet-staking`. ### Pallet Delegated Staking **Agent**: An account that receives delegation from other accounts (delegators) and stakes on their behalf. They are also Virtual Stakers in `pallet-staking` where `pallet-delegated-staking` manages its locks. **Delegator**: An account that delegates some funds to an agent. ### Pallet Nomination Pools **Pool account**: Keyless account of a pool where funds are pooled. Members pledge their funds towards the pools. These are going to become `Agent` accounts in `pallet-delegated-staking`. **Pool Members**: They are individual members of the pool who contributed funds to it. They are also `Delegator` in `pallet-delegated-staking`. ## Changes ### Multiple Stake strategies **TransferStake**: The current nomination pool logic can be considered a staking strategy where delegators transfer funds to pool and stake. In this scenario, funds are locked in pool account, and users lose the control of their funds. **DelegateStake**: With this PR, we introduce a new staking strategy where individual delegators delegate fund to pool. `Delegate` implies funds are locked in delegator account itself. Important thing to note is, pool does not have funds of its own, but it has authorization from its members to use these funds for staking. We extract out all the interaction of pool with staking interface into a new trait `StakeStrategy`. This is the logic that varies between the above two staking strategies. We use the trait `StakeStrategy` to implement above two strategies: `TransferStake` and `DelegateStake`. ### NominationPool Consumes an implementation of `StakeStrategy` instead of `StakingInterface`. I have renamed it from `Staking` to `StakeAdapter` to clarify the difference from the earlier used trait. To enable delegation based staking in pool, Nomination pool can be configured as: ``` type StakeAdapter = pallet_nomination_pools::adapter::DelegateStake<Self, DelegatedStaking>; ``` Note that with the following configuration, the changes in the PR are no-op. ``` type StakeAdapter = pallet_nomination_pools::adapter::TransferStake<Self, Staking>; ``` ## Deployment roadmap Plan to enable this only in Westend. In production runtimes, we can keep pool to use `TransferStake` which will be no functional change. Once we have a full audit, we can enable this in Kusama followed by Polkadot. ## TODO - [x] Runtime level (Westend) migration for existing nomination pools. - [x] Permissionless call/ pallet::tasks for claiming delegator funds. - [x] Add/update benches. - [x] Migration tests. - [x] Storage flag to mark `DelegateStake` migration and integrity checks to not allow `TransferStake` for migrated runtimes. --------- Signed-off-by: Matteo Muraca <mmuraca247@gmail.com> Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io> Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Signed-off-by: Adrian Catangiu <adrian@parity.io> Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io> Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Signed-off-by: divdeploy <chenguangxue@outlook.com> Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: hongkuang <liurenhong@outlook.com> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: gemini132 <164285545+gemini132@users.noreply.github.com> Co-authored-by: Matteo Muraca <56828990+muraca@users.noreply.github.com> Co-authored-by: Liam Aharon <liam.aharon@hotmail.com> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Alexandru Gheorghe <49718502+alexggh@users.noreply.github.com> Co-authored-by: Alessandro Siniscalchi <asiniscalchi@gmail.com> Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com> Co-authored-by: Ross Bulat <ross@parity.io> Co-authored-by: Serban Iorga <serban@parity.io> Co-authored-by: s0me0ne-unkn0wn <48632512+s0me0ne-unkn0wn@users.noreply.github.com> Co-authored-by: Sam Johnson <sam@durosoft.com> Co-authored-by: Adrian Catangiu <adrian@parity.io> Co-authored-by: Javier Viola <363911+pepoviola@users.noreply.github.com> Co-authored-by: Alexandru Vasile <60601340+lexnv@users.noreply.github.com> Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com> Co-authored-by: Dastan <88332432+dastansam@users.noreply.github.com> Co-authored-by: Clara van Staden <claravanstaden64@gmail.com> Co-authored-by: Ron <yrong1997@gmail.com> Co-authored-by: Vincent Geddes <vincent@snowfork.com> Co-authored-by: Svyatoslav Nikolsky <svyatonik@gmail.com> Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com> Co-authored-by: Dino Pačandi <3002868+Dinonard@users.noreply.github.com> Co-authored-by: Andrei Eres <eresav@me.com> Co-authored-by: Alin Dima <alin@parity.io> Co-authored-by: Andrei Sandu <andrei-mihail@parity.io> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Bastian Köcher <info@kchr.de> Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: Sebastian Kunert <skunert49@gmail.com> Co-authored-by: gupnik <nikhilgupta.iitk@gmail.com> Co-authored-by: Vladimir Istyufeev <vladimir@parity.io> Co-authored-by: Lulu <morgan@parity.io> Co-authored-by: Juan Girini <juangirini@gmail.com> Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com> Co-authored-by: Dónal Murray <donal.murray@parity.io> Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com> Co-authored-by: Kutsal Kaan Bilgin <kutsalbilgin@gmail.com> Co-authored-by: Ermal Kaleci <ermalkaleci@gmail.com> Co-authored-by: ordian <write@reusable.software> Co-authored-by: divdeploy <166095818+divdeploy@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Co-authored-by: Squirrel <gilescope@gmail.com> Co-authored-by: HongKuang <166261675+HongKuang@users.noreply.github.com> Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io> Co-authored-by: Egor_P <egor@parity.io> Co-authored-by: Aaro Altonen <48052676+altonen@users.noreply.github.com> Co-authored-by: Dmitry Markin <dmitry@markin.tech> Co-authored-by: Alexandru Vasile <alexandru.vasile@parity.io> Co-authored-by: Léa Narzis <78718413+lean-apple@users.noreply.github.com> Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com> Co-authored-by: georgepisaltu <52418509+georgepisaltu@users.noreply.github.com> Co-authored-by: command-bot <> Co-authored-by: PG Herveou <pgherveou@gmail.com> Co-authored-by: jimwfs <wqq1479787@163.com> Co-authored-by: jimwfs <169986508+jimwfs@users.noreply.github.com> Co-authored-by: polka.dom <polkadotdom@gmail.com>

This is the second PR in preparation for paritytech#454. ## Also see - **Precursor** paritytech#3889. - **Follow up** paritytech#3905. Overall changes are documented here (lot more visual 😍): https://hackmd.io/@ak0n/454-np-governance ## Changes ### Delegation Interface Provides delegation primitives for staking. Introduces two new roles: - Agent: These are accounts who receive delegation from other accounts (delegators) and stakes on behalf of them. The funds are held in delegator accounts. - Delegator: Accounts who delegate their funds to an agent authorising them to use it for staking. Supports - A way for delegators to add or withdraw delegation to an agent. - A way for an agent to slash a delegator during a slashing event. ### Pallet Delegated Staking - Implements `DelegationInterface`. - Lazy slashing: Any slashes to an Agent is posted in a ledger but not immediately slashed. The agent can call `DelegationInterface::delegator_slash` to slash the member and clear the corresponding slash from its ledger. - Consumes `StakingInterface` to provide `CoreStaking` features. In reality, this will be `pallet-staking`. - Ensures bookkeeping for agent and delegator are correct but leaves the management of reward and slash logic upto the consumer of this pallet. - While it does not expose any calls yet, it is written with the intent of exposing these primitives via extrinsics. ## TODO - [x] Improve unit tests in the pallet. - [x] Separate slash reward perbill for rewarding the slash reporters? - [x] Review if we should add more events. --------- Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com> Co-authored-by: georgepisaltu <52418509+georgepisaltu@users.noreply.github.com>

…tytech#3905) Third and final PR in the set, closes paritytech#454. Original PR: paritytech#2680 ## Precursors: - paritytech#3889. - paritytech#3904. ## Follow up issues/improvements - paritytech#4404 Overall changes are documented here (lot more visual 😍): https://hackmd.io/@ak0n/454-np-governance ## Summary of various roles 🤯 ### Pallet Staking **Nominator**: An account that directly stakes on `pallet-staking` and nominates a set of validators. **Stakers**: Common term for nominators and validators. Virtual Stakers: Same as stakers, but they are keyless accounts and their locks are managed by a pallet external to `pallet-staking`. ### Pallet Delegated Staking **Agent**: An account that receives delegation from other accounts (delegators) and stakes on their behalf. They are also Virtual Stakers in `pallet-staking` where `pallet-delegated-staking` manages its locks. **Delegator**: An account that delegates some funds to an agent. ### Pallet Nomination Pools **Pool account**: Keyless account of a pool where funds are pooled. Members pledge their funds towards the pools. These are going to become `Agent` accounts in `pallet-delegated-staking`. **Pool Members**: They are individual members of the pool who contributed funds to it. They are also `Delegator` in `pallet-delegated-staking`. ## Changes ### Multiple Stake strategies **TransferStake**: The current nomination pool logic can be considered a staking strategy where delegators transfer funds to pool and stake. In this scenario, funds are locked in pool account, and users lose the control of their funds. **DelegateStake**: With this PR, we introduce a new staking strategy where individual delegators delegate fund to pool. `Delegate` implies funds are locked in delegator account itself. Important thing to note is, pool does not have funds of its own, but it has authorization from its members to use these funds for staking. We extract out all the interaction of pool with staking interface into a new trait `StakeStrategy`. This is the logic that varies between the above two staking strategies. We use the trait `StakeStrategy` to implement above two strategies: `TransferStake` and `DelegateStake`. ### NominationPool Consumes an implementation of `StakeStrategy` instead of `StakingInterface`. I have renamed it from `Staking` to `StakeAdapter` to clarify the difference from the earlier used trait. To enable delegation based staking in pool, Nomination pool can be configured as: ``` type StakeAdapter = pallet_nomination_pools::adapter::DelegateStake<Self, DelegatedStaking>; ``` Note that with the following configuration, the changes in the PR are no-op. ``` type StakeAdapter = pallet_nomination_pools::adapter::TransferStake<Self, Staking>; ``` ## Deployment roadmap Plan to enable this only in Westend. In production runtimes, we can keep pool to use `TransferStake` which will be no functional change. Once we have a full audit, we can enable this in Kusama followed by Polkadot. ## TODO - [x] Runtime level (Westend) migration for existing nomination pools. - [x] Permissionless call/ pallet::tasks for claiming delegator funds. - [x] Add/update benches. - [x] Migration tests. - [x] Storage flag to mark `DelegateStake` migration and integrity checks to not allow `TransferStake` for migrated runtimes. --------- Signed-off-by: Matteo Muraca <mmuraca247@gmail.com> Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io> Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Signed-off-by: Adrian Catangiu <adrian@parity.io> Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io> Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Signed-off-by: divdeploy <chenguangxue@outlook.com> Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: hongkuang <liurenhong@outlook.com> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: gemini132 <164285545+gemini132@users.noreply.github.com> Co-authored-by: Matteo Muraca <56828990+muraca@users.noreply.github.com> Co-authored-by: Liam Aharon <liam.aharon@hotmail.com> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Alexandru Gheorghe <49718502+alexggh@users.noreply.github.com> Co-authored-by: Alessandro Siniscalchi <asiniscalchi@gmail.com> Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com> Co-authored-by: Ross Bulat <ross@parity.io> Co-authored-by: Serban Iorga <serban@parity.io> Co-authored-by: s0me0ne-unkn0wn <48632512+s0me0ne-unkn0wn@users.noreply.github.com> Co-authored-by: Sam Johnson <sam@durosoft.com> Co-authored-by: Adrian Catangiu <adrian@parity.io> Co-authored-by: Javier Viola <363911+pepoviola@users.noreply.github.com> Co-authored-by: Alexandru Vasile <60601340+lexnv@users.noreply.github.com> Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com> Co-authored-by: Dastan <88332432+dastansam@users.noreply.github.com> Co-authored-by: Clara van Staden <claravanstaden64@gmail.com> Co-authored-by: Ron <yrong1997@gmail.com> Co-authored-by: Vincent Geddes <vincent@snowfork.com> Co-authored-by: Svyatoslav Nikolsky <svyatonik@gmail.com> Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com> Co-authored-by: Dino Pačandi <3002868+Dinonard@users.noreply.github.com> Co-authored-by: Andrei Eres <eresav@me.com> Co-authored-by: Alin Dima <alin@parity.io> Co-authored-by: Andrei Sandu <andrei-mihail@parity.io> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Bastian Köcher <info@kchr.de> Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: Sebastian Kunert <skunert49@gmail.com> Co-authored-by: gupnik <nikhilgupta.iitk@gmail.com> Co-authored-by: Vladimir Istyufeev <vladimir@parity.io> Co-authored-by: Lulu <morgan@parity.io> Co-authored-by: Juan Girini <juangirini@gmail.com> Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com> Co-authored-by: Dónal Murray <donal.murray@parity.io> Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com> Co-authored-by: Kutsal Kaan Bilgin <kutsalbilgin@gmail.com> Co-authored-by: Ermal Kaleci <ermalkaleci@gmail.com> Co-authored-by: ordian <write@reusable.software> Co-authored-by: divdeploy <166095818+divdeploy@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Co-authored-by: Squirrel <gilescope@gmail.com> Co-authored-by: HongKuang <166261675+HongKuang@users.noreply.github.com> Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io> Co-authored-by: Egor_P <egor@parity.io> Co-authored-by: Aaro Altonen <48052676+altonen@users.noreply.github.com> Co-authored-by: Dmitry Markin <dmitry@markin.tech> Co-authored-by: Alexandru Vasile <alexandru.vasile@parity.io> Co-authored-by: Léa Narzis <78718413+lean-apple@users.noreply.github.com> Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com> Co-authored-by: georgepisaltu <52418509+georgepisaltu@users.noreply.github.com> Co-authored-by: command-bot <> Co-authored-by: PG Herveou <pgherveou@gmail.com> Co-authored-by: jimwfs <wqq1479787@163.com> Co-authored-by: jimwfs <169986508+jimwfs@users.noreply.github.com> Co-authored-by: polka.dom <polkadotdom@gmail.com>

Polkadot-Forum · 2024-06-13T07:31:55Z

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/any-update-on-voting-while-staking-in-a-pool/8589/3

This is the second PR in preparation for paritytech#454. ## Also see - **Precursor** paritytech#3889. - **Follow up** paritytech#3905. Overall changes are documented here (lot more visual 😍): https://hackmd.io/@ak0n/454-np-governance ## Changes ### Delegation Interface Provides delegation primitives for staking. Introduces two new roles: - Agent: These are accounts who receive delegation from other accounts (delegators) and stakes on behalf of them. The funds are held in delegator accounts. - Delegator: Accounts who delegate their funds to an agent authorising them to use it for staking. Supports - A way for delegators to add or withdraw delegation to an agent. - A way for an agent to slash a delegator during a slashing event. ### Pallet Delegated Staking - Implements `DelegationInterface`. - Lazy slashing: Any slashes to an Agent is posted in a ledger but not immediately slashed. The agent can call `DelegationInterface::delegator_slash` to slash the member and clear the corresponding slash from its ledger. - Consumes `StakingInterface` to provide `CoreStaking` features. In reality, this will be `pallet-staking`. - Ensures bookkeeping for agent and delegator are correct but leaves the management of reward and slash logic upto the consumer of this pallet. - While it does not expose any calls yet, it is written with the intent of exposing these primitives via extrinsics. ## TODO - [x] Improve unit tests in the pallet. - [x] Separate slash reward perbill for rewarding the slash reporters? - [x] Review if we should add more events. --------- Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com> Co-authored-by: georgepisaltu <52418509+georgepisaltu@users.noreply.github.com>

…tytech#3905) Third and final PR in the set, closes paritytech#454. Original PR: paritytech#2680 ## Precursors: - paritytech#3889. - paritytech#3904. ## Follow up issues/improvements - paritytech#4404 Overall changes are documented here (lot more visual 😍): https://hackmd.io/@ak0n/454-np-governance ## Summary of various roles 🤯 ### Pallet Staking **Nominator**: An account that directly stakes on `pallet-staking` and nominates a set of validators. **Stakers**: Common term for nominators and validators. Virtual Stakers: Same as stakers, but they are keyless accounts and their locks are managed by a pallet external to `pallet-staking`. ### Pallet Delegated Staking **Agent**: An account that receives delegation from other accounts (delegators) and stakes on their behalf. They are also Virtual Stakers in `pallet-staking` where `pallet-delegated-staking` manages its locks. **Delegator**: An account that delegates some funds to an agent. ### Pallet Nomination Pools **Pool account**: Keyless account of a pool where funds are pooled. Members pledge their funds towards the pools. These are going to become `Agent` accounts in `pallet-delegated-staking`. **Pool Members**: They are individual members of the pool who contributed funds to it. They are also `Delegator` in `pallet-delegated-staking`. ## Changes ### Multiple Stake strategies **TransferStake**: The current nomination pool logic can be considered a staking strategy where delegators transfer funds to pool and stake. In this scenario, funds are locked in pool account, and users lose the control of their funds. **DelegateStake**: With this PR, we introduce a new staking strategy where individual delegators delegate fund to pool. `Delegate` implies funds are locked in delegator account itself. Important thing to note is, pool does not have funds of its own, but it has authorization from its members to use these funds for staking. We extract out all the interaction of pool with staking interface into a new trait `StakeStrategy`. This is the logic that varies between the above two staking strategies. We use the trait `StakeStrategy` to implement above two strategies: `TransferStake` and `DelegateStake`. ### NominationPool Consumes an implementation of `StakeStrategy` instead of `StakingInterface`. I have renamed it from `Staking` to `StakeAdapter` to clarify the difference from the earlier used trait. To enable delegation based staking in pool, Nomination pool can be configured as: ``` type StakeAdapter = pallet_nomination_pools::adapter::DelegateStake<Self, DelegatedStaking>; ``` Note that with the following configuration, the changes in the PR are no-op. ``` type StakeAdapter = pallet_nomination_pools::adapter::TransferStake<Self, Staking>; ``` ## Deployment roadmap Plan to enable this only in Westend. In production runtimes, we can keep pool to use `TransferStake` which will be no functional change. Once we have a full audit, we can enable this in Kusama followed by Polkadot. ## TODO - [x] Runtime level (Westend) migration for existing nomination pools. - [x] Permissionless call/ pallet::tasks for claiming delegator funds. - [x] Add/update benches. - [x] Migration tests. - [x] Storage flag to mark `DelegateStake` migration and integrity checks to not allow `TransferStake` for migrated runtimes. --------- Signed-off-by: Matteo Muraca <mmuraca247@gmail.com> Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io> Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Signed-off-by: Adrian Catangiu <adrian@parity.io> Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io> Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Signed-off-by: divdeploy <chenguangxue@outlook.com> Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: hongkuang <liurenhong@outlook.com> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: gemini132 <164285545+gemini132@users.noreply.github.com> Co-authored-by: Matteo Muraca <56828990+muraca@users.noreply.github.com> Co-authored-by: Liam Aharon <liam.aharon@hotmail.com> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Alexandru Gheorghe <49718502+alexggh@users.noreply.github.com> Co-authored-by: Alessandro Siniscalchi <asiniscalchi@gmail.com> Co-authored-by: Andrei Sandu <54316454+sandreim@users.noreply.github.com> Co-authored-by: Ross Bulat <ross@parity.io> Co-authored-by: Serban Iorga <serban@parity.io> Co-authored-by: s0me0ne-unkn0wn <48632512+s0me0ne-unkn0wn@users.noreply.github.com> Co-authored-by: Sam Johnson <sam@durosoft.com> Co-authored-by: Adrian Catangiu <adrian@parity.io> Co-authored-by: Javier Viola <363911+pepoviola@users.noreply.github.com> Co-authored-by: Alexandru Vasile <60601340+lexnv@users.noreply.github.com> Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com> Co-authored-by: Dastan <88332432+dastansam@users.noreply.github.com> Co-authored-by: Clara van Staden <claravanstaden64@gmail.com> Co-authored-by: Ron <yrong1997@gmail.com> Co-authored-by: Vincent Geddes <vincent@snowfork.com> Co-authored-by: Svyatoslav Nikolsky <svyatonik@gmail.com> Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com> Co-authored-by: Dino Pačandi <3002868+Dinonard@users.noreply.github.com> Co-authored-by: Andrei Eres <eresav@me.com> Co-authored-by: Alin Dima <alin@parity.io> Co-authored-by: Andrei Sandu <andrei-mihail@parity.io> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Bastian Köcher <info@kchr.de> Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: Sebastian Kunert <skunert49@gmail.com> Co-authored-by: gupnik <nikhilgupta.iitk@gmail.com> Co-authored-by: Vladimir Istyufeev <vladimir@parity.io> Co-authored-by: Lulu <morgan@parity.io> Co-authored-by: Juan Girini <juangirini@gmail.com> Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com> Co-authored-by: Dónal Murray <donal.murray@parity.io> Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com> Co-authored-by: Kutsal Kaan Bilgin <kutsalbilgin@gmail.com> Co-authored-by: Ermal Kaleci <ermalkaleci@gmail.com> Co-authored-by: ordian <write@reusable.software> Co-authored-by: divdeploy <166095818+divdeploy@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Co-authored-by: Squirrel <gilescope@gmail.com> Co-authored-by: HongKuang <166261675+HongKuang@users.noreply.github.com> Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io> Co-authored-by: Egor_P <egor@parity.io> Co-authored-by: Aaro Altonen <48052676+altonen@users.noreply.github.com> Co-authored-by: Dmitry Markin <dmitry@markin.tech> Co-authored-by: Alexandru Vasile <alexandru.vasile@parity.io> Co-authored-by: Léa Narzis <78718413+lean-apple@users.noreply.github.com> Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com> Co-authored-by: georgepisaltu <52418509+georgepisaltu@users.noreply.github.com> Co-authored-by: command-bot <> Co-authored-by: PG Herveou <pgherveou@gmail.com> Co-authored-by: jimwfs <wqq1479787@163.com> Co-authored-by: jimwfs <169986508+jimwfs@users.noreply.github.com> Co-authored-by: polka.dom <polkadotdom@gmail.com>

kianenigma added the J0-enhancement label Aug 17, 2022

Ank4n self-assigned this Mar 27, 2023

kianenigma changed the title ~~Nomination pools: Allow funds to be used for democracy~~ [NPoS] Nomination pools: Allow funds to be used for democracy Apr 27, 2023

Ank4n mentioned this issue Jul 12, 2023

[NPoS] Unify staking functions across staking pallet and nomination pallet #407

Open

juangirini transferred this issue from paritytech/substrate Aug 24, 2023

the-right-joyce added I5-enhancement An additional feature request. and removed J0-enhancement labels Aug 25, 2023

Ank4n mentioned this issue Oct 23, 2023

[NPoS] Trusted delegation feature in staking #1986

Closed

Ank4n mentioned this issue Dec 14, 2023

[Moved] Enable governance for Nomination Pool members #2680

Closed

4 tasks

Ank4n mentioned this issue Mar 29, 2024

Allow privileged virtual bond in Staking pallet #3889

Merged

kianenigma mentioned this issue Mar 29, 2024

🎉 Wishlist: Users #3901

Open

This was referenced Mar 30, 2024

Introduces: Delegated Staking Pallet #3904

Merged

Refactor Nomination Pool to support multiple staking strategies #3905

Merged

Ank4n closed this as completed in #3905 May 22, 2024

Ank4n mentioned this issue May 29, 2024

[Pools] Build a pool slashing monitoring bot to apply pending slashes to the affected pool members. #4630

Open

balqaasem mentioned this issue Jul 28, 2024

🎉 Wishlist: Users Setheum-Labs/Setheum#1066

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[NPoS] Nomination pools: Allow funds to be used for democracy #454

[NPoS] Nomination pools: Allow funds to be used for democracy #454

kianenigma commented Aug 17, 2022 •

edited by Ank4n

Loading

kianenigma commented Nov 21, 2022

forgetso commented Aug 23, 2023

forgetso commented Aug 28, 2023

Ank4n commented Sep 7, 2023

michalisFr commented Oct 2, 2023

Ank4n commented Oct 12, 2023

Polkadot-Forum commented Oct 16, 2023

michalisFr commented Oct 16, 2023

Polkadot-Forum commented Nov 16, 2023

muddlebee commented Jan 19, 2024

Ank4n commented Jan 19, 2024

Ank4n commented Jan 19, 2024

Polkadot-Forum commented Jan 19, 2024

sourabhniyogi commented Jan 20, 2024 •

edited

Loading

Ank4n commented Jan 31, 2024

Polkadot-Forum commented Feb 19, 2024

Polkadot-Forum commented Mar 4, 2024

bkchr commented Mar 4, 2024

Ank4n commented Mar 4, 2024

Polkadot-Forum commented May 1, 2024

Polkadot-Forum commented May 4, 2024

Polkadot-Forum commented Jun 13, 2024

[NPoS] Nomination pools: Allow funds to be used for democracy #454

[NPoS] Nomination pools: Allow funds to be used for democracy #454

Comments

kianenigma commented Aug 17, 2022 • edited by Ank4n Loading

kianenigma commented Nov 21, 2022

forgetso commented Aug 23, 2023

forgetso commented Aug 28, 2023

Ank4n commented Sep 7, 2023

michalisFr commented Oct 2, 2023

Ank4n commented Oct 12, 2023

Polkadot-Forum commented Oct 16, 2023

michalisFr commented Oct 16, 2023

Polkadot-Forum commented Nov 16, 2023

muddlebee commented Jan 19, 2024

Ank4n commented Jan 19, 2024

Ank4n commented Jan 19, 2024

Polkadot-Forum commented Jan 19, 2024

sourabhniyogi commented Jan 20, 2024 • edited Loading

Ank4n commented Jan 31, 2024

Polkadot-Forum commented Feb 19, 2024

Polkadot-Forum commented Mar 4, 2024

bkchr commented Mar 4, 2024

Ank4n commented Mar 4, 2024

Polkadot-Forum commented May 1, 2024

Polkadot-Forum commented May 4, 2024

Polkadot-Forum commented Jun 13, 2024

kianenigma commented Aug 17, 2022 •

edited by Ank4n

Loading

sourabhniyogi commented Jan 20, 2024 •

edited

Loading