Signal Request: Add Ranked Choice Voting as an Option for Governance Polls

Continuing on from here into a signal poll.

I would like to add ranked choice voting as an option for governance polls to prevent situations like what is currently happening in the DSR Spread reduction thread with multiple winners. The issue comes up that if we add a poll to the governance portal that has more than 2 options then we run the risk that a minority option ends up winning out over the majority-preferred options. For example, if we were to vote on a DSR Spread reduction poll with 3 options and get the following results:

  • Status Quo (4k MKR)
  • 2 weeks (3.9k MKR)
  • 1 month (3.5k MKR)

In this case the status quo wins, but perhaps the majority wants either 2 weeks or 1 month. There is currently no way to express this in a single poll.

What I propose is adding an option to run polls as ranked choice polls with the ability to select your 1st, 2nd, 3rd, etc favorite choices in order. See for a more detailed explanation. As @LongForWisdom said in the previous thread there are multiple ways to determine a winner with ranked choice.

The main options are:

Instant run-off (IVF)


Ballots are initially counted for each voter’s top choice. If a candidate has more than half of the vote based on first-choices, that candidate wins. If not, then the candidate with the fewest votes is eliminated. The voters who selected the defeated candidate as a first choice then have their votes added to the totals of their next choice. This process continues until a candidate has more than half of the votes.


  • Simple to implement
  • Simple to reason about to the user


Condorcet Method


A Condorcet method is one of several election methods that elects the candidate that wins a majority of the vote in every pairing of head-to-head elections against each of the other candidates, that is, a candidate preferred by more voters than any others, whenever there is such a candidate. A candidate with this property, the pairwise champion or beats-all winner, is formally called the Condorcet winner.



  • Algorithm is more complex to implement
  • Not obvious to the end user why a candidate is winning

Positional Method

This is a generalized version of Borda Count where each ballot gets some weight. Due to the constraints of the data this will not fit in the 32-bit integer implementation I wrote below.

Borda Count Method


The Borda count is a family of single-winner election methods in which voters rank options or candidates in order of preference. The Borda count determines the outcome of a debate or the winner of an election by giving each candidate, for each ballot, a number of points corresponding to the number of candidates ranked lower. Once all votes have been counted the option or candidate with the most points is the winner. The Borda count is intended to elect broadly acceptable options or candidates, rather than those preferred by a majority, and so is often described as a consensus-based voting system rather than a majoritarian one.


  • Easy to implement
  • Easy to reason about to the end user



I’ve looked over the Governance Portal code, and this looks to be a pretty straightforward change (the devs can correct me here if I’m wrong). We are already using an integer (256 bits on-chain and 32-bits in the JS code) to store the vote number. If we only want to use the 32-bits then we can encode 4 bits per option (max 15 options on a poll + no vote) and give you 32 / 4 = 8 choices available. The bitwise position in the integer can give you the rank choice. IE the lowest 4 bits indicate first choice.

The nice thing about this implementation is that it is backwards compatible with the current first-past-the-post system.

  • Do not add support for ranked choice voting
  • Add support for ranked choice voting with the Instant-runoff method to determine the winner
  • Add support for ranked choice voting with the Condorcet method to determine the winner
  • Add support for ranked choice voting with the Positional method to determine the winner
  • Add support for ranked choice voting with the Borda Count method to determine the winner
  • Abstain (I want to see results)
  • Abstain (I have no opinion)
  • Abstain (I don’t feel I am knowledgable on the subject)
  • Abstain (I disagree with the poll options)
  • Abstain (I have a different objection)

0 voters

This is a multiple choice poll, vote for everything you are willing to vote for in an on-chain vote. Poll will close on February 27th, 2020 at 11:00 AM EST to be reviewed during the weekly governance call.


I believe @Derek is one of the people involved in the voting portal. Pinging him for visibility.

1 Like

I agree with the flaws of first past the post.

I’m not sure why there hasn’t been traction for median. Maybe it’s because there hasn’t been anyone else lobbying for it, or people think it seems too simple. But there’s quite the elegance in the math and game theory behind it.

Regarding taking the median vote (weighted by mkr), you might think it’s too simple since voting will be the exact same. But the end result is the fairest compromise, right in the middle.

Ranked choice voting can get quite complicated game theory wise (There is always tactical voting), and deciding which method is the most ‘fair’. Anyways, I support ranked choice voting over the current system.

Assumptions: Single Peaked preferences vs Multi Peaked Preferences (someone preferring both 1 month and status quo over 2 weeks).


I prefer rank choice voting to median because each voter can provide more information about their desired outcome. This is especially important for our community because of small sample sizes. Median and rank choice voting might obtain similar results in large samples, but we’re trying to deal with votes where less than 5% of MKR is voting. You want to collect as much preference per voter as possible.


Actually that would be great mechanics for governance polls on good example is what recently happened in DSR SPREAD poll, swings for a ‘lesser evil’ at the end of a vote. If You can select multiple preferences in order You can quite clearly show your preference in one vote.

But that would actually need a change in polling smart contracts i guess


Added some summaries to each of the methods. Personally, I am voting for IVF as it’s simple to implement, reason about and provides most of the benefits we are looking for with minimal drawback.

UI implementation can consist of multiple dropdown menus that appear and disappear as you vote. IE initially you have 1 dropdown, then if you select an option a 2nd one appears below. If you select a 2nd option then a 3rd one appears, etc. There should never be more then N - 1 dropdowns for N options on a poll.

For IVF results you can display it like this:

Alternatively you can show condensed intermediate rounds if by chopping off multiple options that have < 10% of the vote or something. For example in the above case remove Option 3 and 4 at the same time to save space.


