Prioritization in MakerDAO


Recently, and with some prompting from the PECU, I’ve been considering the problem of prioritization within the DAO.

Previously, the Core Units have managed prioritization internally and worked on what they think makes the most sense, taking input from governance through greenlight polls, declarations of intent, and through conversation and discussion on an ad-hoc basis.

This has worked reasonably well up to this point, though we have at times had community members propose a change in priorities due to dissatisfaction with the Core Units (then mandated actors) choices.

As more and more possible work items are proposed, the problem of prioritization becomes more and more complex. At this point, I’d like to try to streamline the process and develop some system to do this in a more consistent and transparent way.


There are a number of considerations to be made when considering the issue of prioritization.

First, prioritization is a continuous rather than a discrete decision. While one can vote something to the ‘top of the list’ that decision could be invalidated as soon as another option is added to the list of possible priorities.

Second, prioritization needs to extend past a single item. There are often blockers that prevent work on a specific proposal that cannot be directly resolved by the Core Units. We need to be able to rank a set of proposals such that Core Units can adapt to external constraints.

Third, prioritization needs to be low cost. This is an addendum to the first two points. Because prioritization is continuous and needs to cover many items, it needs to be cheap to do (in terms of time, gas, attention, etc.)

Options Considered

Off-chain ranking, on-chain confirmation via binary poll


  • Doesn’t require any work from DUX.

  • The process is simple and easy to understand.


  • Doesn’t take into account MKR weight at the prioritization stage. This could be good but is much more likely to be bad.

  • We would need to repeat the poll regularly to take into account new options and any changing priorities.

  • Expensive in terms of attention. Would require frequent discussions on the forum or in meetings to figure out how to distribute priorities.

  • Chance of on-chain poll failing, leading to lots of wasted effort.

On-Chain Approval Voting

What is this?

Approval Voting is a system in which each voter records a ‘yes’ or a ‘no’ for each option, their full vote-weight is applied equally to each option on which they voted ‘yes’. We use this system for signal requests at the forum stage. Options are ranked by MKR Weight.

More Information


  • Allows MKR to vote directly for prioritization options on-chain.

  • More experts endorse approval voting for single-winner than any other system (but prioritization isn’t a single-winner election.)

  • Matches what we do for off-chain polls, so the system is familiar to the community.

  • Reusable for other multi-option single-winner polls.


  • Requires DUX to produce both new vote option input and vote result output on the Voting Portal.

  • Less intuitive for prioritizing, most people prefer to rank things. May be more intuitive for agreeing on shared direction/values.

  • Custody platforms would need to integrate/rely on delegation.

  • Would need to repeat the poll regularly to take into account new options.

On-Chain Positional Voting

What is this?

Positional voting is a ranked voting system in which vote weight is distributed across ranked options by some rule (and not by the voter.) For example, ranking something first might give it 100% MKR vote weight, second might give 75%, third 50%, fourth 25%, and fifth 0%.

More Information


  • We can reuse the ranked-choice input system that currently exists on the voting portal.

  • Outputs a clearly ranked list of results.

  • Ranked input is more intuitive for voters when trying to determine prioritization.

  • Conceptually simple.


  • We would need to repeat the poll regularly to take into account new options.

  • Custody platforms would need to integrate/rely on delegation.

  • Requires DUX to develop a new method of displaying vote results on the voting portal - though this would be less work than some other options.

On-chain Single Transferable Vote

What is this?

A modification of IRV which handles multiple winners and allows vote weight to be transferred between options as options are eliminated. Similar to IRV in that there are multiple rounds and options are removed as rounds progress.

More Information

Edit: Updated to use Single Transferable Vote as name.


  • We can reuse the ranked-choice input system that currently exists on the voting portal.

  • An extremely clear explanation and walk-through of the algorithm is available via FairVote.

  • Outputs multiple winners in winning order.

  • Can output any number of winners, up to and including the total number of options in the poll. This makes it multi-purpose and could be useful for determining the general direction of the DAO, rather than just priorities.

  • Ranked input is more intuitive for voters when figuring out prioritization.

  • Allows for the transfer of vote-weight to lower-ranked options if higher-ranked options have already been removed as ‘winners.’ Means that no vote-weight is ever ‘wasted’ and can count towards multiple options.


  • Requires DUX to develop a new method of displaying votes.

  • Would need to repeat the poll regularly to take into account new options.

  • Custody platforms would need to integrate/rely on delegation.

On-Chain Conviction Voting

What is this?

