Pre-HIP RFC: Should Hop Community Governance Process Emulate Other DAOs

đź—łMeta-Governance
1

Motivation

The goal of this proposal is to avoid the governance process from being too cumbersome while also helping other DAO contributors quickly plug into the Hop Community and add value by contributing proposals to advance the protocol.

@cwhinfrey has laid out a strong foundation and initial framework for community governance https://forum.hop.exchange/t/community-governance-process/130 and @lefterisjp has proposed several suggestions to bring the governance process in line with other DAOs which are tried and work.

Changes Proposed

It is proposed to separate the temperature check and snapshot vote instead of running them concurrently.

Phase 1: Temperature Check / Request for Comment – Discourse

A governance forum post providing a synopsis of the proposal.
To create a Temperature Check/Request for Comment:

Ask a general, non-biased question to the community on forum.hop.exchange 9 about a potential change (example: “Should Hop governance add liquidity mining for XYZ token?“). Forum posts should be labeled as follows: “Temperature Check/ Request for Comment - [Your Title Here]“.

First, I propose 5 days of discussion where people engage to show interest or not. If there is enough feedback and buy-in by at least 2 different people then it can go to a snapshot vote.

Phase 2: Snapshot Vote – Snapshot

I also propose that the Snapshot vote should be up for at least 7 days, is decided by a majority, and requires a minimum of 300k votes to pass. This poll can either be binary or multiple choice but should include the option “Make no change” or its equivalent. Make sure that the discussion thread links to the new Snapshot poll and the Temperature Check/Request for Comment thread.

At the end of 7 days, whichever option has the majority of votes wins, and can be included in a governance proposal for Stage 3. A 300k HOP -vote quorum is required for the Snapshot vote to pass. To clarify, the quorum is the sum of all votes. A vote may be about choosing A or B or C. There is no YES in that case.

If the option “Make no change” wins the Snapshot vote, the topic should be closed by community moderators.

The on-chain vote is just a formal ratification of whatever snapshot decides and is only needed for proposals that need to do on-chain action.

Feedback Needed

This is a request for comment, in line with current Hop governance processes, and is intended to provide a place for comment and feedback to be incorporated before requesting a sponsor to move it to a temperature check as a HIP (francom is under the 1,000,000 HOP threshold for being able to submit a proposal).

Looking forward to receiving feedback from other delegates especially those who are involved in other DAO governance processes.

2 Likes
2

Hey @francom thanks a lot for taking the time to write this down as a proposal.

In general looks good to me.

Some small comments:

A 300k HOP yes-vote quorum is required for the Snapshot vote to pass.

The quorum is supposed to be the sum of all votes. Can’t define it as YES only. Plus a vote may be about choosing A or B or C. There is no YES in that case. To be clearer I suggest defining the quorum as total votes filed.

3 Likes
3

Do we want to take this opportunity to lower this, or do we all feel good about 1m HOP? In particular would like to hear from those with 1m HOP who will be asked to push proposals if it stays where it is.

4

Hey @francom thanks for exploring this topic.

In short, I think the answer is YES but allow for flexibility and growth towards a more custom process.

There are many mature DAOs who have dealt with this processes - their solutions are a good model for us to consider as we grow and iterate.

1 Like
5

Great point. I’ll define quorum as total votes filed.

6

Thanks for putting this together @francom

I’m personally in favor of lowering the proposal threshold so that large delegates have the ability to post proposals themselves.

I think the quorum should be increased as well. Less than 1% of circulating supply seems low, especially considering:

  • most recent governance decisions have had 5-15M HOP participating
  • there are large unlocks and liquidity incentives on the horizon

A number closer to 1M HOP seems better to me

1 Like
7

After giving it more thought I think we should lower the threshold since only 5 delegates currently have over 1m HOP. Any specific number or range in mind @GFXlabs ? If we lower it to 300k HOP there will be close to 20 delegates that will be able to push proposals.

8

Good point. The last 7 snapshote votes averaged over 9 million HOP participating therefore 1 million HOP seems reasonable. I’ll raise it to 1 million but would love to hear anyone else’s thoughts.

9

Whether it needs to be lowered likely depends upon anticipated emissions/unlocks. If the circulating supply is expected to grow at a quick pace, 1m is probably not too much. If the supply is expected to expand slowly, then temporarily lowering it to 500k, 600k, 700k, or 800k would lower centralization risk.

It’s a trade off between governance security (which will become more important as HOP begins to have more powers) and centralization. At the moment, the best solution may be to have one of the 1m+ voters push proposals on chain every month or two.

10

I don’t necessarily see the value in this section as it is. Someone could make 2 accounts to push it through, but maybe if it’s 2 comments from delegates (x amount of tokens held) then it’s a more valuable sign of support.

I think there should also be a phase between 1 & 2, like a “Review” or “Proposed” Stage. This is where a proposal must stay unchanged for three to five days before it moves to snapshot. This is a clear time for community members and delegates to provide their final input before it moves to snapshot, and if it doesn’t have enough support via a signaling poll, then it shouldn’t move forward.

Not everyone is always active on forums esp in the early governance stages of a protocol, so these changes will make the governance workflow more sustainable.