phragmenElection.submitCandidacy reserved 100 DOT while phragmenElection.renounce unreserves 1 DOT

[Juanma0x]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Description of bug

Account's actions related to Council candidacy and DOT reservations:

• The account initially submitted its Council candidacy (phragmenElection.submitCandidacy, extrinsic) and reserved 100 DOT (event).

• After almost 3 years, the same account renounced its candidacy as RunnerUp (phragmenElection.renounce, extrinsic), but unreserving only 1 DOT (event). This action left 99 DOT still reserved, with no clear reason for this reservation.

The expected behavior would have been that once the candidacy to the Council was withdrawn, the reservation made would have been completely unreserved.

Steps to reproduce

No response

[bkchr]

The runtime upgrade to Polkadot 0.8.28 had the following migration: https://github.com/paritytech/polkadot/blob/371681c298eb96b74ad04a09ca8097f19c777e68/runtime/polkadot/src/lib.rs#L968

The second parameter to the apply function was the old CandidacyBond. It was passed as 1 DOT while it was actually in the release before: 100 DOT.

The result is now that you only get 99 unreserved, while it should be 99. This will need some governance action to fix this. The best is probably to wait until the next Polkadot runtime upgrade is applied, that will unlock all these funds any way and then write some script to find out which accounts are affected by this. Balances::force_unreserve could be used for this.

[Juanma0x]

I'll recommend the affected user to wait for the next runtime upgrade. However, could it be a problem that the account has already run the extrinsic that should have unreserved the funds?

Thanks, @bkchr.

[bkchr]

The next release will not fix anything for them, but then the pallet is removed and someone can start a governance proposal to fix up all these accounts.

[bkchr]

@liamaharon / @ggwpez could you work on a script for fetching the accounts that need to be corrected?

[ggwpez]

@liamaharon / @ggwpez could you work on a script for fetching the accounts that need to be corrected?

I am a bit mentally slow today, but I assume the script should sum up all Balances::Holds of an account and compare it with the reserved balance in System::Account?
One example of a bad account on Rococo would be 5CVJNNL34DB5HD32M7P8gZSKG6bzMtV6CJ4atrqJLLGzxrKx then:

It reports 756 of all 3843 accounts as bad.

[bkchr]

but I assume the script should sum up all Balances::Holds of an account and compare it with the reserved balance in System::Account?

Not sure we should fix up everything "blindly". The script we would need here for this case would scan everybody that was a candidate/runnerup and check that they go unreserved the amount that they got reserved back when they applied. Does that makes sense?

[liamaharon]

I have a script scraping all reserve / unreserves (https://github.com/liamaharon/phragmen-candidacy-reserve-scraper), it will net out any refunds we need to make when it is finished.

Current version works but is really slow, will take ~24 hours to finish scraping Polkadot 🙈 The delay is almost all latency because it does one block at a time. I've asked @josepot if there's any easy way we can batch fetch the extrinsics which should speed it up I estimate in the realm of 100x.

[ggwpez]

Maybe its possible to query subscan event api or something. Otherwise yes, querying one block at a time to get the events will be very slow and possibly rate-limited.

[bkchr]

I don't see any problem of it taking 24 hours. We will need to run this only once and not against any "moving target".

[liamaharon]

Quick update:

The eta estimation was way off and it would take too long to finish.

The problem is just network latency. I'm syncing a Polkadot and Kusama node so I can run the script on the same machine, will be much faster.

edit Jan 17: haven't forgotten about this

[liamaharon]

Affected accounts who received too few DOT when calling renounce, resulting in a 99 DOT stuck reserved balance:

14AgaKr2jYURm74azd4QKEXrDC4ZLg7nq7iae11dS7341QQq
1629Shw6w88GnyXyyUbRtX7YFipQnjScGKcWr1BaRiMhvmAg

@bkchr thoughts on whether it's better to fix these via runtime migration or governance?

Note that it's possible more accounts never called renounce but were not refunded enough when we removed the Phragmen pallet.. Unclear whether those cases, if they exist, are important given the users never called renounce after many years. But noting it in case someone brings it up in the future.

[bkchr]

Using governance with force_unreserve should be fairly simple for this. IMO the rule should be that if there already exists a call and it isn't about 1000s of accounts to be fixed, we should use governance with the call.

[liamaharon]

Referenda fixing this https://polkadot.polkassembly.io/referenda/474