A system in which voting is continuous and options can be added and removed on the fly. Vote weight increases over time, to represent a voter’s conviction in their vote. Outputs a continuously updated ranking of options that can be used for prioritization.

More Information


  • Probably is the best way to solve this problem while reducing ongoing costs over the long term.

  • Reusable for proposal priorities / direction for the DAO / grants / etc. Potentially other advanced uses, parameter setting, etc.

  • Would not need to repeat votes, new proposals could be added and removed seamlessly.


  • Designed for fund allocation rather than arbitrary stuff - probably generalizes fairly well though…

  • Would need more significant front-end work.

  • Probably requires smart contracts work.

  • Would need custody provider integration / rely on delegation.

  • Not entirely sure of the details of how this works, would require further investigation.


Having looked at all these options, my conclusion is that in the short term, Multi-winner IRV is the way to go, and in the longer term, we should seriously consider conviction voting for prioritization of resources (be it funding directly, or core unit hours.)

Multi-winner IRV is the only option that gives us transfer of excess vote-weight, which I feel is going to be pretty critical given the range of MKR held by voters is very large (some with lots of MKR, others with relatively little).

It lets us re-use some of the front-end work which should slightly reduce implementation time, and it’s very flexible in what we can use it for. Ranking a set of options, choosing a subset from a set of options, etc.

Although calculating the results is non-trivial compared to the other options, DUX has already implemented IRV result calculation, and this is a variant of that system. The complexity downside can be mitigated by effective communication of the results on the voting portal.

Compared to Conviction Voting, Multi-winner IRV requires much less work. Conviction Voting is also at an experimental stage currently, and it would be helpful to see the system mature some and get more experimental data before committing lots of time to it.

Next Steps

I’m going to go ahead and speak to DUX about costing some of these options, focusing on the favored options. I’ll also draft a MIP that would cover how this system works in detail, and allow the community to more meaningfully comment and respond to a more specific proposal.

In the meantime, this thread is also meant to elicit feedback from the community and start a debate about some of the options open to us. If you have other ideas, please do share them.


Personally I am not the biggest fan of IRV–and when I think about IRV–it reminds me of this confusing outcome that occur in 2020– that was one confusing outcome for the entire community. But again, I am willing to try–assuming the community + MKR token hodlers understand it, properly.

Also, how does GovAlpha intend to attract more community members to participate? I ask because when I see Ethereum influencers like Coopa pitch the theme of working for a DAO equals ownership of such via tokens:


I wonder if the Maker motto will remain, SourceCred is your ownership of the DAO. If so, how does SourceCred play into IRV participation?


When we started with SourceCred payouts, more people expressed preference for payouts in DAI vs MKR. But always thought MKR made more sense personally.


I agree that that outcome was not ideal. And I agree with you that IRV is not the ideal system for single-winner elections in Maker, given our other constraints. I would rather see On-chain approval voting for single-winner polls.

Ensuring outcomes are not confusing would be one of the implementation goals. In an ideal world, the voting UI will show the results after each round under IRV, alongside the final results. This is a non-trivial amount of UI work though.

Multi-winner approval voting is very simple conceptually, but in the past when I’ve discussed prioritization, people have wanted to rank things versus just voting yes/no on each one.

Happy to answer this if you ask it elsewhere. I would prefer to keep this thread focused on prioritization options.

  1. I think this is a worthwhile endeavor. MKR voters should have a way of signaling their preference for priority.

  2. Of the choices, my preference is to have a continuously open vote going on at all times. One where voters can rank each of the options in terms of importance themselves and then have the IRV magic happen to factor in their voting weight. I also like that options can be removed and added on the fly as they are completed or dreamt up. So On-chain conviction voting or multiwinner IRV seem to be the options that fits that description best.

  3. I feel unsure about the rules of our specific IRV. ie; I am weirded out about vote weight being shifted to the next ranked choice once an option is eliminated. (are we even eliminating options with multi-winner runoff?, I guess not?) I just don’t like the mechanic of transfering votes to next choices once a choice is a winner or eliminated. I feel like once options change it should reset the vote completely so everyone would need to rerank it all given the new context (if there is a new choice on the board.) On chain conviction voting seems to be my fav option currently. Willing to change my mind though.

  4. What is on the priority voting list?
    Is it organized by engineering projects? general direction? etc… I’d love to see something like an example list of what would be on this kind of vote.

  5. Is this recommendation or a harder direction that MKR voters are setting? Do CUs have last say? Is this just a general “north star” list that governance is setting so we have a roughly shared sense of priority?

  6. Can we set up an off-chain version of multi-choice IRV or conviction voting to test out the UX? Can we do it inside discourse itself?


