Proposal: Modify WL critiera for voting

[Dave]

Background

White Listing of projects has had challenges with voter participation. The belief is that anyone staking vBNT to vote ought to actively participate in the process, which involves weekly votes on proposals. However, we’ve seen marginal participation in many cases.

There are a few theories as to why:

1. some voters wish to block a vote from reaching quorum by abstaining
2. voters are not as engaged over time, but do not unstake

Proposal

To mitigate the concerns of project vulnerabilities AND active participation, this proposal aims to give concerned voters a direct voice via voting “NO” while avoiding passive participation hindrance.

Current logic:
IF WhitelistProposal AND VoterParticipation >= 40% AND YesVotes > NoVotes Then PASS
Else FAIL

Proposed Logic:
If WhitelistProposal AND NoVotes > 30% Then FAIL
Else PASS

TL;DR
When looking at the core issue, it really gets back to “What deserves to be White Listed?”
My understanding is that “Any project that benefits the protocol” is the simple answer to the question.
Going a step deeper, the real intention is to avoid anything that may harm the protocol.
Harm may originate with the safety/security of the proposed project(s), determined by it’s minting and re-basing capability, the transparency of the respective Dev Teams, if the project has any critical mass, etc. Concerns along these vectors are appropriate for objection from voters.

Our current White Listing governance is not aligned to the above concerns. We have had numerous projects fail to achieve White Listing status while still satisfying safety/security concerns mentioned above. These outcomes suggest that the established voting mechanism isn’t effective. Trying to incentivize (through inflationary measures) voting is is noble, however we’ve observed that ICHI’s incentive did not change voter behavior. The cost of Dev effort (and inflationary payouts) to stand up incentives is counterproductive to the benefit of the protocol.

Rather than taking an incentive approach, this proposal seeks to use voting as a way to identify security/safety risks, which is what vetting a White List candidate was intended. If/when such risks are identified, the threshold for voting it down is 30% (lower than voting up @ 40%). By NOT having a quorum requirement for 30% down voting, it actually becomes easier to reject a proposal ‘for cause’ while at the same time, being easier to pass on merit.

This proposed change to voting also requires minimal Dev effort and zero inflation, which is more beneficial to the protocol than the voter incentive approach.

[TheOneJM]

Flipping WL voting makes a lot of sense to streamline Whitelisting.

All votes should assume that the token will be Whitelisted unless the DAO votes for it to not take place.

Hopefully we’re also eventually able to automatically put the pools up for vote for WL once a liquidity threshold is met to further streamline the process.

[bias]

You can find a very long discussion about Incentivizing Voters here: How to increase voter turnout

I am working a few others to draft a proposal to incentivize voting. Rather than change quorum rules, we have been focusing more on how to engage voters who are inactive and hopefully draw new voters into the governance contract. Currently on the table is a snapshot ballot and potentially voting rewards.

I think we are 100% going to propose adding the Abstain option. Right now we use supermajority rules, so we need 40% quorum and 66% of votes to be For the proposal to pass. Abstain would count towards quorum but have no influence on the supermajority rule. This should help drive participation.

I think while it’s tempting to just lower quorum for whitelists, whitelists are Bancor’s primary security concern at this point. Low activity + easier quorums makes it even easier for bad actors to force through something damaging to the protocol. I would much rather keep exploring the Voting Incentives before lowering requirements

[Dave]

Thanks! Have looked through the discussion you linked above. Lots of ideas there.

When looking at the core issue, it really gets back to “What deserves to be White Listed?”
My understanding is that “Any project that benefits the protocol” is the simple answer to the question.
Going a step deeper, the real intention is to avoid anything that may harm the protocol.
Harm may originate with the safety/security of the proposed project(s), determined by it’s minting and re-basing capability, the transparency of the respective Dev Teams, if the project has any critical mass, etc. Concerns along these vectors are appropriate for objection from voters.

Our current White Listing governance is not aligned to the above concerns. We have had numerous projects fail to achieve White Listing status while still satisfying safety/security concerns mentioned above. These outcomes suggest that the established voting mechanism isn’t effective. Trying to incentivize (through inflationary measures) voting is is noble, however we’ve observed that ICHI’s incentive did not change voter behavior. The cost of Dev effort (and inflationary payouts) to stand up incentives is counterproductive to the benefit of the protocol.

