[Discussion] The DAO's voting mechanism, structure and processes

Edit 20.11.21 - 23:30: Miro | Online Whiteboard for Visual Collaboration
PW: grapedao

Hi everyone! Since we touched upon this topic briefly in one of the last DAO-talks but never followed up on it, here is the thread for everyone’s two cents regarding our voting mechanism, structure, and processes.

As you might have guessed, it is a rather complex subject. Therefore I’ll try to structure it as best as possible so that we can figure out how best to tackle it. So please, bear with me :wink:

TL;DR: What are your ideas regarding our proposal and voting system? What rules do we need to have in place for proposals to be voted on? Should there exist different criteria for proposals, e.g., different voting times for proposals with a higher impact, etc.?

Participation in general and the chance to participate in a vote is crucial for the DAO’s legitimacy. Therefore we should have an agreed-upon process for how to set up/structure our voting system.

As I understand, right now, Discourse is the platform where everything DAO-related happens. Furthermore, the voting mechanism seems to be ‘Permissioned Relative Majority’; the results are presented in the following Public DAO Meeting and executed afterward (if the proposal passed).

Here is a short overview of how things are right now:

  1. Any DAO member can post a proposal.
  2. Any DAO member can comment on a proposal.
  3. Any DAO member can vote on a proposal.
  4. Non-DAO members can see any proposal.
  5. Non-DAO members can not create a proposal.
  6. Non-DAO members can not comment on a proposal.
  7. Non-DAO members can not vote on a proposal.
  8. There is no agreed-upon timeframe for a proposal to run.
  9. The voting system is not quorum-based.

For me, especially 8 and 9 are issues we should address sooner rather than later. Another question would be whether we should stay with Discourse and see how viable it is short to mid-term. Or if we should start from scratch and decide on the proper system/mechanism first (see below).

Personally, I think Discours and how things progress is the right way for us, at least for now, since it is a system that is already available and with a few tweaks it can provide everything we need. Plus, if we continue this route, there is no need to spend resources on implementing another mechanism.

However, from experience, I can say that the requirements might quickly change as soon as more people participate in the decision-making. So re-thinking or at least having in mind that there are different solutions available is advisable to not run into a tight spot later down the road.

Here are some voting mechanisms that DAOs use today (subjective & not complete):

Permissioned relative majority

Relative majority voting mechanism compares the total number of votes of those supporting and those against to arrive at a decision. Permissioned means proposals need to be sponsored by DAO members to be voted on, which, in theory, limits the risk of potentially ‘dangerous’ proposals (that could be malicious; e.g., one person can drain the DAO’s funds while others aren’t looking).

Projects: MetaCartel Ventures, Raid Guild and DAOhaus.

Token based quorum voting

Quorum voting requires a certain threshold of voters for a proposal to pass (e.g. 70% quorum, which means 70% of voting is needed for a vote to pass). 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 to be considered for passing).

Projects: Compound, Curve, and Kleros.

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, making the barrier to pass proposals much lower.

Projects that have used this: DXdao, NecDAO and Prime DAO.

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.

Projects: 1Hive, Panvala, and Commons Stack.

My suggestions for the immediate future would be to address and discuss the way votes on a proposal are handled and to have a look at:

  1. Should we have an obligatory discussion thread before a proposal gets posted? Like this post. (Obvsl. not suited for ‘urgent’ votes)
  2. Should there be proposal tiers so that the runtime of the voting is tied to the impact the outcome has? (e.g. amount of $GRAPE)
  3. How long should the minimum voting time on a proposal be?
  4. How many people have to participate in a vote to consider it viable/acceptable? Although we use the mechanism of permissioned relative majority, implementing a threshold could be a good idea.

Because I’m fairly new to the DAO I was a bit hesitant to create this post at first but I think it can’t hurt to talk things through. As it stands, I simply don’t know enough (of you) but I’m excited to find out. That’s also the reason why I didn’t post my preferred ‘solution’.
Maybe there already is a plan in place that I’m not aware of, then please, consider this post obsolete. If not, it’s a start.

Either way, I’m impressed with the overall energy in this community and it’s great to see how invested people are. For now, I’m really curious about your ideas and opinions and especially the different angles you approach this topic.



My understanding was that we’ll be using Squads soon, but I don’t know what functionality it will have. Can anybody comment on that?


Important topic :+1: I’m also new to being in a DAO so voting practices are new to me

I’m positive to implement minimum participation (threshold), like 55-70%, so we can avoid potentially dangerous proposals get passed without the majority have a say, as you wrote.

I’m wondering what percentage a proposal should have in order to pass. What is normal, +50% or 66,6%?


From the DAO discussions we have had I think we are waiting to see how Squads’ solution compares with Discourse. And we will probably go on from there.

I’ll spend some time to compare with what they have already and update the DAO.


implementing minimum participation threshold makes sense especially if there are funds on the line imo. For proposals where funds aren’t at stake we could stick with permissioned relative majority. Just my thoughts.


Thank you for this thread, pretty new to DAOs myself so this was helpful. Looking forward to comments from the community to get educated further.


