Proposed Governance Processes

Here you will find an outline of the proposed governance rules for the HOPR Community Trust. Items with links are subject to change via proposals at the link.

(Proposals and links are currently being created - this part in italics will be deleted once this is complete.)

If there are parts which you think should also be subject to a proposal, please indicate which and why.

This outline will be updated and refined throughout the discussion period.

General Process

The general process employs the same verbs and phases as the current HOPR governance:

  • SIGN
  • VOTE

Two additional concepts are introduced: AUDIT, to check the validity and legality of proposals, and posting a BOND, to cover the audit costs.

Proposals are made and discussed in a dedicated Discourse forum instance. Proposal “signing” during the referendum phase also occurs here.

Voting occurs on a dedicated Snapshot space. Temperature checks and process votes (e.g., to extend discussion) also occur here.

Auditing is initially handled via Discourse until a separate audit marketplace can be established.

Who can participate?

For Sybil protection, minimal identity checks and token balances are required. The more power an action gives you, the higher the proposed threshold.

Join forum: Joining the Discourse requires a registered unique address containing >10 HOPR tokens. No other identity checks.

Propose: Making a proposal requires signatures from registered unique addresses containing at least 500,000 HOPR tokens. These users will all be co-proposers.

Post bond: Anyone can post a bond for any proposal. Bond amount is 100,000 HOPR tokens (200,000 for meta proposals).

Post in Discussion: Creating a thread or posting a reply requires a registered unique address containing at least 1,000 HOPR tokens

Sign: Signing a post required a registered unique address containing at least 100 HOPR tokens

Vote: Any address containing at least 10 HOPR tokens can vote

Making a Proposal

To make a proposal, it must be co-signed by users registered in the forum with unique registered addresses containing a combined total of at least 500,000 HOPR tokens. Each user signing a proposal in this way becomes a co-signer of the proposal.

At the time of proposal each co-signer must indicate how much of their balance is being contributed to the proposal. Users do not have to lock their tokens, but the same tokens cannot be used to contribute to different proposals. The combined contributed balance must remain over 1m until the vote closes.

A bond of at least 100,000 HOPR tokens must be placed, not necessarily by the proposer. The bond will be held in a ringfenced multisig controlled by the trustee and protector(s).

Proposal Scope

Proposals must be related to the funds controlled by the Community Trust or the governance processes of the Trust. Proposals which do not match this scope should be deemed invalid.

Proposal Categories

Not all proposals are equal in terms of complexity and risk. In general, proposals which require off-chain interactions from the trustee are deemed riskier than fully on-chain proposals. Proposals which involve changing the governance processes are deemed even riskier.

  • On-chain: Proposals related ENTIRELY to on-chain assets and can be described entirely via code, wallet transactions or smart chain interactions (e.g., rebalancing Uniswap position)
  • Off-chain: Proposals with off-chain components (e.g., exercising shareholder rights in HOPR RiSe)
  • Meta: Proposals related to changes to the governance processes or the running of the trust (e.g., changing voting thresholds)

Each level should bring increasing levels of restrictions. A proposal always falls into the strictest category which applies, even if it isn’t the bulk of the proposal.

Proposals which are entered into the wrong category should be deemed invalid.

Proposal Validity

To be valid, proposals must generally be possible, legal and fall in general scope (must be related to the funds controlled by the Community Trust or the governance processes of the Trust)

In addition:

  • On-chain proposals must contain a full description of all code which must be run, wallet transactions must be made and smart chain interactions
  • Off-chain and meta proposals must contain a full description of al steps which must be taken to implement the proposal

Temperature Check

An initial temperature check will determine whether proposals should be blocked from continuing with discussion

This is a 24hr vote on Snapshot. Invalid proposals can technically pass the temperature check, but the hope is that they would not.

Proposals which are generally valid but not yet specifically so can pass to discussion, where goal is to refine them


Proposals which pass the temperature check move to the discussion phase, even if they don’t yet pass the full validity checks.

The goal of the discussion is to refine the proposal and make it specifically valid. Anyone can discuss the proposal and suggest changes. The proposer may adjust the proposal at any time.


Discussion runs for a minimum of one week and can be extended by one week up to twice by the proposer (at their discretion) or community (by bringing an extension vote identical to the initial temperature check).

Higher risk proposals should have longer discussion times.

Discussion on meta proposals always lasts for the full three weeks.

Proposal Validity

To be valid a proposal must:

  • Be in scope
  • Be exhaustively described such that the trustee can implement it without further decision making.


Proposals must be audited to ensure that they are legal and that any code is safe and does what it claims it will do. Validity is related to, but separate from, the audit process.

The proposer may lock a proposal at any time and trigger the audit process. Beyond this point the proposal may not change.

Passing discussion

To pass to the next phase, proposals must be fully valid and receive the following levels of support:

On-chain: 20% of active participants
Off-chain: 25% of active participants
Meta: 30% of active participants

Active Participant Definition

The precise definition of active participant still needs to be created [Tbd]


Proposals which pass the discussion phase are moved to the referendum section of the forum

Referenda on proposals run for at least 72 hrs. Any forum member with at least 100 HOPR tokens may sign the proposal to signify support

To pass to the next phase, proposals must have passed the audit process and received the following levels of support:

On-chain: 30% of active participants
Off-chain: 35% of active participants
Meta: 40% of active participants


All proposals must be fully audited before passing to the vote stage

The audit costs are taken from the initial bond of 100,000 HOPR tokens. The bond will be placed in a ringfenced multsig controlled by the trustee and the protectors.

