Switching to Ranked Choice Voting for the Multiple Choice Governance Votes

After some discussion in rocket chat, a few of us believe it makes more sense to use ranked choice voting (https://en.wikipedia.org/wiki/Ranked_voting) instead of the current first-past-the-post system. In particular the https://vote.makerdao.com/polling-proposal/qmxt6giqs42mxr4uskyxaunuw1ua4txwgtnxw4ogbuusht DSR vote is in a virtual tie between 2% and 4% with only 14 MKR separating the two as of the time of me writing this.

Personally I voted for 3% initially and later moved my vote to 4% after it became the localized winner within my preferences. I’m hearing that others do the same as well. I think it makes sense to be able to capture this sentiment and reach a compromise number if there is a half and half split like is happening now.

In terms of technical implementation, I think we can make this switch with only front-end changes. Current vote options seem to be encoded as a uint256 which gives us the option represent those 256 bits as 8-bit choices (255 options + no vote) with 32 choices available. (Maybe someone more familiar with smart contracts can correct me here if I’m wrong)

Also, I am a programmer, so happy to build out this change myself if Maker is strapped for dev resources.


:heavy_plus_sign:1 agree, awesome idea.

I also think this is a great idea, and mad props for figuring out a technical solution that requires minimal effort. That’s like the holy grail of development :wink:

I will say that ranked choice voting is a lot more complicated than it sounds though. Lots of methods have been generated to judge the winner of such polls. Wikipedia has some pretty good descriptions and examples of the various systems here: https://en.wikipedia.org/wiki/Ranked_voting#Different_types_of_systems

I think we’d probably want a Condorcet method. Ideally one of the Single-method systems. Unfortunately there is no ‘best’ choice, each system has various trade-offs.

I’m not super familiar with the trade-offs myself. If anyone is interested in doing some research it would be super interesting to read a brief paragraph summarising the popular systems.

1 Like

Granted, but I’d favor any rank choice system over first-past-the-post.

1 Like

Agreed! To clarify, I mean no best choice within ranked choice voting systems.

I’m working on a proposal with a small group involving delegating votes to representatives, and then allowing the top N representatives to vote on multiple options with Quadratic voting, which might actually be less computationally complex than ranked choice.

Correct me if I’m wrong, but isn’t the weakness of quadratic voting on the blockchain that it requires identity? That is, can’t I just split my MKR across many addresses to not suffer from the reduction when voting on a singular option?

For now, I think the ranked choice voting idea is simply trying to find a better way to lock in MKR holder’s preferences regardless of what other MKR holders are voting for. Put simply, it will allow you to vote your exact preferences on a topic rather than compromise or capitulate based on what others are doing. Most importantly, ranked-choice should not suffer from identity constraints.

NOTE: the executive voting process is not being discussed in this proposal. This is just an alternative to the current polling mechanism we are using.


Just a couple of things, 1) you still need backend work to do ranked-choice voting 2) quadratic voting is useless without identity.

edit: seeing @cmooney’s note, that makes more sense! Ranked choice for polling is a good idea at first glance. Sadly it could send contradictory signals since casual observers may expect the winning polling proposal to represent the winning executive proposal assuming nobody changes their preferences. That won’t be the case anymore, so that might be somewhat surprising to folks.

There is still backend work for sure, but I think Sam is correct that we don’t need to change the smart contract. We can just overload the uint256 for the option into 8-bit chunks that gives the user 32 possible preferences. I am not sure how well the logging system can handle this, and we would want to pull the index off the smart contract event, so we may just want to re-encode this as an array in the log; however, I did like the compact representation in Sam’s idea. If we can get away with it, it’s a reasonable hack.

1 Like

Quadratic voting sometimes requires identity (since one could game the system by splitting MKR holdings across addresses for more total votes), but if MKR holders delegate their voice share to representatives, and only the top N (say, 10) representatives (by total voice) vote, this would strongly discourage splitting. A mechanism of this type removes the need for identity.

It’s one potential method to smooth the voting distribution (improving decentralization), while decreasing the governance burden for the long tail of MKR holders.

I haven’t thought through all the details (ex: what if the top representative has enough MKR that splitting their holdings allows them to occupy two of the top N spots), but the upsides are promising.

I’ll start a different thread for this, since it’s more related to executive voting and general Maker governance.

1 Like

This isn’t a sensible context for quadratic voting. We’re not trying to give preference to public goods. We’re trying to maximize the future value of MKR.

1 Like

Quadratic Voting is an interesting concept, but I don’t think it really applies here.

Regarding the technical work, when I say only front-end changes are needed I am referring to non-smart contract code. And to re-iterate this for governance votes only, not executive (which would obviously require smart contract dev in that case).

Another method, that I’ve suggested a while back (7 months ago).

Wording could be changed to ‘up to 2%’, ‘up to 3%’, ‘up to 4%’. And the winning vote would go to the % with at least 50% support.

A benefit is that this might make more sense than ranked choice voting, when you’re voting for things on a sliding scale. And you don’t need a backend update, maybe some front end voting to show the current leader.

Heya, following up with a little documentation on the technical approach you suggested here https://observablehq.com/d/ae76dede35b840f4 Not the actual UI/ widget design – will have that soon (finishing up a little backend work first) – but in case you were interested :slight_smile: