Preamble
The ENS DAO has never shied away from experimenting with governance and learning from it. Steward Elections use approval voting, the choice for Endownment Manager was a ranked choice voting, we even had a novel knapsack algorithm to select Service Providers. The crypto space has been lucky to be able to experiment in practice what are often academic debates on governance that could take decades in politics. What we learned from these past experiences:
- Ranked Choice Voting is a better choice for expressing user opinions. While Approval is better than a simple FPTP vote, it leads to some undesired results: voting on too many candidates is the same as not voting at all, and the binary choice makes it easier to pressure delegates (âplease also approve meâ is an easier ask than âplease rank me as you number oneâ)
- Instant Run-Off Voting has fallen short of our expectations. The result is a black box where itâs quite hard to understand the full context of the vote (without some complex sankey charts) and it can be quite unpredictable but most importantly, it fails to deliver itâs main allure: avoid polarization. In an election dominated by two very opposite candidates, a more moderate third candidate will be eliminated on the elimination round and the election will fall back to the two main adversaries.
IRV is often used interchangeably with RCV as if theyâre the same but theyâre not. The first is about how you vote, the second, how you count the votes. There are uncountable other algorithms that, given ballots with ranks, can be used to pick a winner. Thereâs a whole category just for Condorcet systems, which are algorithms that will attempt to put run all possible one to one matches and pick the candidate who would win all of them (if such candidate exists). An issue with many of these is that, like IRV, explaining how these systems work can be hard and it feels like a black box where the result is inscrutable. Iâve written more about that challenge.
One crucial factor for us is that our governance happens all in the open, over a long period of 5-7 days, and the ongoing result can be seen on a small column in snapshot. Delegates can change their mind at any point during the period, often based on the ongoing result or social pressure. For that reason, itâs important that at any point someone should be able to easily follow the current stage of the vote, and how it can be influenced, in the simplest form. Another important factor for us is that often we run elections with more than one possible winner, so the result must be able to rank all candidates, no only pick one winner. For that reason, we have picked the Copeland method as the desired method for governance in the future.
Explanation of Round-Robin / Copeland
This RFP is for someone to implement Roundrobin style ranked vote system, AKA Copeland Method. One of the main reasons we are preferring this is it leads to a simpler UI which will be familiar to anyone who ever watched a sports tournament, since itâs the logic behind sports league tournament. While technically Round-Robin and Copeland have slight differences when dealing with ties (which is rare for a highly divisible token) we will be calling the method Round-Robin since itâs a more self explanatory name.
If you have followed any league sports competition, like UEFA, Conmebol, NFL, MLB, NBA, etc, then you already know how Round-robin voting works. Only difference is that all individual matches are replaced by a ranked ballot. That familiarity is an important part of its appeal.
Specification of the algorithm:
- The ballot should allow the voter to rank any amount of candidates. A clear line (labeled âNone of the Belowâ) should differentiate candidates who were ranked or not in the ballot. A vote with no ranked candidates is a valid vote (although, a good UI should try to confirm if it was not an error).
- All candidates are compared head to head, and their absolute number of votes will be displayed. In a match between a ranked and unranked candidates, the unranked automatically loses. In a match between two unranked candidates, the ballot will not count to eitherâs total vote in that match.
- All matches are calculated and displayed sorted by absolute number of votes. Each victory awards 1 point, ties or losses award 0 points
- The Average Support for each candidate will also be calculated: itâs the sum of the absolute votes each got in each match (on either side), divided by the amount of matches it was featured in. Average Support is used as a tiebreaker. If all a candidate received was 100k votes ranking them in 1st place, their average support should be 100k. Some elections might want to set a minimum âaverage supportâ as an exclusion criteria or quorum.
While None of the below should neither score or rank, itâs average support should also be calculated and displayed on the results table. Depending on the rules for that particular election, it can be used as an exclusion criteria or minimum quorum.removed this section as unnecessary.
An example of how it all could be displayed in a Snapshot UI is below. We believe that althought the system can be complex under the hood, its output is quite clear. Itâs easy for anyone to follow along what is happening now and what could happen in the future. In the example below, Charlie is ahead, Aliceâs best strategy is probably to compare herself favourably with Charlie, but Bobâs best strategy is to compare favourably against Alice.
Request for Proposals
We therefore request developers who would be willing to improve ENS governance by implementing this option. Requirements:
- must be compatible with Snapshot. Either itâs a direct PR on the Snapshot side (acceptance by snapshot is a responsibility of the developer) or itâs compatible with Snapshot (for example an alternative UI for Snapshotâs existing Ranked Choice Voting)
- must implement an UI in which the user will somehow express their opinions of all candidates (with the option of NOT expressing opinions about some of them). An acceptable default would be a simple drag to rank, but we would consider other alternatives.
- must implement an UI showing the resulting calculation in real time, similar to the example above.
Payment would be split in milestones, with the last one being delivered when the option is live on snapshot (or another site compatible with it). The selection of the developer for this will take in consideration their past record of contributions as well as their asking price and proposed timeframe.
If youâre interested in participating, please leave a comment or contact us via DMs so we can arrange to analyze proposals.
This RFP is a suggestion for an improvement for the future of governance. Itâs not a suggestion on how the next governance decisions should be made.