Rather than taking an incentive approach, this proposal seeks to use voting as a way to identify security/safety risks, which is what vetting a White List candidate was intended. If/when such risks are identified, the threshold for voting it down is 30% (lower than voting up @ 40%). By NOT having a quorum requirement for 30% down voting, it actually becomes easier to reject a proposal ‘for cause’ while at the same time, being easier to pass on merit.

This proposed change to voting also requires minimal Dev effort and zero inflation, which is more beneficial to the protocol than the voter incentive approach.

Hope you’ll give it another look.

[Jefe-fintechv1]

The application of negative consent principles to WL appeals to me, and may solve one problem since anyone opposing a WL would need to vote AGAINST otherwise it would pass.

However, the broader issue of voter participation is what I sought to address. My goal was to increase participation through rewards and gamification to shift the balance of voting power to be more egalitarian and meritocratic – vote consistently and earn rewards.

The expected result would be more frequent (hopefully constant) quorum, and the passage of more WL proposals among others.

I don’t view voting rewards and negative consent as mutually exclusive. In fact, to really level up voter participation I suggest we combine both and prepare a unified proposal that both rewards constant engagement in Bancor’s future and requires those who oppose a WL to make their opposition known instead of blocking through a non-vote. We would still obtain actionable intelligence that we could use to modify a proposal and communicate intelligently with other communities to rally their support.

[mbr]

This logic is highly insecure.

For example - imagine only one person voted FOR with a single vBNT, and no one else voted.

Should this pass?

[Dave]

Thanks. Agreed that some quorum should exist, but probably lower than 40%.

The proposed approach is aiming to encourage a low bar for rejection using “NO” votes instead of a high bar of acceptance with “YES” votes.

We always want the DAO to reject questionable projects, however in most cases, we’re needing to plea to whales to show up for quorum when there is overwhelming support in terms of approvals.

After more discussion in the telegram chat, it’s clear that permissionless design and development is coming, so this will all be moot at some point. Knowing that the Dev team is putting energy into QC of approved proposals regardless, I suggested in the chat that perhaps we’d have a short term/tactical approach of time-boxed weekly pre-screening/QC of the top-ranked projects (ordered by market cap) that aren’t already whitelisted as a way to better utilize the time of the Dev team for QC efforts. If the time frame for a permissionless solution is a week or two away, then this isn’t worth the effort… however if a permissionless solution is further out, this pre-screening approach might help to avoid lower-value projects from taking valuable Dev time, while allowing a limited amount of time to get stronger projects listed… it’s a balance of short/long term and prioritization of Dev time. You and the team will have the best perspective on this.

[tenzent]

What about simply lowering quorum for whitelistings to 30%, with xBNT starting to vote now it should make it a lot easier.

[mbr]

Remember, the lower the quorum, the more power you give to whales.

This is also true for a low ‘AGAINST’. What you are proposing, is to drop the quourum and increase the supermajority. This is fine; for example, a reasonable compormise could be:

Whitelisting Quorum: 30%
Whitelisting Supermajority: 90%

However, be aware that this doesn’t get you out of the woods, either. A single AGAINST vote can kill the vote. I don’t mind, by the way. I would support something like this.

Just be aware that any governce voting structure increases in security as it gets more difficult for votes to pass. I know it is topical to be upset about our quorum rules, but actually it has worked out pretty well thus far.

In general, the number of failed proposals should be comparable to the number of successful ones. This is a good indicator of a functioning decisions making system. If everything starts passing, then we have a problem.

[tonro]

I dont know if that could be implemented in a secure way, but it would interesting to not count towards the quorum those vbnt that are inactive (did not vote for any proposals in the last x days). And as soon as the holders vote, that weigth should count again towards the quorum. It might be easier to do it onchain rollups than on snapshot.

[mbr]

I agree with this.

I think a system of ‘booting’ inactive vBNT from the governance contract is something that could be discussed in greater detail.

[tfns]

Fully support a “booting” system.

[mbr]

I am moving this thread to the chatroom. We don’t really have a working draft yet.

[tenzent]

Alright I was racking my head over how we can start getting more productive with with whitelisting and thought this up.

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.

[mbr]

I want to invite everyone on this thread to join the community call today. We are going to commit some time to discussing some of these things, and hopefully we can come to an agreement in view of the community.