This is a well written post, and the summaries of each voting method are very useful. In addition, you’ve made it clear that this signal is to Add ranked choice as an option rather than moving to ranked choice for any particular poll. The difference may sound small, but it’s important that we see the implementation before green-lighting it’s use in polls. Thanks @hexonaut for producing this.

Based on the summaries and some background knowledge of voting methods I’ve voted for the Condorcet and Borda Count methods. I would argue against instant-run-off based on the fact that it doesn’t eliminate the spoiler effect. MKR Holders should be sure that their voting for their favourite (unpopular) option isn’t going to reduce the chance of an option they find acceptable taking victory.

The Condorcet method is able to find the best option if one exists, which makes it one of the better methods, however the downside is that it’s calculation is not trivial. I would still find it acceptable, but I’d prefer the Borda Count method, furthermore, I think everyone else should do, mainly because:

This is a huge point in favour of the method! In my view it’s incredibly important that as a group MKR Holders don’t fracture into a conflicting system of parties, votes should not be seen as a competition, but as a collaboration. The way to ensure this is to focus on ‘most acceptable option’ rather than ‘most preferred option.’ This is the same reason I have been advising everyone doing signal requests to allow multiple votes, because it does this exact same thing, pushing the focus from ‘most preferred’ to ‘most acceptable’

Also @hexonaut I don’t think this con:

… is accurate. The issue is in the word ‘supported.’ It should be ‘preferred’. It’s not guaranteed to give the preferred result if it has a majority voting for it, but it should instead result in something that is ‘supported’ (ie ranked fairly highly) by a larger group.

In addition to it’s ‘Con’ being it’s greatest strength, The Borda Count method is also easy to implement and reason about.

One con that I would highlight for Borda Count is that it is that it is more susceptible to tactical voting that some of the other methods (although no method is entirely immune.) This could become a problem if the ‘political landscape’ of our voting becomes very competitive.

1 Like

I’ve removed the Borda Count con you mentioned. You are right it is not an obvious con, and in fact your point about the most acceptable answer is maybe more what we are looking for in this protocol. I’ve added Borda Count to my vote based on your argument.

I’ve also edited to add the spoiler effect to IVF, but I still don’t think it is enough of a problem to move my vote away from IVF.

I still don’t like Condorcet because it is complex to reason about for the end user. I think it should be obvious which option won and why.


Sorry @LongForWisdom - I am generally on your side in governance things, but I think that the evidence suggests that Borda is more susceptible to tactical voting than IVF…

“My scheme is intended for only honest men” (lol, but huge love for that French guy! very much my kinda idealist) vs “this mostly seems to work, can sometimes be a little wonky, and has alternatives like Tideman”.

Also, worth thinking about these different options in the context of continuously running polls, no? Again, Borda would seem to come out worse there: as more people get used to which options are generally being picked, they can bury and/or compromise much more effectively.

1 Like

I agree, but I don’t think it is worth discounting based on that fact alone. In almost all other ways it’s ideal. If we implement it and tactical voting becomes a problem we can always revisit. We shouldn’t assume tactical voting will be used, especially when MKR Holders are aware that:

  1. We view it as abuse of the system.
  2. Votes are publicly visible.
  3. Everyone is on the same team.

Regarding the context of continuously running polls, I think it’s difficult to judge the outcome. It might be that tactical voting happens more in continuous polls, but it may also happen less. Because everything is public, other voters can react and respond to tactical votes. It could be that they are too much of a risk to be worth doing, because methods require you to vote contrary to your preferences. If you do this and it’s public, others can react in ways that make your tactical vote a liability.


Great to see a positive response for this suggestion - I am also in favour of ranked choice voting for polls. Initial investigation with the smart contract & development team indicate that this is technically possible to support using the existing contracts.

@hexonaut is correct that there will be frontend UI work to represent the new selection options as well as some necessary modifications to the GovQueryServiceApi to treat OptionIDs as a 32 byte array of ranked options - there is some work there but it is all feasible.

A formal poll would confirm that this is something the community is truly interested in, following which we would dive into prioritising design/requirements/development work.


Quick update: Talked with the Maker dev team about this, and we are good to proceed with a vote however, due to recent market events, I will be waiting to add this as an on-chain poll until after the dust settles.


Submitted a PR for @rich.brown to review:


Thanks Sam.

The content of that poll states that “If this proposal passes, all future governance polls will allow for ranked choice voting.”

What does ‘allow’ mean in this context? Are all polls ranked choice or only some?

Have you confirmed from the development team that they will be able to code this and update the portal in 7 days?

@Derek Thoughts about timelines?

1 Like

Currently the Dev Team are finishing SCD Global Settlement tasks (SAI and collateral redemption). We should be finished this week. I expect we can start on ranked choice at the end of the week.

As per Rich’s comment, let’s confirm expectation for all polls being ranked choice or only some?

Josh, Cmooney and I are looking forward to getting this one rolling!


I’ve reworded the next steps portion to be more clear that is in an option and not a forced requirement that all polls run as ranked choice. Also, as it was phrased there is no 7 day timeline, so I cleared that up.

New Text: “If this proposal passes, the governance portal development team will begin work on adding support for instant run-off ranked choice voting to the governance portal. Once development is completed, any future poll author will have the option to run the poll as ranked choice.”

Let me know if anything is still unclear.


Update: The on-chain poll passed on Friday with 65k MKR (99%) voting yes. I will update this thread once @Derek informs me that the work is done and ready.


Thanks @hexonaut , we’re making a start this week, hope to have something for you to demo soon!


Bump. We’re still looking forward to this! Any updates, kind sirs?


Update: The dev team has completed work on ranked choice voting. This thread can be closed now. @LongForWisdom

1 Like