[Staking] Currency <> Fungible migration

[Ank4n]

Migrate staking currency from traits::LockableCurrency to traits::fungible::holds.

Resolves part of #226.

Changes

Nomination Pool

TransferStake is now incompatible with fungible migration as old pools were not meant to have additional ED. Since they are anyways deprecated, removed its usage from all test runtimes.

Staking

• Config: Currency becomes of type Fungible while OldCurrency is the LockableCurrency used before.
• Lazy migration of accounts. Any ledger update will create a new hold with no extra reads/writes. A permissionless extrinsic migrate_currency() releases the old lock along with some housekeeping.
• Staking now requires ED to be left free. It also adds no consumer to staking accounts.
• If hold cannot be applied to all stake, the un-holdable part is force withdrawn from the ledger.

Delegated Staking

The pallet does not add provider for agents anymore.

Migration stats

Polkadot

Total accounts that can be migrated: 59564
Accounts failing to migrate: 0
Accounts with stake force withdrawn greater than ED: 59
Total force withdrawal: 29591.26 DOT

Kusama

Total accounts that can be migrated: 26311
Accounts failing to migrate: 0
Accounts with stake force withdrawn greater than ED: 48
Total force withdrawal: 1036.05 KSM

Full logs here.

Note about locks (freeze) vs holds

With locks or freezes, staking could use total balance of an account. But with holds, the account needs to be left with at least Existential Deposit in free balance. This would also affect nomination pools which till now has been able to stake all funds contributed to it. An alternate version of this PR is #5658 where staking pallet does not add any provider, but means pools and delegated-staking pallet has to provide for these accounts and makes the end to end logic (of provider and consumer ref) lot less intuitive and prone to bug.

This PR now introduces requirement for stakers to maintain ED in their free balance. This helps with removing the bug prone incrementing and decrementing of consumers and providers.

TODO

• Test: Vesting + governance locked funds can be staked.
• can Call::restore_ledger be removed? @gpestana
• Ensure unclaimed withdrawals is not affected by no provider for pool accounts.
• Investigate kusama accounts with balance between 0 and ED.
• Permissionless call to release lock.
• Migration of consumer (dec) and provider (inc) for direct stakers.
• force unstake if hold cannot be applied to all stake.
• Fix try state checks (it thinks nothing is staked for unmigrated ledgers).
• Bench migrate_currency.
• Virtual Staker migration test.
• Ensure total issuance is upto date when minting rewards.

Followup

• Ensure nomination pool members can directly stake and vice versa. #5742

[muharem]

Looks good to me. But consider this approve as from someone who is not an expert in the staking topic

[kianenigma]

this is basically the "staked, and active in staking (minus pending slash)" balance?

[Ank4n]

Yes

[kianenigma]

This file had really good tests, I learned a lot by reading them!

[kianenigma]

PR is in good shape, and thanks to incremental code, the changes are easy to digest, good work!

• About the amounts of force_withdraw: Ideally we need to check the status of the old corrupt ledgers, and make sure they are eliminated before this. As @muharem said, with 59 accounts, I would expect 59*ED to be force removed from staking. Update: the 12k account is indeed one that is still in a corrupt state and we will try to force_unstake it fully in the next runtime upgrade: Release v1.4.0 polkadot-fellows/runtimes#527 (comment)
• We need to add a guide for wallets to this, explaining how they should adapt to this. For directs stakers, it is likely not a big deal as they are likely reading the ledger.total, and not inspecting STAKING_LOCK anymore. For pools, it will be substantial. This support article is a good start: https://support.polkadot.network/support/solutions/articles/65000188140-changes-for-nomination-pool-members-and-opengov-participation

[Ank4n]

About the amounts of force_withdraw: Ideally we need to check the status of the old corrupt ledgers, and make sure they are eliminated before this. As @muharem said, with 59 accounts, I would expect 59*ED to be force removed from staking. Update: the 12k account is indeed one that is still in a corrupt state and we will try to force_unstake it fully in the next runtime upgrade: polkadot-fellows/runtimes#527 (comment)

There are probably more accounts that are affected. 59 is the count of accounts that had more than ED withdrawn from them.

We need to add a guide for wallets to this, explaining how they should adapt to this. For directs stakers, it is likely not a big deal as they are likely reading the ledger.total, and not inspecting STAKING_LOCK anymore. For pools, it will be substantial.

There are runtime apis to query pool and member balance. How should we promote it?

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/12815031300
Failed job name: test-linux-stable