Background:
The Alpaca team is always looking for ways to improve our Governance process, as shown by the recent implementation of shielded voting.
Another potentially useful framework / concept we don’t currently have for Alpaca’s Governance is Quorum. Quorum refers to the minimum % of voters turn out required for the voting result to be valid.
Rationale:
When it is used, the Quorum required in DeFi projects are around 10% - 20% of eligible voters.
For the case of Alpaca, since there is around 23 million xALPACA, around 2.0 - 4.5 million xALPACA votes would be required on a proposal to meet the quorum. A quick review of previous proposals on Snapshot would show that all the previous ones would have met the quorum requirement.
This is a good sign and show that we have an active community as compared to our peers in the industry.
Implementation
-
All the future votes would have a quorum requirement. If the votes don’t meet the quorum requirement, then the result is not valid and would require new voting.
-
“Abstain” voting option will be added , so xALPACA holders can still contribute to the quorum on a topic that they don’t have a strong opinion or preference.
3 Likes
Good idea.
One concern i have is whether we can have a rule that the quorum cant be less than a single person’s holding?
I am concerned that if a single person has more xAlpaca than what is required they can basically decide everything on their own?
Wdyt?
In addition to the implementation of Quorum, I would also like to expand the discussion to also include some codification of the voting structure:
Quorum:
1.) Minimum of 10% of xALPACA voted in order for the result to be valid. (rounded to the nearest 100,000s) For example, if the total xALPACA balance was 23,124,227.24, we would require 2.3 million votes.
Voting Structure:
1.) At least 72 hours of voting time for each proposal.
2.) Shielded voting for all proposals
3.) All voting choices shall be put on equal footing. For example, if the proposal is on changing a protocol’s parameter and there are multiple possible parameter values to select from, we will conduct a series of votes with the first vote being a YES or NO on whether to change the parameter.
4.) In the case where the number of voting choices > 2, we WILL NOT require the winning result to receive > 50% of the votes, unless specified prior to the vote. The rationale behind this is to save time / energy from too many votes. More over, if the voting structured is well thought out (as in point#3 above) the multiple choices (>2) would be the final vote in a series of votes.
for 4) I would prefer to have the 50%+ of the votes on a multi option vote by default.
We already have around 20-30% of active voters, in a multi option vote with 4 options we would need only 26% of 20-30% people to vote it.
Hi everyone,
now that we have a new governance vault in place, I would like to revisit this topic. Reiterating the key points below:
Quorum:
1.) Minimum of 10% of xALPACA voted in order for the result to be valid. (rounded to the nearest 100,000s) For example, if the total xALPACA balance was 47million, we would require 4.7 million votes.
Voting Structure:
1.) At least 72 hours of voting time for each proposal.
2.) Shielded voting for all proposals
3.) All voting choices shall be put on equal footing. For example, if the proposal is on changing a protocol’s parameter and there are multiple possible parameter values to select from, we will conduct a series of votes with the first vote being a YES or NO on whether to change the parameter.
4.) There will be an option for users to vote Abstain. This way, xALPACA holders can still contribute to the quorum on a topic that they don’t have a strong opinion or preference.
5.) For a “simple voting” topics where there are only two choices (i.e., YES or NO), the YES vote must receive > 50% of the votes for the proposal to pass (i.e. YES > NO + Abstain)
6.) In the case where the number of voting choices > 2, we WILL NOT require the winning result to receive > 50% of the votes, unless specified prior to the vote. The rationale behind this is to save time / energy from too many votes. More over, if the voting structured is well thought out (as in point#3 above) the multiple choices (>2) would be the final vote in a series of votes.
3 Likes
This discussion topic has now been moved into an AIP. Any further discussion can be made in the new thread. [AIP-28] Updating Governance Voting Structure