How Sequential Phragmén voting works

This is an explorable explanation of the Sequential Phragmén voting system (invented in the 1890s) currently used on Kusama and Polkadot's on-chain elections. You can modify these examples - create candidates and voters, adjust their voting stake (drag left and right or type) and add and delete votes to see how it affects the results.

This voting system is used for nominators to elect validators, as well as for the community to carry out council elections and referendums.

Example 1: One token = one vote

A simple example with 1 token per voter, with three candidates to elect out of four. As you would expect the candidates with the most votes (and tokens backing them) get elected. The process is an iterative one, each candidate is selected in a different 'round' of the election process, this is the number displayed in the elected column.

Example 2: Token weightings

The problem with having voters associated with accounts is that one person can control many hundreds of accounts, or a single account may indeed be owned by multiple people - there is no way (currently) to know this. Instead the concept is that the people with the most to lose (the highest amount of tokens) are given the most power - voters need to temporarily reserve some of their tokens to weight their voting. It of course comes with it's own problems, and it is acknowledged that the power of large stakeholders needs to be limited. We'll see in later examples how Phragmén voting as applied in Polkadot and Kusama tackles this in a couple of ways.

Here we see some voters with different stake amounts. The candidates with the highest stakes backing them get elected - but this doesn't always match the vote share. Try changing the stakes to see how it effects the election.

Example 3: Sometimes the stake is out voted

There is more to Phragmén voting than simply ordering candidates by the amount of tokens backing them. In this example we see some of the intermediate calculations (called voter 'load' and candidate 'scores') which change for each round of the election process.

With loads and scores the smaller the number the better, as it's the candidate with the lowest score in each round that gets elected. The Polkadot wiki has more detail on how they are calculated which I'm not going to go into here - we are interested in the effect they have on the results.

In a manner of speaking, the loads and scores redistribute 'success' between voters. Each time one of your chosen candidates is elected in a round, your voter load is increased for all the subsequent rounds. As this number increases, it reduces the influence of your votes on the candidate scores. We can see below a case where a candidate with a large approval stake loses out to one with a less tokens backing them - because the voters that chose it were boosted, as they hadn't had any other candidates selected.

Try changing the number to elect in this example to 3 - you can see the support for candidate 2 halves as the large stake from voter 1 has to be shared between candidates 2 and 3 if they are both succesful.

Example 4: Voter conviction

Another aspect that evens the playing field with regard to large stakeholders is to allow people to trade brute force "deep pockets" for time, using a conviction parameter. This is used only for referenda; and allows voters to lock their voting tokens for longer - multiplyingies their stake up to six times.

It's important to note that tokens locked for voting can be used for other things at the same time, other votes, staking, locked for setting on-chain identity for example. They just can't be moved to another account during the this time.

GPL3 source code