This is only possible with Conviction Voting (or another form of continuous voting system.)

I don’t think you understand how multiwinner IRV would work - I’d encourage you to read through the reference in that section. Vote weight being moved around is integral to IRV - It’s more or less what makes it IRV. Options won’t change within a single vote. It’s not a continuous voting system.

Ultimately, we could use it for anything. Initially I expect we’ll use it to direct protocol engineering on specific projects.

Any of the above. At this stage it’s about a voting system that allows us to rank things. ‘What things to rank’ isn’t really covered here. There are potentially a lot of uses, which is why I think it’s worthwhile to implement a variant voting system.

Maybe to the first questions. Probably not necessary to have it inside discourse, that would just complicate things with limited gain.

1 Like

This post was flagged by the community and is temporarily hidden.

This is what I pointed out on my post above–most folks don’t understand IRV–maybe do an illustration video via the @Content-Production team similar to this: Instant Runoff Voting - YouTube but with a Maker Governance twist to it?

1 Like

Multi-winner IRV is also known as Single Transferable Vote. Here’s a video that walks through it: Example STV election - YouTube

Note that this assume winners = 3 and options = 6. And also one person one vote. In a prioritization scenario we would have winners == options, and vote weight would equal MKR weight.

If an option meets the threshold it would be ranked in the next available slot closest to 1. If an option is discarded it would be ranked in the next available slot closest to 6.

In this way, the ranking slots fill up from both ends, depending on the actual distribution of votes.

Following the above video the outcome by round would be:
Round 1 - Rank John in position 1.
Round 2 - Rank Aliyah in position 2.
Round 3 - Rank Helen in position 6.
Round 4 - Rank Paul in position 5.
Round 5 - Rank Kwame in position 3.
Round 6 - Rank Sally in position 4.

Outcome being:

  1. John.
  2. Aliyah.
  3. Kwame.
  4. Sally.
  5. Paul.
  6. Helen.

In Maker-land. Imagine the options are MIPs that have passed but haven’t yet been implemented by the Smart Contracts team.

1 Like

Got it. From a democratic point of view supporters of Sally are going to be upset that Kwame got less votes but still outranked Sally. I also believe some MKR token owners will only vote for 1 choice and the other choices will benefit from such. Again, not a fan but willing to try it out.

He would have got less votes under FPTP, sure. That’s sort of the point of having a ranked system though, it allows you to better capture peoples preferences beyond ‘this option is my favourite.’ I would argue this makes the system more democratic, rather than less. And moreover, it’s critical to capture preferences beyond favourites when the goal is to prioritize a set of work items rather than electing individuals to office.

This is something we could probably disallow in the UI. If not, you can just not-transfer votes if a user has not ranked any other options. Like:

STV - User may or may not register additional preferences beyond favourite option.
FPTP / Plurality - User cannot register additional preferences beyond favourite option.

Like, at least STV gives voters the option to register further preferences versus making the choice for them.


Great discussion so far! Here are my thoughts as someone who recently joined MakerDAO as a Product Manager (DUX team):

  1. I believe that the CUs should remain end-responsible for their priorities and planning, since they have the clearest picture of their specific context—including a lot of context that is ‘below the surface’.

  2. What is missing currently, though, is a MakerDAO wide list of priorities that would serve as reference for the CUs. They should aim to work in sync with the DAO’s priorities as much as possible, barring other important work (eg. technical debt, emergencies, and other sensible time investments that are too fine-grained for the DAO-wide priority list).

  1. I believe this MakerDAO-wide priority list should consist of challenge statements, phrased as “How might we…?”. This prevents the list from becoming too long, filled with fine-grained initiatives and projects. Instead, we should give CUs the mandate to define meaningful contributions and cross-CU projects that align with these prioritized challenges. Examples would be: "How might we increase governance participation?", “How might we bring DAI to all major L2 platforms?” and “How might we onboard TradFi academic talent to MakerDAO?”.

Whatever DAO-wide prioritization framework we end up choosing, I believe that prioritization is always relative and not absolute—therefore I think ranked input would be best. Also the framework should minimize governance overhead (both in time investment required and related gas expenses).

As we (DUX) are the team focussing on governance UX, we will keep an eye on this discussion and later on investigate the technical feasibility of the mechanisms discussed. :slight_smile: