Proposal title
Snapshot Params
TL;DR
- 3 use cases for Snapshot
- Reduce voting type options to Quadratic Voting and Quadratic Ranked Choice Voting only.
- Support Required: 88%
- Min Quorum: 10 people + 10% of total token supply
- Vote duration: 4 days for Cultural Decisions and Community Signal - 6 days for Runoff
Proposal description
This proposal aim to decide a set of parameters for Snapshot including the voting types that can be used. They will dictate the results of proposals submitted there. Snapshot proposals should belong in these 3 categories:
1. Large impact cultural decisions
2. Community signal
3. Runoff votes (coming from crowd proposal making on Tokenlog)
Only TECH token holders can submit proposals. (TECH will become TEC tokens after the commons upgrade)
Snapshot has 5 different types of voting
- Single choice voting
- Each voter selects one choice that receives all their voting power
- Approval voting
- Each voter may select any number of choices that will equally receive all their voting power
- Quadratic voting
- Each voter may spread voting power across any number of choices. Results are calculated quadratically
- Ranked Choice Voting
- Each voter may select and rank any number of choices. Results are calculated by instant runoff counting method based on the top decision of each voter. Votes are token weighted.
- Weighted Voting
- Each voter may spread voting power across any number of choices.
The strategy I propose is that we prioritize Quadratic Voting over other types of voting. Our token distribution is somehow unbalanced. The top token holder has almost 10% of voting power alone, followed by the second largest holder with 7.5%. It’s not ideal for a few people to be able to control most decisions. Quadratic Voting offers a more balanced scenario while still respecting people’s holdings.
The 2 voting types suggested are Quadratic Voting and Quadratic Ranked Choice Voting.
As of now, Quadratic Ranked Choice voting doesn’t exist on Snapshot. Here is how we are gonna proceed if this proposal passes:
- The square root of each hatcher’s holdings will be calculated and new tokens will be minted for the Commons Upgrade Runoff Votes on Snapshot. This is a temporary solution only for this vote.
- Meanwhile, we’ll get in contact with Snapshot Labs and have a developer to work on an encoded solution that is lasting.
Parameters
From these two voting types there are three parameters to be chosen: Support Required, Minimum Quorum and Vote Duration Period.
Support Required
Support Required is the percentage of yes votes needed to pass a proposal.
According to the advice from this post, I propose we use a high support required, like the one we have for the Hatch DAO. Cultural decisions aren’t any less important and I believe it’s healthy for the community to be aligned on practices and processes.
Minimum Quorum
Minimum Quorum is the percentage of the total token supply that must participate in a vote in order for it to be valid.
Following the Advice Process, I propose we have 2 measures for minimum quorum, both in number of people and percentage of tokens from the total supply.
For every vote in Snapshot we need a quorum of at least 10% of the total token supply participating, including at least 10 unique voters.
The double measure is important because now only 2 people represent 10% of voting power. It will be safer to have at least 10 opinions on a vote. The token distribution will likely change soon and 10% might become more spread out. Having both metrics will give us flexibility in case 10 people become too few as we scale.
Vote Duration Period
Vote Duration Period is the duration of time each vote is open and eligible to be voted on.
- 4 days for Large Impact Cultural Decisions and Community Signal.
- 6 days for Runoff votes
From the three use cases, Large Impact Cultural Decisions, Community Signal and Runoff Votes, I propose these parameters:
Large Impact Cultural Decisions
Voting type - Quadratic voting with YES, NO options only.
Support Required - 88%
Vote Duration - 4 days
Minimum Quorum - 10% & >= 10 voters
Community Signal
Voting types:
- Quadratic Voting with YES, NO
- Quadratic Voting with multiple choices and a clear description of how many options will be considered
- Quadratic Ranked Choice Voting
Support Required - 88% for QV
Vote Duration - 4 days
Minimum Quorum - 10% > and 10 voters >
One of the Community Signal use cases is Tao voting where we don’t have an UI yet and the tech team has to be the one to submit proposals to the DAO.
Runoff votes (coming from crowd proposal making on Tokenlog)
Voting type - Quadratic Ranked Choice Voting with multiple choice to select one winner coming from Tokenlog curation process
Support Required - This parameter doesn’t apply in the same way for Ranked Choice Voting. In this case, the top proposal is the winner unless the results are evenly split between 2 proposals. Evenly split majority means that the difference between the votes from first and second place is equal or smaller than 5%. In this case, the authors of these proposals will be invited for an open hack session to find a collaborative solution with the community input.
Vote Duration Period - 6 days
Minimum Quorum - 10% > and 10 voters >
Additional information to add
We can’t program params into Snapshot (not that I know of), so the final results of each vote should be monitored by soft gov and transparency according to the parameters we choose.
How does this proposal benefit the community or the field of Token Engineering?
This proposal is fundamental to our decision making process and will give legitimacy to our cultural decisions.
Complementary information
Big thanks to Griff, Zeptimus and everyone who shared advice for this proposal and to Mitch who helped me edit this post