[RFC - Governance update] Proposal to adjust voting quorum and approval threshold


Title: Proposal to adjust voting quorum and approval threshold
Author(s): Britt
Status: Draft
Related Discussions: ongoing discussion in discord
Submission Date: TBD


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.

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).

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.

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


This is kinda sad. It should be easier to get a measly 15% of the tokens to show up on a ballot. Nonetheless, it is the standard in cryptocurrency governance to set a low bar on governance. I agree with this 5% of tokens.


The Across snapshot proposal ( Snapshot) was struggling to reach the 20M quorum until 2 wallets with 15M and 6.2M came in. These 2 combined have the ability to sway votes even at the 20M quorum. Not sure how to resolve this but putting a quorum low at say 6 M will be maybe too low. Perhaps 10M or maybe even slightly more at 13M? What I’m try to say is that I’m not sure! :blush:


I like this thought process and feel like the guardrail of under $50k in value and soft quorum requirements help minimize risk.

Given we have such limited data to support any additional historical analysis to inform the right amount, I would support at 6m as proposed and we can always iterate or adjust as needed.


As an active member in the governance of MakerDAO and current delegate in Optimism, I think that the best for these cases is voting in the forum for amounts less than $25K, with this you ensure minimum losses and reciprocal quality in each request.

In addition, a model that can be used is that of the delegates, we know that low participation is a reality, it will be useless to increase the quorum or not if participation is low, that is why I proposed creating a system of delegates with incentives .

For the delegates and delegators, in addition, the figure of the delegate in these cases forces them to work hand in hand with the core team, present proposals and participate actively in the discussions.


I like the idea of delegation/committees as well. I’m working on another proposal that would outline the use case for committees within Across, and I definitely think this is the right way to go. This proposal is really meant to find a solution to help proposals go through in a way that isn’t so intensive while we work through some of those structural decisions.

That being said, I would actually love to talk to you more about the OP delegate model to see what we can learn from it.


Sure, it would be an honor for me, you can send me a DM through the forum or if you find it more comfortable we can talk through Discord.

Hi frens,
The 20 million limit may be high for now. However, the 6 million limit seems a little low to me. If possible, a recommendation-based limit can be established. For example, a limit of 15-20 million can be set for a treasury-based proposal.

I think quorum will be reached easier with the circulating supply growing. People will always turn up for important votes and ignore less importants ones… so the balance between them should be reached trough higher/lower quorum.
Not sure how that can be implemented!

I think you laid out and addressed the issues well here and i also believe quorum is too high and needs to be changed. I also like the idea behind adjusting the approval threshold for larger grant requests. I support this initiative

I support this proposal, I think it’s well thought out and a good step. I think that it could lead to good proposals being passed more easily, but once that aren’t necessarily going to motivate whales to grab their hard wallets.

I tend to prefer the optimistic way with proposals anyway, where they “pass unless someone says no.” If we see a bad proposal go up and it gets support by a faction who can reach quorum, it then means that now we need to advertise to whales that we need them to sign on and vote no. And if the proposal is in fact damaging or bad, I fully expect to see that happen. I think this is the better default flow.

I support this proposal and think that DAO treasuries tend to be underutilized due to lack of voting participation and a lack of alternative organizational models. I’ve been pretty focused on oSnap, personally, and would love more feedback from the Across community on what features would be useful for futures versions of the oSnap module. The long-term goal should be to enable DAOs to organize themselves around human-readable rules that follow whatever pattern makes the most sense, not just the patterns (multi-sigs, voting) that are easiest to turn into code.