Should there be a minimum threshold of votes w/ $hifi tokens, before a vote can be held? If so, let us discuss here what that number should be.
2 Likes
Should there have to be a substantial amount of $hifi token votes in support, before a vote should be able to be created? Furthermore, possibly it also has to have support from at least two guardians(?), or some sort of requirement like that; so somebody can’t just come in and buy a bunch of tokens and create a proposal & push something through.
1 Like
Here is a Sushi Swap example:
1 Like
Here is an example from AAVE:
1 Like
What do you think about 1,000,000 $Hifi votes to qualify to do a community vote? This way people have to work together to launch a proposal.
Thanks for sharing this idea! It’s really interesting.
I feel like the minimal threshold idea is good, and the minimal amount should be the lowest possible, just to prevent proposal spam.
Also, we are not in spam territories (yet) and I guess we have to also be careful to not impact the decentralization factor as well. I’m always in favor of a good balance.
Also, I am wondering about the possibility of another kind of filter: Holding time. For example, we could have a requirement where you need to proof your Hifi Holdings for at least a week, a month, or something of the sort (almost like a snapshot?)
Yes, it’s to protect our beloved Hifi and also to respect everybody’s time. Though at the same time, acknowledge what you’re saying, it is a decentralized community and want to open up the opportunity for new ideas. There is no minimum threshold to initially put something on snapshot and if it does garner enough support there, it will get the minimum threshold and we will then I suppose begin to define our processes, whereas then possibly it goes to the forum here for more discussion? Possibly tightening up/ fine tuning the proposal? This is where these types of discussions are super valuable because we are incrementally creating our methodology for governance. What type of thoughts do other people have on proactively addressing this topic?
1 Like
I just assumed it would be the same as MFT at 2%. However I guess the team didn’t clarify this during the swap, so its a good discussion to have.
There are some pros and cons related to your proposal to discuss further that need to be taken into account.
Pros:
- A minimum threshold of votes with $HIFI tokens could ensure that a sufficient number of token holders are participating in the voting process.
- This could increase the legitimacy and representative nature of the voting results, as they would reflect the views of a significant portion of the token holding community.
- A minimum threshold could also discourage vote buying or other forms of manipulation, as a larger number of tokens would be required to sway the vote.
Cons:
- A minimum threshold could potentially exclude smaller token holders from participating in the voting process, even if they are interested and engaged in the community. (Delegation is the alternative of it)
- It could also make it more difficult for new token holders to have a say in governance decisions, as they may not yet have a large enough stake to meet the threshold.
- Setting the threshold too high could result in low voter turnout and a lack of participation in the voting process.
Questions:
- How would the minimum threshold be determined?
- Would the threshold be fixed or subject to change over time?
- How would the threshold be enforced, and what penalties (if there are some) would be in place for those who do not meet it?
How would the minimum threshold be determined?
The minimum threshold could be determined by the Hifi voters through a democratic process, such as here on the forum with dialogue and ultimately voting or consensus building. It could also be written into Hifi’s rules or bylaws on a faq page.
Would the threshold be fixed or subject to change over time?
The threshold could be either fixed or subject to change, depending on the needs and desires of the community. If the community is flexible and open to change, the threshold may be adjusted over time through a democratic process. If the community values stability and predictability, the threshold may be fixed and not subject to change.
How would the threshold be enforced, and what penalties (if there are some) would be in place for those who do not meet it?
The enforcement of the minimum threshold would depend on the specific rules and procedures of the community. For example, the community could have a designated person or body responsible for enforcing the threshold, and if it does not hit the threshold, it just does not get to move to a community vote (no penalties for attempting to manifest ideas to fruition). For sure, it’s important for the community to clearly communicate and enforce our rules to ensure fairness and accountability.
Are you wanting to have a minimum number of tokens to create a proposal?
Or are you talking about wanting to have a minimum amount of tokens to vote on a proposal?
Can anyone can create a proposal on Snapshot? If so, should a minimum threshold of supportive $hifi votes be required, and possibly a minimum quorum to elevate the proposal to further discussion on the forum? At which point possibly we revise, deliberate, think through collectively as a community — before going up for a vote that would enact a policy change? Should not everyone w/ $hifi be able to vote; with one token or 1 million tokens?
Worthwhile topic & discussion. Personally, I like how UNISWAP do it via a 3 stage process:
- Temperature Check
- Consensus Check
- Governance Proposal
Temperature Check
The Temperature Check process determines whether there is sufficient will to make changes to the status quo. At the end of the two days, a majority vote with a 25k UNI yes-vote threshold wins. If the Temperature check does not suggest a change from the status quo, the topic will be closed on the governance site. If the Temperature Check does suggest a change, proceed to Stage 2: Consensus Check.
Consensus Check
The Consensus Check process incorporates feedback from the Temperature Check and establishes formal discussion around a potential proposal. Consensus Check is accompanied by another off-chain vote. At the end of five days, a majority vote with a 50k UNI yes-vote threshold wins.
Governance Proposal
A Governance Proposal is the final step in the governance process. The proposal should incorporate feedback from the Consensus Check and is accompanied by executable on-chain code. In order to submit an on-chain Governance proposal, a delegate must have a minimum balance of 2m UNI. The voting period lasts 7 days and a majority vote with a 40m UNI yes-vote threshold wins.
UNISWAP conducts off-chain via Snapshot for each stage & use a consistent standard with proposal titles. Examples below:
- [Temperature Check] Deploy Uniswap V3 on Scroll testnet
- [Consensus Check] Fix the Cross Chain Messaging Bridge on Arbitrum
I have reviewed Governance related Hifi Blog posts and whilst there are references to using Discord, Forum and then Snapshot. I could not locate anything more formal beyond this. I suspect this were deliberate given we were modelling off previous versions i.e… Compound, Synthetix etc.
It may be prudent to identify why this were not included initially as there could well be a very valid reason which requires consideration.
On face value, there is merit 100% as many Defi Protocols appear to be utilizing. That said, would it make the process more complex than it perhaps needs to be? This is all open for discussion & well done for raising.
1 Like
There are some potential pros and cons for each stage of the UNISWAP process which I think is a good example to follow on and get familiar with:
Temperature Check:
Pros: Allows for initial feedback on a proposal before it enters the formal governance process, can help identify any potential issues or concerns with a proposal early on, allows for more informal and quicker decision-making.
Cons: May not provide a comprehensive or representative view of the community’s opinions, may not have the same level of transparency and accountability as the formal governance process.
Consensus Check:
Pros: Allows for a more in-depth review of a proposal, helps ensure that a proposal has broad support before it moves on to the formal governance process, can identify and address any potential issues or concerns with a proposal.
Cons: May not be as efficient as a purely temperature check-based process, may not have the same level of transparency and accountability as the formal governance process.
Governance Proposal:
Pros: Provides a formal, transparent, and accountable process for decision-making, ensures that all members of the community have an equal opportunity to participate in the decision-making process, allows for a more thorough and comprehensive review of a proposal.
Cons: May be slower and less efficient than a temperature check or consensus check-based process, may require more time and resources to participate in the process.
Regarding temperature check, what do you think of using this forum’s poll system for it?
Hifi DAO is still in it’s infancy and requires some initial filters and gatekeeping strategies for brigning proposals to snapshot.
It believe this would help dampen the possibility of having bad actors creating voting scenarios that would go against the community’s will.
It’s a really basic element, but it could be the first of many in the future. And it could also be improved or replaced overtime as the DAO evolves.
What do you think? Answer the poll below (lol dis a test 
)
- I think it’s a good idea!
- I don’t like the idea.
0 voters
1 Like
There should be a minimum delegation threshold.
Theory
We should be minimizing governance, not maximizing it. The less votes there are, the better, because the more involved the community can be when there is actually a vote. Too much voting, and people will lose interest. Because of that, we should make it difficult to pass a proposal, on purpose. It should require a lot of effort, so that only when the community and the proposal creators are really convinced that the proposal is right, it actually passes.
Practice
I think Uniswap’s approach to governance makes a lot of sense. They require a two day temperature check, a majority vote with a 25k UNI (0.0025% of the supply) yes-vote threshold wins. The temperature check is there to see if there is any interest in the proposal.
Afterwards, they have a five day consensus check where a majority vote with a 50k (0.005%) UNI yes-vote threshold wins. Both the temperature check and consensus check can be done off-chain. The consensus check is there to confirm the changes made to the proposal after the temperature check passed (incorporated feedback from the community, for example).
Once both the temperature check, and later the consensus check have passed, the real governance vote can take place. This should happen on-chain. In Uniswap’s case, 2M UNI (0.2% of the supply) delegation is required for someone to create a proposal. I think this is definitely very reasonable. At the end of the seven day voting period, a majority vote with a 40M UNI (4% of the supply) yes-vote threshold wins.
Hifi
In Hifi’s case, with our token supply, this would mean a majority vote with a 2.5K HIFI yes-vote threshold would win the temperature check, a majority vote with a 5K HIFI yes-vote threshold would win the consensus check and a majority vote with a 4M HIFI yes-vote threshold would win the real governance vote.
2 Likes
Hey Max, been a while!
Nice thread.
To make sure I understand, Uniswap’s approach suggest that a temperature check, a consensus check and governance vote would all use the snapshot voting process each time?
1 Like
Both the temperature check and consensus check require a Snapshot vote (so these two happen off-chain). The governance vote does not happen on Snapshot (happens on-chain).
1 Like
Makes sense. And I support this idea.
1 Like
Are there any reasons why they do temp check and consensus check off-chain and then vote on-chain to implement the changes?