If costs exceed the bond, anyone has the opportunity to increase the bond.

This bond is reimbursed if the proposal passes and is successfully implemented.

The proposer may withdraw their proposal at any time. If they do, the bond will be reimbursed, minus any audit costs accrued so far.


Proposals which pass the referendum criteria pass to the vote phase once they are fully audited.

The vote is held on snapshot using a modified version of quadratic voting. All holders of at least 1000 HOPR tokens on Gnosis Chain or Ethereum Mainnet have vote power equal to [balance ^ 0.75]

Votes last for the following timespans:

On-chain: 72hrs
Off-chain: One week
Meta: Two weeks

To pass, votes require the following levels of support

On-chain: 50%
Off-chain: 50%
Meta: 66%

And must reach the following quora:

On-chain: 10m HOPR tokens
Off-chain: 15m HOPR tokens
Meta: 25m HOPR tokens


Proposals which pass the vote stage will be implemented by the trustee following the instructions in the proposal

Emergency Process

It is possible that circumstances require faster governance than these processes allow. In these cases, an alternative process can be triggered. [Tbd]

Guardrail Mode

The HOPR Association suggests that these processes begin in “guardrail mode”, a constrained process setup where proposals can only be created at certain times. Governance would run in six-week cycles, with proposal creation only possible at the beginning of each cycle.


At first I was concerned about the 500,000 threshold but seeing that people can join together to propose makes this much less a burden on serous proposals. I do think the bond mechanism for auditing needs a little more explanation. So the bond provider pays for the audit but is reimbursed if it passes? And if they retract their proposal they will only pay for expenses? This risk/reward seems a little off for me. Obviously this will deter unserious actors from
Proposing proposals however will this stifle creativity? In other words seems to me I’m risking that only if it’s a sure thing or the reward to my self interests is high enough that it negates the risk. I just wonder about the unintended consequences of it.


Is it possible to add as an extra layer, how old the wallet is? Or for how long has been holding the $HOPR token. Just a thought.


How would you use this? Grant more power to longer-standing tokens?

1 Like

Your governance framework proposal displays a comprehensive and well-structured approach that clearly reflects your consideration of the community’s decentralized nature. However, it’s important to address some potential concerns:

  1. Complexity for Newcomers:While your process is thorough, its complexity might pose a challenge for newcomers. To mitigate this, it’s crucial to offer easily understandable documentation, tutorials, and support for participants who are new to the governance process.

  2. Token Concentration:The establishment of a high threshold for certain actions could inadvertently lead to token concentration within a select group of users. This concentration might result in a skewed decision-making process, potentially undermining the community’s democratic ideals.

  3. Auditing Costs:The inclusion of an auditing requirement adds significant value by upholding quality standards. However, it’s essential to ensure that the associated auditing costs remain reasonable and manageable. Balancing the benefits of auditing with the financial burden it might impose is key for sustainable governance.

1 Like

great suggestion

1 Like

well-thought framework, however one important aspect to consider is ensuring that the community’s voice is heard. You might want to emphasize mechanisms for community feedback and the incorporation of diverse perspectives throughout the process.

The inclusion of “Guardrail Mode” to begin with a more constrained governance setup is a wise approach to gradually test the new framework’s effectiveness before transitioning to a fully open process.

Yes, this can be one use case. Or for sybil.

Support this proposal

Just catching up after summer holiday and catching up with work, but was wondering how the support levels and quora token values were arrived at? Was tis based on our previous results or some other metric?

I used a variety of metrics, including:

  • analysis of all HOPR token balances and their distribution
  • results from previous votes and how much it would cost to sway them
  • total circulating supply
  • similar figures from other successful DAOs
  • similar figures from other UNsuccessful DAOs (i.e., analysis of governance attacks and how they were conducted)

But I admit this is may not easily translate to the new HOPR community governance setup and involves a lot of guesswork


yeah I think this is on the face of it a good idea - add some weight/standing in some way to wallets that have been around for a while. Certainly the age of the wallet per se is not really meaningful, you could have had a wallet for 5 years and bought hopr yesterday for example.

So the idea of having some weighting on the length of holding makes more sense if that is to be some type of ‘age’ layer.

but why have this as you say - only reason I can think of is that you could have some limit on when a wallet can join a vote/create a proposal etc. That way you could minimise the possibility of bad actors creating loads of wallets today and funding them and using them to create disruptive proposals or sway votes in a certain direction in a governance attack by only allowing those actions after a wallet has held x amount of hopr for x amount of time. probably has downsides too of course

1 Like

Yes I think this makes sense only if there’s a massive drop-off in the penalty.

It is important to mitigate against flashloan attacks (i.e., just get the tokens you need to win the vote, then immediately sell them again), but I find it less hard to justify a linear weighting (i.e., I don’t see why the vote power loss from 0 months vs 1 months should be the same relative to 2 months vs 3 months)

Ah ok seems like a good idea to include good and bad experiences of other DAO’s but I guess its a minefield hence the guesswork premium. LOL

no I don’t see any reason to get a higher vote power just cos you have been here longer than the next person. getting in early has its own intrinsic benefits on a successful project and also in this one for node running we already know that our Network NFTs will bring the benefit of a lower stake entry point so longevity is going to be rewarded there ( for node runners at least)

1 Like

support the proposal

1 Like

similarly, I support this proposal, although the requirement for the number of HOPR tokens for “Voting” could be increased from 10 to 100.

Support this proposal