[Update #2] Poll Outcomes - 2020-11-19

Update #2

Given the true result communicated by Derek and verified by multiple people still does not reach a majority, a stability fee change for stablecoins will not move forward to the executive this week.

More details as to the rationale of this decision can be found in my response here.

Update #1

So as it turns out this may not be as straightforward as it initially appeared with the Stablecoin poll. I’ll be providing a further update tomorrow morning. At this stage you should assume that my initial post below is not the last word on the issue.

Original Text (Contains Incorrect Information)

This weeks polls revealed an issue in the new voting portal that lead to an incorrect distribution of votes being displayed on the ‘Lower Stablecoin Stability Fees’ poll to the point of it showing an incorrect result.

The correct result can be viewed here, on the older version of the voting portal.

This issue effected ranked choice polls only, and I’ll let @Derek comment on the issue itself in this thread.

I will now confirm the polling results here, and explain what the outcomes mean for this weeks executive:

Adjust the YFI-A Debt Ceiling

  • Plurality Vote, unaffected by the issue.
  • Passed
  • Included in this weeks executive vote

Monthly MIPs Governance Poll

  • Plurality Vote, unaffected by the issue.
  • Passed
  • Included in the monthly executive vote on Monday.

Adjust the Dust Parameter

  • Ranked Choice IRV Vote, was unaffected by the issue given the distribution of choices.
  • Outcome matches between v1 and v2 portals.
  • 500 DAI is the winning option.
  • Included in this weeks executive vote

Lower Stablecoin Stability Fees

  • Ranked Choice IRV Vote, was affected by the issue given the distribution of choices.
  • Outcome differs between V1 and V2 portals. The V1 portal shows the correct, canonical outcome.
  • No option has a majority.
  • No stability fee change will be included in this weeks executive vote.

I’m aware some of you were hoping for a different outcome from the stability fee poll. @Primoz and I discussed putting a compromise option in this weeks executive, but after deliberation, decided not to proceed.

Our reasoning is as follows:

  • The poll itself strongly implies that a majority is required for change in the ‘Next Steps’ section.
  • @LongForWisdom does not feel that the the Governance Facilitator should be interpreting poll results to the degree that would be required to include the change in the executive. People had the ability to vote for multiple options but they didn’t. I can’t assume that they intended to do so but voted incorrectly.
  • @Primoz does not feel that the stability fees represents an urgent or emergency issue at the current time (at least not to the point where he feels the need to include a change in this executive.)
  • The potential lost value in the event of burning MKR and then being forced to mint MKR due to this issue is small, and grows over time at a slow rate rather than occurring all at once.
  • DAI remains fully backed for a reasonable period (months) even after the first stablecoin vaults drop below 100% collateralization ratio due to the DAI in the surplus buffer.

I would like to encourage all MKR Holders who voted in this poll to consider submitting more choices in ranked votes in the future. If voters are unwilling to compromise, it is possible that the result will end up worse than the compromise options, as we saw in this poll.


The way the Votes are displayed in the “Correct” results is not how ranked choice voting is supposed to work in my understanding.
The votes that selected only 2, 0 or 4 and didn’t select other options need to drop out entirely. Then between 1% and 3 %, 1% has a majority and won the poll.

1 Like

Yeah, I voted for 1% but will take that into account for next time, thanks LFW

1 Like

Thanks for your work @LongForWisdom.
We are lucky to have you as facilitator. :pray: :pray: :pray:

1 Like

The announcement was very timely, thank you LFW for its serious and responsible spirit in its work.

Hi all, an update wrt the frontends and the role they played in the above confusion. Alongside Sam’s spreadsheet, the development team reviewed on-chain data confirming this week’s Stablecoin Poll:

In round 1: option 6 (something else) was eliminated with no votes
In round 2: option 2(3%) was eliminated
In round 3: option 4(1%) was eliminated
In round 4: option 1(4%) was eliminated
In round 5: option 3(2%) was eliminated leaving option 5(0%)

The winner at round 5 was option 5 (0%) BUT it did not have majority.

Note, RCV has always calculated the majority as including all initial participants & MKR weights - we take the ‘whole pie’ throughout all the rounds.

Note, there were frontend UI problems that added to the confusion of this poll:

  • It was discovered that the old portal was doing an extra (6th) round of elimination in order to try and get to a majority when only 5 rounds are necessary. I believe single vote choices were the reason for this incorrect behavior - where the system attempted to determine majority where none existed.
  • A further point of differentiation is that the old portal doesn’t include an abstain value as presented on the newer portal, thereby leading to a different unique voter count.
  • The new portal had a recently introduced bug causing incorrect vote transfers between rounds.

Next steps:

  • Improvements are currently being made to the new portal to correct the vote transfers issue between rounds. This issue does not affect previous polls.
  • The old portal will be updated to perform the correct number of rounds
  • A ranked choice guide and explanation will be documented for better awareness and understanding.

I apologise for the confusion that the front end discrepancies caused in this instance and will work with the development team to update.


So after giving this some more thought and now that we have the real results displaying in the portal, I think we basically have two arguments being made that I saw in the chat:

  1. Majority in IRV means using the vote total for the remaining votes after discarding votes for options that have been eliminated.

I disagree with this point. We have never done governance polling this way, and I don’t think we should start because it is convenient for this particular vote. I think you can see why this is the case if you change the vote from a parameter adjustment to something of the form:

Option A - Contentious Action A
Option B - Contentious Action B
Option C - Do Nothing

In this case let’s say voters are polarized to a particular option and really really do not like the others. So in that scenario voters would select 1 option and only 1 option. We effectively get first past the post, and I agree that the default here should be to Do Nothing if no option gets a majority. No amount of Ranked Choice IRV can solve this for us.

  1. Making the observation that those who voted for 0% probably prefer 2% to 4%, but they forgot to add additional options.

This second point I think is much more on the mark, and really I think this applies to any poll where we are adjusting a single parameter from the status quo to some end value. This is a case where it does make sense to vote for nearly every option. If you support 1% you probably prefer 2%, 3% over 4%. I was hoping the voters would all do this, but my guess is that they simply forgot to add all their choices or maybe it was unclear in the UI.

I think the guard against these sort of human-level errors we may want to consider using a different metric to pick a winner in these scenarios which I call the “Most Conservative Majority”. This would be the option that is closest to the status quo where there is a majority of support at that option or further away. In the case of the SF reduction vote this would 2% which has 81.45% support at that number or below. I think this is a good way to encode the rightly perceived disconnect between the technical result (leave it at 4%) and what a majority of governance likely wants us to do (lower by some amount).


Completely agree with this assessment.

While I think the above is appropriate perhaps since we are reworking DssGov I think we will have to consider not just the mechanics of voting, but that voting itself IS inherently designed to resolve one way or another. From what I can tell in both the old and current system voting can resolve to ‘no action’. I agree it is important to educate voters, regarding how their votes affect the system. I also think some consideration of votes resolving to something (do something that is reasonable, vs. do nothing because voting could not muster a decision) needs to be considered in any upgrade.

I believe the choices and details of the failed poll were sufficient to resolve to a result particularly if people paid attention and voted. While much of the putting together polls is part of the GF job, as well as interpreting results I think a clear system to do that for everyone is important. What I am seeing is this dichotomy of well I looked at the polling and this is how I ‘interpret’ the results. We want a system that is designed so no such interpretation is necessary. Something wins or it doesn’t and I think honestly if there is a goal here it is to make it clear to everyone the rules of poll result interpretation so there isn’t any debate over the results. Ever again.

Talk about changing the process, the mechanics of polling/vote resolution, change it but lets make sure we all are on the same page regarding how governance works and where it can’t work. (i.e. if voters are split in multiple ways well then inaction is the result). Give we are working on a new upgrade I think now is the time to speak up if anyone has any changes like the one posted by @hexonaut so we can define an implementation and discuss the pros/cons of the change.

Wanted to thank @hexonaut for collecting the data @LongForWisdom for his tireless dedication to accruacy, truth and nurturting MakerDAO governance generally, and @Derek for update on the specific issue and work improving portal UI and voting generally.

Things may get messy but when we all work as a team to achieve common goals it is amazing what we can do.


I would be more likely to agree if we were talking about a vote with immediate executive impact. But this is polling, we are just deciding what to offer as an executive. In your example, Contentious Action A or B would be proposed – but if really contentious, it won’t become the hat anyway. There is always the choice to do nothing by not approving the executive proposal. So it really makes sense to poll, take whatever is most popular (unless “do nothing” is most popular) and offer it as a proposal.

I was ignoring bundling here, just focusing on the goals of ranked choice. As long as executives are a scarce resource though, I agree that it’s more complicated. And I don’t really have a strong opinion there.

So again not considering executives as a scarce resource, the whole “the result computation code doesn’t understand the semantics of the vote options” goes away if you force everyone to rank everything, which makes no difference with the current method as soon as you treat leading options as winners in ranked choice.

This is fairly ad-hoc but until we have a cleaner system in place I’m not unhappy with that.

I think this is also a good place to copy part of a message I sent to Long, back in February of this year :


Given the true result communicated by Derek and verified by multiple people still does not reach a majority, a stability fee change for stablecoins will not move forward to the executive this week.

There was some debate yesterday about this decision in the official Maker Chat, and there were a lot of arguments thrown around. To those that weren’t involved this response may seem excessive, but I do want to make it clear why I’ve made the decision that I have.

I’m going to run through some context first, then answer some of the questions that had a factual unambiguous answer. Finally I’m going to comment on some of the arguments I heard made yesterday divided into those that I feel have merit, and those that don’t.


Instant Run-off Voting

When Instant Run-off Voting was initially voted for the description given was this (which was sourced from wikipedia):

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.

This statement is also sourced from wikipedia, and comments on the varying implementation of IRV.

The mechanics of the process are the same regardless of how many candidates the voter ranks, and how many are left unranked. In some implementations, the voter ranks as many or as few choices as they wish, while in other implementations the voter is required to rank either all candidates, or a prescribed number of them.

This statement is the one I included in the ‘Next Steps’ section of the Stablecoin Stability Fee poll.

If a result gains a majority of votes, the Stability Fees for USDC-A, TUSD-A, PAXUSD-A, GUSD-A will be lowered in Friday’s executive.

Factual Answers

Ranked IRV should not end in a stalemale.

This is correct. Ranked IRV does not end in stalemates. This is possible because it does not guarantee that the chosen result has the support of a majority of the total voters.

In the referenced poll, the outcome of the IRV vote was 0%.

Ranked IRV should force voters to rank all options.

This is not true and depends on the implementation. The implementation we have been using does not require voters to rank all option by preference.

Ranked IRV was introduced to prevent the status quo from winning when the majority of users want something else.

This was one of the goals of introducing IRV, and IRV does facilitate this. Indeed, as stated above, it does guarantee an outcome. Critically though, it does not guarantee an outcome that has a majority of the total votes.

Status Quo was an option in the poll, and didn’t win, why is it the default?

Status Quo is the only consistently applicable default across multiple polls. The Governance Facilitator should not choose the default outcome for specific polls, in my view, as this allows them to increase the likelihood of outcomes that they favour.

Why did the Governance Facilitator add the statement requiring a majority of the total votes?

I added the statement above to the poll because of the nature of Approval Voting in executive votes. Executive votes require that more people support the new proposal than the status quo. Ultimately, the result of the IRV poll needs to be confirmed by a majority in an executive vote. If we were able to put up executives that were not bundled, this would not be a problem, because the approval vote would resolve to status quo anyway if the majority did not like the poll result.

However, we are currently required to bundle executive votes due to how DSChief works. This means that a single contentious poll has the potential to prevent the entire executive from passing. The chance of this happening grows if there are multiple contentious polls. Now, it is not certain that this will happen, it’s not necessarily even likely. But it is more likely to happen if we include the results of IRV polls that do not end with a result that the majority of voters favour.

The reason it’s so important that the executive passes is also related to bundling. If a single executive fails, it means that the contents need to be evaluated to attempt to understand why the executive has failed. Any contents that are not deemed to be an issue will move forward to a future executive (potentially after further polls.) Already this is not great, because it creates additional work for governance and the mandated actors. However, it’s worse than this because the problem has the potential to stack. If we fail an executive, it makes it more likely that we will fail the next executive as well (because there is a chance that we inadvertantly include the true reason MKR Holders voted against it in a subsequent executive.) If the second fails, the third will have the bundled contents of multiple weeks, possibly including new results that are also contentious.

However, if you move the majority requirement to the initial poll, rather than the executive vote, you reduce the chances of executives failing to pass to close to zero. The cost of this is that sometimes IRV polls don’t result in changes proceeding to an executive vote.

Does requiring a majority of the total votes allow people to hold the process hostage?

Yes, but no more than was already possible due to the majority requirement of the Approval Voting process we use for executive votes. People can already hold the process hostage by not voting for an executive. The effect of requiring a majority moves the potential hostage taking to a place where it will cause the least disruption.

Fair points

There wasn’t a reason to make this poll use Ranked IRV

This is a fair point because to be frank the decision making process for deciding whether a poll should move on-chain in IRV form or Plurality form is not well defined. The general rule of thumb is that if the forum poll does not result in a majority result, then we put the poll up as IRV. However, I normally leave the final decision up to the author of the signal poll unless I have strong reason to believe that it’s a bad idea. I didn’t get that in this case, in retrospect, perhaps I should have insisted on a Plurality vote.

The reason to use Ranked IRV in this case is to allow MKR Holders the freedom to express their preferences more precisely.

Does the Governance Facilitator have the authority to add requirements to polls for them to move into an executive vote?

Good question. My view prior to this was obviously yes, otherwise I wouldn’t have included the statement. In practice, I’m expected to review and have the final say on the poll wording, this gives me a ridiculous amount of power to write whatever I want. Unfortunately, the practical point is that someone needs to have the final say on the content of the polls. Allowing the author to have final say doesn’t seem advisable to me, as it means that they can insert bias into the wording. It would also mean the polls become even more inconsistently worded than they are currently.

The ideal mitigation to this is to have multiple Governance Facilitators and require them to reach consensus on the wording.

But MKR Holders should vote in the executive even if it contains things they don’t like.

Yes, they probably should given the issues I described above. However, this is transferrable to the polling votes as well. MKR Holders had the ability in this polling vote to express their willingness to compromise in the executive (by ranking all options.) They didn’t do this. Some argued that was because voters did not understand the voting system. I’ve addressed this point below.

Was the wording of the statement requiring a majority ambiguous?

In retrospect this could have been worded to be less ambiguous, and in the future I will attempt to make sure there is no room for misinterpretation. The ambiguity with this statement is centered around whether the ‘majority’ refers to a majority of the total voters, or a majority of the ‘shrunk pie’ voters that remain after the final round of IRV.

However, I don’t believe that the natural reading of this statement favours the ‘shrunk pie’ reading for the following reasons:

  • If the author of the statement wanted to express that the outcome requires a majority of the shrunk pie, there is no need to include this statement. IRV always resolves with a majority of the shrunk pie.
  • If the intention was that the winning option would continue to executive regardless of if it had a total majority, the author would have used the word plurality as this matches how the UI displays the vote outcomes.

For the record, I wrote the statement with the intention that the poll require a majority of the total voters in the poll.

Less fair points

It’s almost certainly MKR Holders forgetting to choose multiple options.

This is not certain, or even necessarily likely. We have had IRV voting for some time now and we’ve used it for significant votes in the past. The Vault Compensation poll saw 87k MKR voting, many of whom used the ranked choice functionality.

That said, it is possible that this contributed to the issue, and in the future I will ensure that there is a clear explanation of how to vote depending on the type of poll.

It’s clear none of the voters know how Ranked IRV works.

As above, this is not necessarily clear, for most of the same reasons.

Once again though, it could have contributed to the issue, and in the future I’ll make sure there is a clear explanation in the poll.

Why is this result decided by one guy, the Governance Facilitator?

In the event of ambiguity some person or group needs to have the authority to make a decision on how to proceed. This authority most naturally falls to the Governance Facilitators.

The downside to this is that at the current time, Maker Governance has only elected one Governance Facilitator which means that this authority falls to one person (me.) This leaves me in the unenviable position of making the decision. If Maker Governance wants someone else to make those decisions, they can express that wish via a subproposal under MIP0c13.

A majority of Maker Holders voted for some reduction so we should make some reduction.

While this may seem like a valid point, in practice it isn’t due to the nature of IRV.

The reason for this is that voters in the poll had the ability to choose compromise options and didn’t. The Governance Facilitator saying ‘A reduction of 0% is fine’ directly contradicts the preferences expressed by voters because they were able to express willingness to compromise on any reduction by ranking all reduction options in the order of their chosing. A majority of voters in this poll did not do this, which indicates an unwillingness to compromise.

Now, it is possible that voters did not understand how to express their preferences, and I will be making sure this is more clear going forward. However, the Governance Facilitator cannot look at the results of the poll and say ‘Well, you expressed this preference using the tools available to you, but actually, I think you really meant this instead because…’

I really hope it’s obvious why the Governance Facilitator shouldn’t ever do this.

We voted in Ranked IRV, what we’re doing isn’t ranked IRV.

The poll implements IRV correctly (now that the frontend is fixed.) This is an IRV poll and IRV provided a victor (as it is guarunteed to do.)

The Governance Facilitator inserted an additional requirement for the poll to move into this weeks executive (at the point the poll was written, not post-result.) In my mind this makes this IRV with an additional requirement that is implied by the approval voting process that determines a winning executive vote.

The executive process is separate from the polling process and shouldn’t factor into it.

I agree that the executive process should not factor in to the polling process. However the reality is that at the moment, it does factor into it for reasons discussed above about bundling executives. With the introduction of DssGov this will not be the case, and we can relax the requirement for a majority outcome to move to executive.

Given the wording of the statement requiring a majority the Governance Facilitator should choose what is best for the Maker Protocol.

This essentially boils down to: ‘You have an excuse to choose a better result (minor ambiguity in the majority statement) so you should take it.’

Better is subjective, it’s not the Governance Facilitators job to decide what is best for the Maker Protocol or MKR Holders. The Governance Facilitator’s job is to ensure that the process of governing the protocol is as smooth as possible. Obviously I’m letting you all down here, but the solution is to improve understanding, education and processes. The Governance Facilitator’s choice of outcome must be based on the process and intentions that went into the poll, rather than what is the ‘better’ outcome for the protocol.


I want to say thank to @LongForWisdom for the clear post and for providing strong leadership in the face of intense criticism and backlash here and in the chat. I admit I thought the poll would resolve with a “plurality” but I completely understand the confusion. I now agree that the way the poll was worded clearly aligns with the “majority” interpretation. I think it sets an important precedent that we try to honour the poll wording even when it leads us to challenging situations like this.

I do understand the argument that a Governance Facilitator should implement a compromise reduction to the SFs based on the expression of the voters that they at least want something less than 4%. It could make sense here given that we were polling for a stability fee rate and it is easy to determine the directionality of the voters’ sentiment. However, as @hexonaut pointed out, RCV can be used for other more subjective proposals as well. If we encountered this problem in that circumstance it may not be easy to interpret the directionality of non-numerical votes. We could not “compromise” by going with the plurality.

Given the wording of the poll, our ongoing challenge with bundling, and the fact that reducing the stablecoin fees is not an emergency, I think LFW was left with little choice here and I very much respect his handling of this difficult dispute. We are lucky to have him (please don’t leave us :pray:).

I’m thankful that this issue arose now and not when we were trying to put out a more serious fire. How we move forward from this will only make our governance processes stronger.


I think he/she does, but in this case, additional requirement/wording was changing the voting system. Which was voted on in April. I think this was a mistake, since i doubt majority of voters read polls very carefully, so the change was not transparent.

I don’t think it’s a big deal though - such unpredictable situations (different interpretations) were expected to happen. It’s governance after all.

1 Like

This is partially a flaw with IRV in that compromise options might get eliminated in earlier rounds.

What this means for MKR voters?

MKR voters need to vote strategically and rank compromise options higher if they wish to get something to pass with greater than 50% of the vote.

1% SF had the most partial support with 51,634.95/70,277.09 (73.47%) support as a 1,2,3 third option.

Choice 1: 2976.82 MKR (4.24%)
Choice 1/2: 27034.09 MKR (38.47%)
Choice 1/2/3: 51634.95 MKR (73.47%)

But, 1% SF got eliminated in the third round before 0%, 2%, 4%.

A Solution:

One solution is a slight change to the IRV process. In the first round eliminate all options that have less than 50% support as any choice. 0% SF survived to the sixth round but it never had more than 50% support.

You could also just blame 0% voters for choosing it as a first choice. With the current system, if you want to compromise you may need to rank the compromise choices higher.

You could also say it’s another issue with IRV where people need to vote strategically and not with their true preference.


This is also an interesting option that I posted about before. There’s some benefits over IRV when we’re voting on something over a number line.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.