Voting Options in DAOs
This article explores the different voting mechanisms used by DAOs through Q&As with DAO founders and builders. *Special thanks* to Michael from Curve, Clement from Kleros, anonymous from Compound, Sky from DXdao, Luuk and Pat from PrimeDAO, Adam from lexDAO, Dekan from Raid Guild, Luke from 1Hive, Cooper from Audius, Auryn from Gnosis, and Ezra from DAOstack for providing input!
Token based quorum voting
Quorum voting requires a certain threshold of voters in order for a proposal to pass (for example: 60% quorum, which means 60% of voting power needs to vote). Once this threshold has been met, whichever decision has more votes wins. Without reaching the quorum threshold, proposals fail.
The threshold has typically been based on the total number of votes, although some protocols (like Compound governance) have a quorum threshold only for the votes in favor of a proposal passing instead (20% quorum in this case would mean 20% of voting power voting positively for a proposal in order for a proposal to be considered for passing).
Projects that have used this include Compound, Curve, and Kleros (among many others).
This governance mechanism is battle tested, and has a long history in our political system. It also has a simple UX for users.
On the flipside, pure token-based voting has some issues. Plutocracies aren’t great. Selecting the “right” quorum requirement is hard. A low quorum makes proposals very easy to pass and the system easy to attack. A high quorum makes it very difficult to pass proposals. This challenge is even greater when large whales are added to the mix. Token-based voting is sensitive to certain kinds of attacks (like the flash governance attack we saw in Maker). Quorum-based voting also requires a high amount of participation from members to pass proposals, which is expensive and time consuming.
Q&A with Michael from Curve:
How do you like quorum-based voting being used in your DAO?
Quorum-based voting makes sense for us. Usually turnout is very small, though. We have not had many challenges passing proposals (only 1 didn’t reach quorum out of ~30). Voting does turn into a game of chasing whales though, which is annoying. Some of them you know, some of them you don’t know, which makes things challenging. The amount of gas is a barrier to a certain degree, but we are looking to subsidize gas with meta transactions in the future.
Are you concerned about some of the risks associated with quorum-based voting? (NOTE: Curve does not use direct token voting. They require token holders to lock tokens, and the voting power given is proportional to the amount of tokens locked as well as the time they are locked for. This mechanism decreases attack vectors.).
Not really since voting power is given to token lockers, based on the amount of time they have the tokens locked for. Not really concerned about other risks, like not being able to reach quorum.
Would you switch the voting mechanism for this DAO if you could easily do so?
What I really want to have is liquid democracy, where votes are delegated.
Q&A with Clement from Kleros:
How do you like quorum-based voting being used in your DAO?
I hate it. The only quorum % I would advise projects use would be 0 (ie, no quorum).
What are some of the things you most dislike about quorum-based voting?
It leads to tactical voting. There are various reasons why tactical voting is not ideal, and doesn’t lead to the best decisions being taken. (Tactical voting means that you may be incentivized to lie about your preference to get the best outcome you can. Many people often do this in the US elections for example, by voting Democratic or Republican even if they support an independent party since their “vote won’t count”). In quorum-based voting, people against a proposal often abstain since they are more likely to prevent a proposal from passing this way than to vote no.
Quorum-based voting also leads to governance locks when the quorum can’t be reached. It also leads to forced conservatism as only extremely popular proposals can be passed but simple ones have trouble getting people to vote.
Are you concerned about some of the risks associated with quorum-based voting?
Yes, I am concerned. The risks of governance locks are significant and can result in projects stopping their development or not being able to answer in a timely fashion to new environment conditions.
Would you switch the voting mechanism for this DAO if you could easily do so?
Conviction voting is interesting, Moloch permissioned-style can fit some DAOs. I’m also generally a fan of Condorcet method voting systems.
Q&A with {anonymous} from Compound:
How do you like quorum-based voting being used in your DAO?
At least in Compound, it seems to be working, and upgrades are being made by the community. It has not been a problem meeting quorum, possibly because there are active whales.
What are some of the things you most dislike about quorum-based voting?
Tokens as a voting mechanism have a market price, which is mostly based around speculation. Separating out the voting power from the financial aspect would be a good thing.
The challenges around Compound governance seem to be more related to social and incentive problems. For example: Many people participate in the community because they care, not because they have a long term stake. It would be good to get more people aligned with the long term direction of protocol. Getting more people to care in general is a challenge. In addition, even though Compound is decentralized, many still just reach out to the team instead of working within the community. Part of this problem is likely due to a lack of infrastructure around proposals and voting as well as perceived centralization.
Would you switch the voting mechanism for this DAO if you could easily do so?
Quadratic voting line of thought seems to be interesting. Possibly requiring the locking up of tokens to accrue voting power. Possibly also issuing vesting COMP to farmers to align long term incentives.
Other things that come to mind is voting power tied to the length of time tokens are staked.
Holographic Consensus
Holographic Consensus (HC) was a concept spearheaded by DAOstack. This voting mechanism associates a prediction market with each proposal. Predictors can stake funds for or against a proposal they believe will pass or fail. If they predict correctly, they benefit financially. Proposals that are predicted to pass are “boosted” and voting switches from 50% quorum to relative majority (where you only look at For vs. Against votes, and no quorum is needed), making the barrier to pass proposals much lower than proposals that don’t have funds staked on them.
Projects that have used this voting mechanism include DXdao, NecDAO and Prime DAO.
This voting mechanism naturally protects projects from nefarious proposals, since you need to pay in order to attack (via staking funds on proposals). It works great for projects that have many proposals since members only really need to pay attention to proposals with a stake on them. It also allows a DAO to pass proposals quickly.
On the flipside, the UX is more confusing and it introduces a new token mechanism (staking on proposals) which isn’t always desired.
Q&A with Sky from DXdao:
How do you like HC based voting being used in your DAO?
Holographic consensus-based voting that is being used by DXdao has been working well. It’s been interesting to participate in a system which uses non-transferrable REP for voting and a GEN-staking token for predicting on proposals, as this is unique from most other single token governance systems.
My understanding is that the design of holographic consensus is meant to be a system that can scale to tens or hundreds of thousands of members. Obviously, we have not seen this large scale experience in action yet and so DXdao is practicing what we might call a much lighter version of what it was designed for. It is not often that there are so many proposals in the queue that the staking mechanism becomes an important aspect of the filtering.
Overall, it has been working well. DXdao has not had many contentious votes. Part of the reason for this is likely that people making proposals often feel out and gain social consensus through forum posts/chats and community discussions around a topic prior to making the proposal. This almost adds a third layer into the governance mix.
What are some of the things you most dislike about HC type voting?
Holographic Consensus adds more complexity to the governance process. The biggest drawback is probably that it is hard to understand the exact details of how the system works, especially if one is new to the DAO and system.
Because of this, it takes time and energy for people to become familiar with the governance process and how to most effectively govern with it.
Also, I would say that an active Holographic Consensus governance system with all the moving pieces and lots of people being active becomes quite expensive especially with higher gas prices on Ethereum.
Would you switch the voting mechanism for this DAO if you could easily do so?
For me, the most interesting addition to the current governance system would be some way to incorporate conviction voting into the governance process to be used for specific types of proposals on top of the current system. Seeing Commons Stack’s Panvala Conviction Voting system in action during Gitcoin grants was pretty cool. I think this fluid type of voting makes a ton of sense in certain situations.
I also really like the simplicity of Moloch DAOs — they are quite easy for new people to understand right away, and they are efficient and secure (assuming you have the necessary community watching over them).
At this point, I don’t think it would make sense to switch fully to any other voting mechanism as HC has been working well for DXdao’s needs, but we are always experimenting!
Q&A with Luuk from Prime DAO:
How do you like HC based voting being used in your DAO?
I believe HC can work well for filtering proposals for a DAO. I’m not really sure it works well for making the best decisions for a DAO though, since people with specific knowledge about something aren’t necessarily the same people who have voting power. The initial idea that Colony had (i.e. where people had reputation in a specific domain) seemed interesting. In fact, in another DAO I was working on (CuraDAO), some people even found it unethical for them to be able to vote on certain proposals they didn’t have knowledge on! I don’t necessarily believe in the vision of these mega DAOs.
Although not really related to the voting mechanism, I do really love the proposal information and flow in the DAOstack DAOs.
What are some of the things you most dislike about HC type voting?
A big challenge is the need to use GEN.
Would you switch the voting mechanism for this DAO if you could easily do so?
Would switch to having multiple voting mechanisms for different decisions. HC for base layer decisions, then Conviction Voting for budgetary decisions. 1 Token 1 Vote for other things. To me, it makes the most sense to use the right tool for the right thing. HC makes sense for high level, but not necessarily low level.
Permissioned relative majority (Moloch DAOs)
Relative majority (ie, where you just compare total number of for and against votes) isn’t a viable governance option for DAOs due to the ease with which they can be attacked (1 person can easily drain the DAO’s funds while others aren’t looking!). However, Moloch DAOs have a nice little feature to prevent this: proposals need to be sponsored by DAO members in order to be voted on, which adds a nice security buffer.
Projects that have used this include MetaCartel Ventures, Raid Guild and DAOhaus.
Some of the benefits of this voting mechanism include a simple UX, and less actions required by members, meaning a lower attention requirement and gas cost. On the other hand, proposals are easy to pass and can pose a risk if nobody is watching. It is slower by design.
Q&A with Adam from LexDAO:
How do you like “permissioned relative majority” voting being used in your DAO?
LexDAO previously used quorum-based voting, and it was a nightmare. Had to whip every vote to get enough people in. The complaining about gas was endless, even when it was $.50 to vote. Votes were rare, but still people were bugged by the gas. Moloch on the other hand tends to effectively align incentives to foster community. It flips the burden from “get enough people to say yes” as the threshold for anything getting done, to “it’s your job to say ‘no’ if you care.”
Do you dislike anything about this sort of voting mechanism?
It’s definitely slower. A lot of the protections built in are around the timing of the proposal process.
Would you move to another voting system, or change anything about it?
Delegation might be something nice to add.
Q&A with Dekan from Raid Guild
(Note: Dekan is building DAOhaus, a platform to deploy Moloch DAOs):
How do you like “permissioned relative majority” voting being used in your DAO?
I like the simple majority rules and no quorum on Moloch voting. Only a single vote is required to pass a proposal which saves gas but it also requires members to be vigilant on watching proposals. It requires an engaged community.
Do you dislike anything about this sort of voting mechanism?
Although “majority rules” has its positives, it is also a negative in a sense. A lot can ride on one vote so a proposal can sneak through if the community is not engaged. If a proposal does sneak through, members can still ragequit, but that could be missed too. So there is a high level of responsibility to be aware of the votes happening in your DAO.
Would you move to another voting system, or change anything about it?
I would like to have an early voting mechanic, so a special proposal could pass instantly on some quorum being met.
Conviction voting
High level: Conviction voting is a voting mechanism in which people stake their voting power on proposals, and over time, those proposals accumulate enough votes to pass. Aragon recently began a pilot for this new type of voting mechanism, which is still very experimental.
Projects that are using this include 1Hive, Panvala, and Commons Stack.
This voting mechanism in theory prevents people with large stakes and strong opinions from suppressing minority voters. The majority doesn’t need to achieve consensus on every proposal, instead, token holders can simply focus on the proposals they support.
On the other hand, this voting mechanism is not yet battle tested, it has a more confusing UX, and likely needs to be used along with other voting mechanisms that are better for yes/no or time sensitive decisions.
Q&A with Luke Duncan from 1Hive
Note: Luke is a member of 1Hive and Aragon, which have funded the building of conviction voting systems:
How do you like your experience with Conviction Voting so far?
Conviction voting is really interesting, it’s still early, but I consider it to be a game changer from a decentralized governance perspective. It’s hard to compare it to other voting mechanisms, because it works so differently. At least in the context we use it, it is more about budgeting and resource allocation than about reaching a specific consensus/decision.
Do you think it could be used effectively for specific consensus / decisions? Or are there reasons why it’s not that good for it?
It’s not really the right tool for that, though in some contexts it could be applied. For example, we use it for funding, and the amount of support required depends on the amount of funds requested by a proposal out of the available funds in a treasury/pool. Another use case is updating a linear parameter (e.g. an inflation rate), which can be done by averaging the signals periodically to move parameter values. But it wouldn’t make a ton of sense to make arbitrary decisions like “upgrade this smart contract”.
The Multisig
Many projects and communities have opted to go the Multisig route (usually with Snapshot for off-chain signaling). In this voting mechanism, token holders signal on proposals, which are then executed by a more centralized committee who usually control a Gnosis Safe. A more thorough analysis of this option along with Q&A will be published at a later date.
Colony’s “Lazy Consensus” voting mechanism (section 3.4 of Colony’s whitepaper)
In this system in development by Colony, , anyone in the community can make a motion for something to happen. If no one objects within a certain amount of time, it happens. If someone objects, then a reputation-weighted vote decides whether or not it should happen. This voting mechanism is still under development, so unfortunately we don’t have firsthand accounts or example projects yet.
Final Thoughts
Currently, the vast majority of projects are using quorum-based voting, in part because it is the most battle-tested and simplest to integrate for existing projects. But we are still in the super early stages of product / protocol governance! The voting mechanism used by your project influences everything from member participation to security and community culture. The *right* voting mechanism could play a critical role in the long term success of projects, by allowing groups to make the best decisions, at the right pace, with minimal risks.
Until a clear winner emerges, projects should try and minimize locking themselves into a specific protocol or voting mechanism, and be open to experimenting as the space keeps evolving.
