[Implemented] Defining voting parameters to optimize future improvement proposals

Title: Defining new voting parameters to optimize the process for future improvement proposals
Author(s): Edu Timmers
Related Discussions: [RFC] A proposal to change the current voting format and set some basic conditions to have better and more acceptable proposals in the future
Submission Date: 07/12/2022

Abstract:

An improvement proposal to create voting parameters that fit the current lifecycle stage of the Hashflow protocol. These entail a minimal voting quorum of 1 million HFT, a minimal voting majority over 60% and an extended voting period of 7 days on Snapshot.

Motivation:

As we are a growing protocol that is just starting with the process of decentralization and governance, it is best to choose voting parameters that match those aspects. By having these parameters in place, there will be more clarity for the community, guardians, investors and developers on how we will move forward with future improvement proposals. A strengthened process for improvement proposals will in turn strengthen the DAO’s effectiveness and efficiency.

Specification & Rationale:

  • Voting quorum of 1 million HFT for proposals to be accepted

In the future preferably there will be a percentage of circulating supply used as basis (1% for starters). However based on recent votes, 1 million is a good basis to start from as this will entail that all active on-chain HFT users and LP providers will need to be onboard for protocol changes.

  • Supermajority of 3/5th or 60% for proposals to be accepted

Hashflow is in an early stage of governance which means that there will often be bad proposals coming into our governance. This article states that if voting occurs on more bad than good proposals, a supermajority is a favourable mechanism.

(https://www.researchgate.net/publication/228187137_Majority_and_Supermajority_Rules_Three_Views_of_the_Capitol)

My proposal is to implement a supermajority of 3/5 or 60% to have community alignment but not create a too tough environment for any proposal to get passed.

  • Announcement of voting must be 1 day before start and ending of the voting period

At least 1 full day before the start and the end of the voting period an announcement should be made in Snapshot as well as Discord. This will help less active Hashflow participants, LP providers and investors be more aware of ongoing governance proposals.

  • Voting period on Snapshot for 5 days

As we are a young and growing protocol, community involvement will be less than more active/bigger protocols. Therefore, applying a fast governance process might lead to irrational choices and might miss the involvement of large community beneficiaries.

Benefits (Pros): Create a stronger basis for governance and community alignment

Downside (Cons): Slower decision-making and more tedious community engagement

Voting:

Yes, means you are for changing the proposed voting parameters.

No, means you are for leaving the voting parameters as they currently are.

3 Likes

I think this part in my proposal can mention here

  • At least 1 full day before the start of voting, an announcement about the start and end time of voting should be made in Snapshot.*
    This advance notification helps that users will not be surprised and will be ready to vote.
    I am OK with the rest of your proposal.
    It is not much different from my proposal.
2 Likes

I would add @danhan point of vote announcements as well

1 Like

Yes and like other projects, we can have proposals on snapshot as “upcoming” so that people get ready for it.

2 Likes

The comment period for this thread is closed - thanks for all the comments!

I support this proposal. I believe this is the most important proposal to go up for voting right now.

3 Likes