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:
- some voters wish to block a vote from reaching quorum by abstaining
- voters are not as engaged over time, but do not unstake
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.
IF WhitelistProposal AND VoterParticipation >= 40% AND YesVotes > NoVotes Then PASS
If WhitelistProposal AND NoVotes > 30% Then FAIL
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.