Thank you for putting this together!

I believe we will be exploring the governance program “Realms”, that Solana has made (its the one Mango currently uses)

The most imperative decision you suggested is finding a structure behind the proposal process and voting. The tools that we use (be it Discourse, Squads, or Realms) can pretty much handle any format we agree on

I like the 4 suggestions you laid out and will focus there:

  1. Should we have an obligatory discussion thread before a proposal gets posted? Like this post. (Obvsl. not suited for ‘urgent’ votes) I think this shoud be mandatory, especially for proposals that are at the DAO level (subDAO proposals should be handled as each subDAO sees fit). We need to clarify which proposals are at the DAO level

  2. Should there be proposal tiers so that the runtime of the voting is tied to the impact the outcome has? (e.g. amount of $GRAPE) I like this alot! I believe budget requests should be short runtimes (2-4 days) as we’ve already allocated that $GRAPE to be used. When it comes to large decisions like the emissions for an epoch, those should take longer 7-10 days.

  3. How long should the minimum voting time on a proposal be? id go with 2 days for a budget use proposal

  4. How many people have to participate in a vote to consider it viable/acceptable? Although we use the mechanism of permissioned relative majority, implementing a threshold could be a good idea. I wouldnt put a minimum. I find that the harder part of the DAO experience isnt in the voting, but the actual implementation. We are at a beginning point in the creation of this DAO, and I’d like to have a bias towards action. If someone is putting the energy to allocate resources, i dont want poor participation to force them into hibernation


Hi @CryptoPawz - Really appreciate the time spent to enumerate these thoughts and really deep dive into it.

RE: Points 8 & 9: on Voting Duration & Voting Adequacy.

8. There is no agreed-upon timeframe for a proposal to run.
9. The voting system is not quorum-based.

Response & Suggestions to Voting Duration & Voting Adequacy.

Duration: I recommend a default duration required for a proposal vote to reach completion is 1 Week. Discussions around categorizing proposals into “Types” creates unique rule-sets that suggests there will be a need for subjective decisioning to determine what type of proposal or vote is required. If everything follows a general rule-set, and the DAO proposes & votes as a DAO on which types of proposals deserve shorter duration votes, this can be achieved, but then we introduce the need for policing on proposal “Types”. Currently, there is no agreed-upon timeframe for a proposal to run, but DAO meetings occur weekly - so - 1 Week would seem sufficient as a start.

Adequacy: Something I feel is also critical. I believe a minimum vote threshold should be defined and required to consider a vote successful. I.e. 60-70% participation minimum. Lack of votes that meet or exceed this minimum should extends proposal duration until threshold is met, or, proposal exceeds 1 Epoch without reaching voting consensus, to be resubmitted or revised. Today, Voting System is based on permissions & merit DAO membership, relative to holding a minimum of 20K GRAPE. :slight_smile: - Certainly an area for review on future improvements!


In Discourse - I think it’s important to note that the permissions described only apply to DAO Category Proposals & Submissions. ANY verified DAO & Non-DAO Member of the community can submit a Discourse post, however, Non-DAO is not permitted to participate in DAO related activities, apart from being able to view.

Clarification: For DAO Category Proposals ONLY

  1. DAO member can view, submit proposals, reply on proposals, comment, and vote
  2. Non-DAO members can only view, can not create proposals, can not reply on proposal. not vote on a proposal.
  3. The above applies only to the “DAO” related submissions. Any verified GRAPE community member that qualifies as any Class member, can gain access and submit posts, replies & votes for Non-DAO related discussions, or, for consensus building in providing support for DAO proposal ideas. However, this has not been fully expanded as there are technical & operational reasons this has not been expanded.


Permissioned relative majority

Grapes current DAO model ensures that DAO members are also Class A members, hold a role, and/or, actively participate in the Community.

Token based quorum voting

Current model incentivizes DAO proposals to align with initiatives beneficial to GRAPE. Not withstanding the lack of on-chain voting, there are several mechanisms that could be implemented to leverage GRAPE tokens & tools to create a more secured, open, voting mechanism.

Holographic Consensus

Because GRAPE is a Social Network, it seems betting for or against proposal votes would instill incentives to ignore the core focus of the vote, and rather, may introduce a desire to promote speculative practices that could sway or disrupt the relevant voting processes.

DAO Research & Documentation:

Would love to get thoughts on this research done on other DAO’s that was shared prior to implementing the solutions GRAPE currently uses.


agree :100: :100: :100: :100:

thank you for this post @cryptopawz. i think the forcing function here will be a flood of high quality and high value proposals. if we optimise for execution and people see things happening - it makes the process higher stakes and worth investing in further.


Hey everyone! Took a bit longer than expected, but I tried to find a solution that we could use to a) visualize what we intend to do and b) that can be expanded as necessary.

It’s still a work in progress, so don’t be too harsh :joy:
Tomorrow, I’ll add what I already outlined. @Continental is also on board and we already discussed his ideas regarding subCategories. Some of @Arximedis thoughts are also already included.

It’s a mix of System Mapping and an extended mindmap. Feel free to add to it!
PW: grapedao


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