[AIP-28] Updating Governance Voting Structure


The Alpaca team is always looking for ways to improve our Governance process. A useful framework / concept we don’t currently have for Alpaca’s Governance voting is Quorum and the ability for users to vote abstain. Quorum refers to the minimum % of voters turn out required for the voting result to be valid.


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

Quorum Requirement:

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.

Note: 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 (based on the old Governance vault’s stats.) 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.

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


This AIP will be a single-choice voting,

  • A YES vote would implement the new voting structure as proposed in this AIP
  • A NO vote would keep the voting structure the same

some items of the new voting structure sound strange to me:

Item 3) is not new, we did this many times before, I may say it is kind of low-efficiency. Since we are introducing quorum, isn’t it making more sense to just put “remains” as an option out of all others?

Item 5) I think YES just needs to be more than NO to win, as well as NO just needs to be more than YES to win. Abstain should be treated as neutrality. The reason we want to introduce quorum and abstain is to make sure enough awareness of each vote, not to try to keep everything unchanged.


Hi Ian, thanks for the feedback

On #3, Yes, this is what we have been doing in the past. But part of this is to codify some of the practice into writing. For example, #1 and #2 are also not net.

As for the intent of the this point, let me illustrate by example.

Uniswap had a vote earlier this year for the community to decide whether to start charging fees from LPs. Looking at the choices and result. You can see that while the “No Fee” camp received the highest votes, if you sum up all the votes on the “turn on Fee” camp, they actually had the majority. The more appropriate way would have been to have 2 votes, where the first vote being just a YES and NO to turn on fee and then the 2nd vote to determine what the actual % fee to charge should be.

On #5, both ways can be done. one option (Yes > No) favors straightforwardness & quickness while the other (Yes > No + Abstain) favors high level of consensus in the community. I don’t have a strong preference and would like to hear what other also think.


I prefer Yes > No, so when I vote Abstain also could contribute to the quorum without affecting the result.


Unless there is any additional comment, I will put this AIP up for voting by tomorrow with #5 changed as suggested by @SirIan and @Chin.


We are still waiting for Snapshot to merge our updated pull request for a new voting config. before I can post this up for voting.

This change is required because of our new Governance vault.


This AIP is now live for voting