Currently, Genesis has an issue with proposals in the regular queue, that is, via absolute majority. As @parrachia has correctly noted:
Right now the only way for a proposal to pass is boosted, other wise it’s 30 day + 51% of all rep in favor (our record is 41% total)
At the request of @Kate I’ve been asked to offer my general commentary regarding it, and posit some solutions:
First, the “Why is this happening?”
Unlike other DAOs, Genesis, as an alpha experiment, was instantiated with a fairly arbitrary Reputation distribution and has added members very loosely. With this “loose policy,” many members simply do not participate after they submit their first proposal as they don’t have any incentive to do so: extrinsically, there isn’t enough capital to generate activity; i.e. Genesis cannot administer grants large enough for full or part-time attention; intrinsically, there’s just not enough interest to sustain prolonged engagement; DAOs are still a novelty and the Genesis Alpha as a virtual tester community does not have so much emotional punch as to sustain activity with the majority of new joiners.
Holographic consensus anticipates this issue and offers, through the GEN prediction mechanism, the ability for people to “force” a vote to occur on any given proposal. This is the mechanism the Genesis Alpha has been using for the most part, and it’s been working: within the Genesis .2 protocol there’s an extrinsic incentive to boost proposals as one can profit from the DAOstake. With this, it could be argued that there’s no need to be able to pass proposals within the regular queue, but in my opinion I disagree with this logic: not being able to reach a global majority when needed is a bug, not a feature.
I am sure the above reasoning is by no means exhaustive, but it offers a high level overview of the issue.
Second, the solutions:
There are arguably five solutions that will increase the likelihood of proposals passing in the regular queue:
-
Remove inactive voters: This could be accomplished through social consensus; i.e. a policy can be formalized wherein inactive voters are slashed of their Rep after x amount of time. This type of altruistic punishment has been demonstrated to work in order to maintain the quality/activity of a process – in our case, voting. This would be ultimately a manual implementation of a process that can be made automatic through some sort of Reputation decay function; however, Arc needs to be upgraded to facilitate off-chain voting in order to automate decay, this is not expected until Q1 2020.
-
Massively inflate the Rep pool towards active voters: Similar to (1), this simply adjusts the balance of Reputation towards those voters who are actually voting, thus increasing the likelihood of a global majority forming. It is, in a sense, a tax on inactive voters.
-
Fractalize to a lower n-stakeholder count with a bloc voting model: There’s an ongoing discussion around the merits of fractalization here, and I present a bloc voting model here that could be utilized to increase Reputation voter % in the regular queue. The jist of this is that Reputation would be allocated by voting blocs, and not individual stakeholders, and those blocs would be orgnanized into their own DAOs; eg. DAOstack Technologies could be a single voting entity with 20% of the Rep, instead of 20 separate stakeholders. @adam has confirmed that DAOs will have the ability to vote in each other within Alchemy as soon as the Generic Action scheme is released; this is expected in the next month.
-
Implement single or multiple layer delegation (aka Liquid Democracy): Both single and multiple layer delegation would be expected to increase Reputation thorough-put, assuming that Reputation is delegated to active voters. This could be a great project/module for an open-source developer to tackle.
-
Lower the threshold for absolute majority: One of the key distuinguishing features of DAOstack is the ability for DAOs to upgrade themselves, this is accomplished through the Scheme Registrar, a scheme that will be made available within the next two-ish weeks. With this, we will have the ability to update/change the Genesis parameters; one parameter is the Majority Parameter, that is, the required % to pass a proposal through the regular queue. By lowering this from 50% to some arbitrary number, say, 30%, it immediately becomes easier to pass proposals within the regular queue – the tradeoff being that the results may not, in fact, reflect the global majority.
It goes without saying there are numerous marketing technical solutions as well that can provide indirect solutions for this issue by channeling increased voter attention through owned channels: e-mail and push notifications, the ability to subscribe to DAO updates, Telegram and Twitter bots, etc… these should not be ignored, but they do not directly impact the issue itself (you can receive 100 notifications for a DAO and yet not vote in it at all).