• © Goverland Inc. 2026
  • v1.0.8
  • Privacy Policy
  • Terms of Use
BancorBancorby0xA15959aAAa96C0b17D06FfBb2dc10aE249E37BF60xA159…7BF6

Update quorum and supermajority requirements

Voting ended almost 5 years agoSucceeded

Read the original proposal on Discourse

TL,DR

  • A thorough analysis of the voter demographics incentivised discussion to improve the current governance.
  • The issues identified include, among others, low voter participation, difficulty in achieving quorum for certain types of proposals and inactive voters. Security and balancing concerns were expressed as well.
  • The Introduction, Comments, and Conclusions sections present the initial analysis before the last rounds of high DAO vote participation. The Discussion section collects the thoughts of the DAO in the governance forum to make them available on snapshot for an informed vote [3]. An update of the proposal is shown in the discussion.
  • The latest voting rounds with high participation were considered in the analysis that derived the final proposed requirements for quorum and supermajority.
  • The proposed requirement changes are the following*:
  1. Whitelisting proposals: 35% quorum, 66.7% supermajority.
  2. Co-investments < 1M BNT: 35% quorum, 66.7% supermajority.
  3. Co-investments > 1M BNT: 40% quorum, 66.7% supermajority.
  4. Liquidity mining: 35% quorum, 66.7% supermajority.
  5. Pool fees: 20%, 66.7% supermajority.
  6. Governance and protocol changes: 35% quorum, 66.7% supermajority.

*These are shown again under the FOR section.

Introduction

The last proposals to whitelist tokens on snapshot have failed despite adequate engagement from voters. An improvement to the voting system is long overdue. Voting data on snapshot for all the wallets with vBNT currently staked in governance was collected [1]. With this data, an analysis of the current voter demographic was drawn to hopefully shed some light into the current voting issues to find adequate solutions for them.

image

image

Figure 1 - Active Voters and Voting participation

Comments

  1. A vBNT staker in governance was considered an active voter if their corresponding wallet has cast at least one vote since the snapshot is active.
  2. Voter participation was calculated as votes divided by total proposals.
  3. Voter participation was taken from the moment a first vote was cast.
  4. Some inactive voters might have staked vBNT without a chance to vote yet. This fact is further emphasized by the number of "Active but haven't voted for 1 week" stakers.
  5. "Active voters that haven't staked in x weeks" stabilises around 3 weeks.
  6. Average Active vote participation is 30%.
  7. A substantial amount of vBNT stakers vote on less than 10% of the proposals.
  8. There is a significant number of wallets with less than 10 vBNT staked in governance (Figure 1).

Conclusions

  • A debate on the topic was already done and no conclusion came from it [2]. This proposal aims to bring two concrete ones and hopefully spark some debate.
  • As a side note, in the future, a minimum vBNT stake in governance should be added to avoid wallets staking small amounts in order to get any community incentive that is given as a part of voting (88mph and ZCN are two examples of this) without contributing to quorum (Point 8).
  • A solution to reduce the impact of whales on quorum is to change the vBNT voting power structure. A reduction to the voting power of larger vBNT stakers vs smaller ones could be considered, to level down the voting power of whales. The solution is non-trivial to implement and might incentivise bigger wallets to split their stake into smaller ones to acquire more voting power, especially if gas fees are lowered with coming L2s. Another solution is quadratic voting -- however, it brings unnecessary complexity to snapshot. The idea is interesting and should be explored if easier solutions are not enough.
  • A recursive vote on snapshot to check inactivity for addresses that have not voted for the past 3 weeks (point 5). Addresses that do not cast a vote on the inactive check are then removed from quorum until they cast a vote or a vBNT restake is made (whichever is simpler to implement really). The tactic can also help reduce the number of active voters with low participation (point 7). The number of inactive wallets holding the most vBNT staked in governance is sufficiently high to consider this as well.
  • Quorum on whitelisting proposals can and should be lowered to 30% given the average active voter participation (point 6).
  • I believe the last two solutions are simple enough. The simplicity of the solutions will reduce dev time while hopefully hindering the current voting issues. A more advanced solution was suggested by @tenzent [2] and should also be considered:

Supermajority Rule : Whitelisting proposals are still 40% Quorum but, having a supermajority of 80% (FOR) lowers it to 30% for whitelisting proposals. This will counter tactical voting since in order to beat the super majority they would have to vote against rather than abstain. 30% Seems like a good number because it is not incredibly easy to reach but in proposals like LPL the community, with the help of only a few mid-size whales, has been able to achieve it (The biggest one being xBNT which we can count on for consistent and reliable voting). This rule would essentially mean that overwhelming support for tokens will be treated differently than split decisions.

Discussion

After some debate since it was posted, I believe most voters agree with @mbr 's thorough proposal.

1. All Whitelisting Proposals Include a Maximum 20k BNT Co-Investment, Subject to a 30% Quorum and 80% Supermajority Requirement.

There are good reasons for this. The lower quorum requirement makes it easier for an individual, or small group of individuals to pass a proposal. The system's vulnerability is increased, and the DAO needs to maintain its ability to manage pool sizes. It is not the case that a deliberate attack is necessarily the most pertinent threat - highly enthusiastic communities, and even our own community, can achieve the same damage without any nefarious intent. A hard limit of 20k co-invested BNT immediately following a whitelist proposal forces these new additions to be managed more carefully.

2. Co-investment Increases are Subject to Dynamic Quorum and Supermajority Requirements.

At present, co-investment increases are held to a 20% quorum and 66.7% supermajority requirement, regardless of the co-investment being requested. The low quorum is partly a reflection of the difficulty in whitelisting. If whitelisting pools is made easier, it stands to reason that increasing co-investment limits ought to be harder; the reduced barrier to entry must be commensurate with strengthened security later in the pool's lifecycle.

  1. Co-investment increases up to and including 100k BNT are subject to 30% quorum and 80% supermajority.
  2. Co-investment increases over 100k BNT are subject to 40% quorum and 66.7% supermajority.

3. Future Revisions to Whitelisting and Co-Investment Policy is Subject to a 30% Quorum and 80% Supermajority Requirement.

It is conspicuous that it is easier to change whitelisting policy, than passing a whitelist proposal. Strictly speaking, this is a type of governance hack. For example, consider that an antagonist who wishes to pass a toxic token has a reduced path to acceptance by first changing the whitelisting policy. This is not acceptable, and we have an opportunity here to close this apparent loophole.

I also want to address some of the user feedback, as well as the conversation that was hosted on our community call recently. We are absolutely committed to making Bancor the DAO to which all others are compared. This will require a comparable level of innovation as the product itself, and will be prioritized after the development pipeline is less congested. The main pain points are whale control and voter apathy - and I am working on a model to deal with both simultaneously. Rest assured that I

Read the FULL proposal on Discourse

Off-Chain Vote

FOR
10.91M 99.7%
AGAINST
30.04K 0.3%
Download mobile app to vote

Timeline

Jun 07, 2021Proposal created
Jun 07, 2021Proposal vote started
Jun 10, 2021Proposal vote ended
Oct 26, 2023Proposal updated