Community Governance Process

Hop Governance Process

This document is a suggested process for developing and advancing HOP Governance Proposals. It is a living document intended to be owned, modified and enforced by the Hop community.

Several governance venues available to Hop governance are mentioned, each serving its own particular purpose.

  1. is a Discourse forum for governance-related discussion. Community members must register for an account before sharing or liking posts. New members are required to enter 4 topics and read 15 posts over the course of 10 minutes before they are permitted to post themselves.

  2. Snapshot (coming soon)
    Snapshot is a simple voting interface that allows users to signal sentiment off-chain (without paying gas). Votes on snapshot are weighted by the number of HOP delegated to the address used to vote.

  3. Governance portals
    A governance portal can be accessed through the Hop interface . Votes can be delegated and cast through this portal. There are also several other governance interfaces that users can use to cast their votes*:

*Note: this is not a complete list, and should be updated by the community frequently.
Below is a preliminary draft for the Hop governance process, detailing exactly where these venues fit in. These processes are subject to change according to feedback from the Hop community.

Phase 1: Request for Comment — Discourse

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

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

The length of this phase should be correlated to the complexity of the proposal and allow for meaningful feedback. It’s in the proposal authors interest to get as much feedback from the community in this stage as possible.

Phase 2: Temperature Check — Discourse/Snapshot

A second separate governance forum post outlining the proposal in detail and incorporating any feedback from the Request For Comment phase. The post should be accompanied by a Snapshot poll. The Snapshot poll runs for 5 days, is decided by a majority, and requires a minimum of 300k yes votes to pass.

To create a Temperature Check:

  1. Use feedback from the Request for Comment post and create a new Snapshot poll which covers the options which have gained support. This poll can either be binary or multiple choice but should include the option “Make no change” or its equivalent. Set the poll duration to 5 days.

  2. Create a new topic in the Proposal Discussion category on titled “Temperature Check — [Your Title Here]“. This will alert the community that this topic is ready to move to an off-chain signalling vote and solicit participation. Any topics beginning with Temperature Check that have not started with a Request for Comment should be immediately be removed by community moderators. Make sure that the discussion thread links to the new Snapshot poll and the Request for Comment thread.

  3. Reach out to your network to build support for the proposal. Discuss the proposal and solicit delegates to vote on it. Be willing to respond to questions on the Consensus Check topic. Share your view point, although try to remain as impartial as possible.

At the end of 5 days, whichever option has the majority of votes wins, and can be included in a governance proposal for Stage 3. A 300k HOP yes-vote quorum is required for the Temperature Check to pass.

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

Phase 3: Formal Vote— Governance Portal

A final governance forum post incorporating any feedback from the Temperature Check phase. The proposal can consist of one or multiple actions, up to a maximum of 10 actions per proposal. If there is an on-chain action to be executed, the forum post should be accompanied by an on-chain vote. Otherwise, the post can be accompanied by a Snapshot poll that mirrors the same threshold parameters as an on-chain vote.

To create a Formal Vote:

(The governance portal is still being set up and will be available soon)

  1. If the proposal requires an on-chain action, write the code for your proposal, which can be voted on through any Governance Portal. More resources can be found here (coming soon). All proposed code should be audited by a professional auditor. This auditing process could be paid or reimbursed by the community treasury. Skip this step if the proposal doesn’t require an on-chain action.

  2. Ensure at least 1m HOP is delegated to your address in order to submit a proposal, or find a delegate who has enough delegated HOP to meet the proposal threshold to propose on your behalf.

  3. Create a topic in the Proposal Discussion category on titled “Formal Vote [Proposal Number] — [Your Title Here]” and link to any relevant Snapshot polls/discussion threads as well as the code audit report. Proposal numbers should be in a “HP###” format. For example, the first Hop Proposal should be titled HP001, the second HP002, and so on. Topics that begin with “Formal Vote” that have not successfully passed the Temperature Check and Request for Comment stages should be removed by community moderators.

  4. Call the propose() function of the Governor contract to deploy your proposal.
    Once the propose() function has been called, a seven day voting period is started. Ongoing discussion can take place in the forum. If the proposal passes successfully, a two day timelock will follow before the proposed code is executed.

Soft governance:

The process described above lays out a structure for those wishing to host a formal vote on a particular issue.

However, governance systems also require a degree of “metagovernance” discussions that inform the direction of and the implementation processes behind policy, but which don’t qualify as policy themselves.
The community may discuss new ideas and strategies for governance — including changes to the process outlined above — in the “Governance-Meta” category. On-chain voting is not necessary to make updates to off-chain processes.

Governance Glossary:

  • HOP: An ERC-20 token that designates the weight of a user’s voting rights. The more HOP a user has in their wallet, the more weight their delegation or vote on a proposal holds.

  • Delegation: HOP holders cannot vote or create proposals until they delegate their voting rights to an address. Delegation can be given to one address at a time, including the holder’s own address. Note that delegation does not lock tokens; it simply adds votes to the chosen delegation address.

  • Proposal: A proposal is code that is executed by the governance contract through timelock. It can replace the governance contract, transfer tokens from the community treasury, or perform an almost infinite range of other on-chain actions. In order to create a proposal, an address must have at least 0.1% (1mm) of all HOP delegated to their address. Proposals are stored in the “proposals” mapping of the Governor smart contract. All proposals are subject to a 7-day voting period. If the proposer does not maintain their vote weight balance throughout the voting period, the proposal may be canceled by anyone.

  • Quorum: In order for a vote to pass, at least 0.3% of all HOP (3mm) must vote in the affirmative. The purpose of this quorum is to ensure that the only measures that pass have adequate voter participation.

  • Voting: Users can vote for or against single proposals once they have voting rights delegated to their address. Votes can be cast while a proposal is in the “Active” state. Votes can be submitted immediately using “castVote” or submitted later with “castVoteBySig” (For more info on castVoteBySig and offline signatures, see EIP-712). If the majority of votes (and a 0.3% quorum of HOP) vote for a proposal, the proposal may be queued in the Timelock.

  • Voting Period: Once a proposal has been put forward, Hop community members will have a seven day period (the Voting Period) to cast their votes.

  • Timelock: All governance actions are delayed for a minimum of 2 days by the timelock contract before they can be executed.


Well reasoned and thought out. Appreciate the effort to lay a solid foundation for the community from day one.


Thank you for clearly identifying the governance process here, this is very helpful! What will Hop be using for on chain governance (i.e. compound governor, openzepplin, etc.)?


Glad to hear it! Hop governance uses the Open Zeppelin Governor contracts.


There seem to be a fake hop Snapshot account

Can we do anything about it?

I think the legal votes of 3million are too low. At present, the token price is 0.1$. It only needs 300000 dollars to decide a project of hundreds of millions. This is too exaggerated.
It is suggested that the legal votes should not be less than 10million.

Hey wanted to mention that I think the process should change a bit to bring it in line with other DAO processes which are also tried and work.


  • Temp check and snapshot vote are different. A temp check should be a period of X days of discussion in the forum where people 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.
  • The snapshot vote should be up for at least 7 days. Recommend more. Why? There is weekends, holidays, etc. Especially for a vote that may end up being controversial you need to give as much time as possible for people to vote.
  • The on-chain vote is just formal ratification of whatever snapshot decides and only needed for proposals that need to do on-chain actions.

May come up with more suggestions for the future, but for now these are the first things that came to mind.


These all seem like good suggestions and I think there’s benefits to being consistent with other DAOs too.

Do you think it makes sense to write up a proposal for these changes? Maybe someone else can help if you don’t have the time.