Header
Title: Proposal to adjust voting quorum and approval threshold
Author(s): Britt
Status: Draft
Related Discussions: ongoing discussion in discord
Submission Date: TBD
Body
Summary:
The goal of this proposal is to adjust our quorum and approval threshold model to something that is more granular and conducive to both security and progress.
Motivation:
Currently Across governance requires a quorum of 20 million ACX for all votes to pass. This represents about 15% of our circulating supply of ACX, which is a pretty high expectation for voter turnout on every vote. It would be beneficial to the protocol to add some granularity to this requirement, if only because different types of votes will naturally see different levels of voter turnout. At the current quorum, it will be difficult to pass most votes. This might end up being a huge roadblock to getting things done, which will kill momentum on many projects that are in progress today. Given that protocol governance for Across is new and engagement/awareness levels in a bull market already tend to be low, it seems reasonable to lower the barrier to acceptance of ideas that come through. On the other hand, simply reducing quorum across the board might open us up to accepting votes that we shouldn’t. Through a combination of lowering quorum and circumstantially raising the approval threshold, we can achieve a more versatile system of voting. The goal of this proposal is to find a middle ground that satisfies all of these problems.
Specification & Implementation:
Lowering Quorum:
I’d like to recommend lowering the quorum to 6 Million based on a recent proposal I created to test organic engagement in our governance system. The goal of quorum is not to prevent whales from swaying a vote, it’s to determine the minimum amount of engagement that should be required to move an idea forward. It’s therefore my stance that we should not create a barrier that is higher than our natural participation rate.
It can be noted that this proposal did meet our current quorum levels, but it required a lot of extra effort on behalf of Risk Labs to seek out voters and ask them to vote. While this is sometimes necessary, it’s not something that should be practiced regularly.
Implementing a reduction in quorum would involve:
1.) Update the Governance Operating Manual to reflect the change.
2.) Updating the settings in Snapshot to reflect the change.
3.) Updating the settings in our oSnap module to reflect the change. (more info on oSnap will be linked here when available).
Raising Threshold:
One hypothetical concern that has been raised during discussions on this idea is that an ACX whale might slip through an unnoticed vote to drain the treasury. While this is extremely unlikely, it is work taking precautions against an event like this. One way to combat dubious votes is to increase the approval threshold. I’d like to suggest that any proposal for $150,000 or more should require an approval threshold of 66% (increased from 51%). In addition to this precaution, it should be noted that we have set up monitoring systems that report to both Discord and internal Risk Labs channels. We receive notifications when a proposal goes live on Snapshot and when a transaction is initiated from the Treasury. Once oSnap is deployed, the dispute window will act as a time-lock on treasury transactions, giving the DAO ample time to dispute an attack.
Implementing a threshold increase would involve:
1.) Update the Governance Operating Manual to reflect the change.
2.) (optional) inclusion of detailed threshold requirements in oSnap deployed rules.
Soft Quorum:
To complement the section above, I’d like to also include a measure that will result in lower barriers for approval on proposals that carry a low potential impact on the protocol and have a lower anticipated voter turnout. In the early stages of the DAO, we really want to encourage good, low-impact ideas, even when voter turnout is low. One way to achieve this is to implement a soft quorum. Here’s how I’d recommend implementing this:
Soft Quorum: For votes that do not reach Quorum, assume that 70% of the votes necessary to achieve quorum would be against the proposal. If this would still result in a majority of votes being in favor of the proposal, the proposal can be considered passed.
A soft quorum should only be used on proposal types that are considered low impact. Anything with substantial consequence should require a larger voter turnout to implement. For our current needs, I believe we can use a soft quorum for proposals that are governance updates or funding requests under $50k in value.
This model also helps protect against bad ideas that are low impact and low in participation.
Here’s an example to help articulate that:
Bob wants to request $30,000 in ACX to start up an Across taco shop. Alice and Roger both think this is a poor use of funds and choose to vote against it. They each have 150,000 ACX for a combined voting power or 300,000 ACX. In order for Bob to receive his funds, he would need to get 1,850,000 "Yes" votes AND no additional "No" votes.
The takeaway from this example is that in events where voter turnout is low, an idea needs to have overwhelming support in order to pass. Here is a link to a soft quorum calculator I created that you can play with to visualize how a vote would play out under this system.
Implementing a soft quorum would involve:
1.) Update the Governance Operating Manual to reflect the change above. A link to the calculator tool would also be included.
2.) Updating the settings and written rules in our oSnap module to reflect the change. oSnap will go through a trial period with a slightly elevated quorum for trustless execution, so any proposals passing with soft quorum will need to be executed with the existing multi-sig (more info on oSnap will be linked here when available).
Rationale:
The soft quorum model I selected here is inspired by the implementation that ShapeShift uses today. The increased assumption of opposing votes + the layers of protection surrounding governance should protect against any bad proposals. At the same time, it should significantly reduce the barrier to entry for those who want to request a grant that will be used to bring value to Across.
Raising the approval threshold for higher-valued grant requests is meant to slightly offset the effect of reducing quorum globally. Grants of that size should start to see stronger voter turnout, and it’s important that voters are more strongly aligned on expenditures of this size.
The global reduction in quorum is inspired by the test proposal linked above, as well as by the governance mechanisms employed by some of the more well-known protocols in the space. For example; Compound requires a 5% quorum, Uniswap requires 4% of all UNI (40M) must vote in the affirmative, and AAVE has a 2% quorum on minor changes. These all approximate to the same levels of participation I’ve outlined above. When more significant updates to the protocol get incorporated into this system, it is reasonable to expect that they should require a higher quorum (AAVE has a 20% quorum on major changes).
Downside (Cons):
By lowering the barrier to entry for low $ value proposals, we’re also lowering the expectation of due diligence on those proposals. It’s not uncommon in this space for a protocol to revise grant proposal requirements after a round of funding with sub-optimal results. While this is less than desirable, I believe it’s a worthwhile risk to take if we do so with the appropriate risk mitigation measures in place. One of these is to place a limit on the value of a grant that can get through with a lower quorum.
Voting:
A vote for this proposal will result in taking the steps listed above to reduce the global quorum to 6 Million, adjust the approval threshold from 51% to 66% for grant requests larger than $150,000, and implement a soft quorum for governance updates and grant requests under $50,000.
A vote against this proposal will result in no changes being made to the governance system, leaving quorum at 20 Million for all proposal types.
Link to live proposal here
