Incorrect Slashing on Council Caused by elections-phragmen Pallet Bug

With the v26 runtime being in polkadot, a bug that caused immature slashing of candidacy bonds in council was fixed, and now's the time to proceed with refunding affected accounts.

Context And Problem

In the elections-phragmen pallet, each candidate has a life cycle with 3 possible stages, namely Candidate, Member or Runner-up. First, accounts can submit_candidacy(), and the pallet will reserve CandidacyBond. If the account makes it into the Members or Runners-up list, then this bond is kept. Else, a loser candidate will always lose their bond (slash_reserved()). Moreover, members and runners-up must also renounce_candidacy() in time. If they lose their spot in an election round (i.e. no longer hold any role), they also lose their bond as the consequence.

Due to an API confusion, we sometimes mis-calculated the outgoing runners-up, thus slashing them prematurely. Furthermore, we mistakenly slashed members and runners-up when they moved in between the roles.

This did not affect all accounts, but some bonds were taken by this error. The team discovered that the root of the issue was in the election-phragmen pallet. The bug is now fixed in v26 (and 2026 in Kusama).

We have gathered info about this in the last few weeks. Kian, from the Parity team, recorded a short video for transparency of what happened and how we intend to fix it.

• A more detailed write-up about the event, including details of how the refund is calculated and can be reproduced: https://hackmd.io/HZVxUWuKTHSVHdjRVtwE0g
• Spreadsheet of current calculated refunds: https://docs.google.com/spreadsheets/d/1dHch86flQ-yXw-BJcnjWLqND2nxOcp4p-hppcuD_DqA/edit?usp=sharing

Steps Going Forward

1. Discussion by the council, questions and comments on the incident;

2. Reimbursement of the affected accounts: The reimbursement process can happen in two ways:

• Tipping from the treasury pallet: Opening one tip per user for the calculated amount and requesting endorsement by council members.
• Wrapping all of the reimbursement calls inside a utility.batch, creating a single batch of force transfers from the treasury to the affected accounts, to be voted by the community.

Feedback on the steps going forward is welcome!