-
Notifications
You must be signed in to change notification settings - Fork 721
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Moved] Enable governance for Nomination Pool members #2680
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
5 tasks
Ank4n
changed the title
[NPoS] Enabling governance with funds delegated to Nomination Pool
https://github.com/paritytech/polkadot-sdk/pull/3905
Apr 1, 2024
The CI pipeline was cancelled due to failure one of the required jobs. |
Ank4n
changed the title
https://github.com/paritytech/polkadot-sdk/pull/3905
Enable governance for Nomination Pool members
Apr 1, 2024
Ank4n
changed the title
Enable governance for Nomination Pool members
[Deprecated] Enable governance for Nomination Pool members
Apr 9, 2024
Ank4n
changed the title
[Deprecated] Enable governance for Nomination Pool members
[Moved] Enable governance for Nomination Pool members
May 6, 2024
github-merge-queue bot
pushed a commit
that referenced
this pull request
May 22, 2024
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 <[email protected]> Signed-off-by: Alexandru Gheorghe <[email protected]> Signed-off-by: Andrei Sandu <[email protected]> Signed-off-by: Adrian Catangiu <[email protected]> Signed-off-by: Alexandru Vasile <[email protected]> Signed-off-by: Oliver Tale-Yazdi <[email protected]> Signed-off-by: divdeploy <[email protected]> Signed-off-by: dependabot[bot] <[email protected]> Signed-off-by: hongkuang <[email protected]> Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: gemini132 <[email protected]> Co-authored-by: Matteo Muraca <[email protected]> Co-authored-by: Liam Aharon <[email protected]> Co-authored-by: Kian Paimani <[email protected]> Co-authored-by: Alexandru Gheorghe <[email protected]> Co-authored-by: Alessandro Siniscalchi <[email protected]> Co-authored-by: Andrei Sandu <[email protected]> Co-authored-by: Ross Bulat <[email protected]> Co-authored-by: Serban Iorga <[email protected]> Co-authored-by: s0me0ne-unkn0wn <[email protected]> Co-authored-by: Sam Johnson <[email protected]> Co-authored-by: Adrian Catangiu <[email protected]> Co-authored-by: Javier Viola <[email protected]> Co-authored-by: Alexandru Vasile <[email protected]> Co-authored-by: Niklas Adolfsson <[email protected]> Co-authored-by: Dastan <[email protected]> Co-authored-by: Clara van Staden <[email protected]> Co-authored-by: Ron <[email protected]> Co-authored-by: Vincent Geddes <[email protected]> Co-authored-by: Svyatoslav Nikolsky <[email protected]> Co-authored-by: Michal Kucharczyk <[email protected]> Co-authored-by: Dino Pačandi <[email protected]> Co-authored-by: Andrei Eres <[email protected]> Co-authored-by: Alin Dima <[email protected]> Co-authored-by: Andrei Sandu <[email protected]> Co-authored-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Branislav Kontur <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]> Co-authored-by: gupnik <[email protected]> Co-authored-by: Vladimir Istyufeev <[email protected]> Co-authored-by: Lulu <[email protected]> Co-authored-by: Juan Girini <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: Dónal Murray <[email protected]> Co-authored-by: Shawn Tabrizi <[email protected]> Co-authored-by: Kutsal Kaan Bilgin <[email protected]> Co-authored-by: Ermal Kaleci <[email protected]> Co-authored-by: ordian <[email protected]> Co-authored-by: divdeploy <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Sergej Sakac <[email protected]> Co-authored-by: Squirrel <[email protected]> Co-authored-by: HongKuang <[email protected]> Co-authored-by: Tsvetomir Dimitrov <[email protected]> Co-authored-by: Egor_P <[email protected]> Co-authored-by: Aaro Altonen <[email protected]> Co-authored-by: Dmitry Markin <[email protected]> Co-authored-by: Alexandru Vasile <[email protected]> Co-authored-by: Léa Narzis <[email protected]> Co-authored-by: Gonçalo Pestana <[email protected]> Co-authored-by: georgepisaltu <[email protected]> Co-authored-by: command-bot <> Co-authored-by: PG Herveou <[email protected]> Co-authored-by: jimwfs <[email protected]> Co-authored-by: jimwfs <[email protected]> Co-authored-by: polka.dom <[email protected]>
can be closed? |
hitchhooker
pushed a commit
to ibp-network/polkadot-sdk
that referenced
this pull request
Jun 5, 2024
…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 <[email protected]> Signed-off-by: Alexandru Gheorghe <[email protected]> Signed-off-by: Andrei Sandu <[email protected]> Signed-off-by: Adrian Catangiu <[email protected]> Signed-off-by: Alexandru Vasile <[email protected]> Signed-off-by: Oliver Tale-Yazdi <[email protected]> Signed-off-by: divdeploy <[email protected]> Signed-off-by: dependabot[bot] <[email protected]> Signed-off-by: hongkuang <[email protected]> Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: gemini132 <[email protected]> Co-authored-by: Matteo Muraca <[email protected]> Co-authored-by: Liam Aharon <[email protected]> Co-authored-by: Kian Paimani <[email protected]> Co-authored-by: Alexandru Gheorghe <[email protected]> Co-authored-by: Alessandro Siniscalchi <[email protected]> Co-authored-by: Andrei Sandu <[email protected]> Co-authored-by: Ross Bulat <[email protected]> Co-authored-by: Serban Iorga <[email protected]> Co-authored-by: s0me0ne-unkn0wn <[email protected]> Co-authored-by: Sam Johnson <[email protected]> Co-authored-by: Adrian Catangiu <[email protected]> Co-authored-by: Javier Viola <[email protected]> Co-authored-by: Alexandru Vasile <[email protected]> Co-authored-by: Niklas Adolfsson <[email protected]> Co-authored-by: Dastan <[email protected]> Co-authored-by: Clara van Staden <[email protected]> Co-authored-by: Ron <[email protected]> Co-authored-by: Vincent Geddes <[email protected]> Co-authored-by: Svyatoslav Nikolsky <[email protected]> Co-authored-by: Michal Kucharczyk <[email protected]> Co-authored-by: Dino Pačandi <[email protected]> Co-authored-by: Andrei Eres <[email protected]> Co-authored-by: Alin Dima <[email protected]> Co-authored-by: Andrei Sandu <[email protected]> Co-authored-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Branislav Kontur <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]> Co-authored-by: gupnik <[email protected]> Co-authored-by: Vladimir Istyufeev <[email protected]> Co-authored-by: Lulu <[email protected]> Co-authored-by: Juan Girini <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: Dónal Murray <[email protected]> Co-authored-by: Shawn Tabrizi <[email protected]> Co-authored-by: Kutsal Kaan Bilgin <[email protected]> Co-authored-by: Ermal Kaleci <[email protected]> Co-authored-by: ordian <[email protected]> Co-authored-by: divdeploy <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Sergej Sakac <[email protected]> Co-authored-by: Squirrel <[email protected]> Co-authored-by: HongKuang <[email protected]> Co-authored-by: Tsvetomir Dimitrov <[email protected]> Co-authored-by: Egor_P <[email protected]> Co-authored-by: Aaro Altonen <[email protected]> Co-authored-by: Dmitry Markin <[email protected]> Co-authored-by: Alexandru Vasile <[email protected]> Co-authored-by: Léa Narzis <[email protected]> Co-authored-by: Gonçalo Pestana <[email protected]> Co-authored-by: georgepisaltu <[email protected]> Co-authored-by: command-bot <> Co-authored-by: PG Herveou <[email protected]> Co-authored-by: jimwfs <[email protected]> Co-authored-by: jimwfs <[email protected]> Co-authored-by: polka.dom <[email protected]>
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: |
TarekkMA
pushed a commit
to moonbeam-foundation/polkadot-sdk
that referenced
this pull request
Aug 2, 2024
…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 <[email protected]> Signed-off-by: Alexandru Gheorghe <[email protected]> Signed-off-by: Andrei Sandu <[email protected]> Signed-off-by: Adrian Catangiu <[email protected]> Signed-off-by: Alexandru Vasile <[email protected]> Signed-off-by: Oliver Tale-Yazdi <[email protected]> Signed-off-by: divdeploy <[email protected]> Signed-off-by: dependabot[bot] <[email protected]> Signed-off-by: hongkuang <[email protected]> Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: gemini132 <[email protected]> Co-authored-by: Matteo Muraca <[email protected]> Co-authored-by: Liam Aharon <[email protected]> Co-authored-by: Kian Paimani <[email protected]> Co-authored-by: Alexandru Gheorghe <[email protected]> Co-authored-by: Alessandro Siniscalchi <[email protected]> Co-authored-by: Andrei Sandu <[email protected]> Co-authored-by: Ross Bulat <[email protected]> Co-authored-by: Serban Iorga <[email protected]> Co-authored-by: s0me0ne-unkn0wn <[email protected]> Co-authored-by: Sam Johnson <[email protected]> Co-authored-by: Adrian Catangiu <[email protected]> Co-authored-by: Javier Viola <[email protected]> Co-authored-by: Alexandru Vasile <[email protected]> Co-authored-by: Niklas Adolfsson <[email protected]> Co-authored-by: Dastan <[email protected]> Co-authored-by: Clara van Staden <[email protected]> Co-authored-by: Ron <[email protected]> Co-authored-by: Vincent Geddes <[email protected]> Co-authored-by: Svyatoslav Nikolsky <[email protected]> Co-authored-by: Michal Kucharczyk <[email protected]> Co-authored-by: Dino Pačandi <[email protected]> Co-authored-by: Andrei Eres <[email protected]> Co-authored-by: Alin Dima <[email protected]> Co-authored-by: Andrei Sandu <[email protected]> Co-authored-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Branislav Kontur <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]> Co-authored-by: gupnik <[email protected]> Co-authored-by: Vladimir Istyufeev <[email protected]> Co-authored-by: Lulu <[email protected]> Co-authored-by: Juan Girini <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: Dónal Murray <[email protected]> Co-authored-by: Shawn Tabrizi <[email protected]> Co-authored-by: Kutsal Kaan Bilgin <[email protected]> Co-authored-by: Ermal Kaleci <[email protected]> Co-authored-by: ordian <[email protected]> Co-authored-by: divdeploy <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Sergej Sakac <[email protected]> Co-authored-by: Squirrel <[email protected]> Co-authored-by: HongKuang <[email protected]> Co-authored-by: Tsvetomir Dimitrov <[email protected]> Co-authored-by: Egor_P <[email protected]> Co-authored-by: Aaro Altonen <[email protected]> Co-authored-by: Dmitry Markin <[email protected]> Co-authored-by: Alexandru Vasile <[email protected]> Co-authored-by: Léa Narzis <[email protected]> Co-authored-by: Gonçalo Pestana <[email protected]> Co-authored-by: georgepisaltu <[email protected]> Co-authored-by: command-bot <> Co-authored-by: PG Herveou <[email protected]> Co-authored-by: jimwfs <[email protected]> Co-authored-by: jimwfs <[email protected]> Co-authored-by: polka.dom <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #408 and #454.
Update [April 1, 2024]
This PR has been broken down into three different PRs targeting individual pallets that are affected. Please refer to the following:
Problem
When a staker directly stakes on pallet-staking, their funds are locked in their account and stakers can use their locked funds for participating in governance. For delegators in Nomination Pool, their funds are transferred to a pool account (pallet sub account) instead. This means they lose access to their locked funds and cannot use it for governance.
We could fix this if NominationPool instead held funds in the user accounts itself and somehow conveyed to Staking Pallet that the pool account represents the locked amount of all its delegators.
How NP works currently:
How we want it to work:
This is what we try to achieve with
pallet-delegated-staking
. It is a wrapper implementation on top of staking-pallet that adds a new primitive ofDelegation
to staking.Other design goals and challenges
Delegatee
account to keep slashing event bounded.Changes
Delegatee Account
We introduce a new primitive for staking, where an account can receive
delegation
from multipledelegator
accounts. We call the account that accepts delegations asDelegatee
. Their staking balance is made up of multiple child delegator accounts and for staking purposes their actual balance is ignored. Importantly, the balance is held in individual delegator accounts and not actually moved to the delegatee account.Staking pallet
Accepts a new type
DelegateeSupport
to support the aboveDelegatee
accounts.Delegated Staking Pallet
Implements
DelegateeSupport
andDelegatedStakingInterface
.DelegatedStakingInterface
is an extension ofStakingInterface
that also supports delegation of accounts.Nomination Pool
Nomination Pool now supports two staking strategies:
TransferStake
orDelegatedStake
. It accepts a new config typeStakingStrategy
which replaces the earlierStaking
.If we set
type StakeAdapter = pallet_nomination_pools::adapter::TransferStake<Runtime, Staking>
, changes in the PR would be no-op and the pool should work exactly as before.Migration of accounts
There are migration extrinsics exposed by
pallet-delegated-staking
to convert aNominator
into aDelegatee
and a way for old Pool members to migrate their funds and be locked in their own accounts.Note: The migration code is not integrated yet in NominationPool.
Following are the steps of how a nomination pool would migrate to DelegateStake strategy.
For this step, we create a
proxy_delegator
account that is a keyless account derived using the actual pool account bypallet-delegated-staking
. All funds are moved to this account and delegated to pool account. Pool account is now adelegatee
.Step 1 and 2 needs to be done in a single migration. This step can be done async, one delegator at a time permissionlessly. Each nominator can migrate their funds from proxy delegator to their own account.
When all delegators to a pool have migrated their funds,
proxy_delegator
account is dusted.Integration tests
There are integration tests of NP, Staking and DelegatedStaking (
pallet-delegated-staking::tests::pool_integration::*
) to ensure that the new pallet works as expected. It could also be a good starting point to look at to understand how the new code will work.Current status
There are still minor issues and probably some more refactors that I will be doing in the coming days. The code though is functionally complete and would be great to get some reviews already 🙏 .
TODO