Proposed Governance Process High Level Overview

UPDATE: The more detailed proposals can be found here: Community Trust Process Proposals - HOPR Community Forum

The official proposals related to this will launch on Monday to allow us to ease into the discussion somewhat. But just to provide some context, here is a short overview of the proposed governance process for the new Community Trust.

This sounds like a major overhaul, but basically the process will be the one you’re familiar with: discussion on Discourse forum, a signature process to signal support, gas-less voting on Snapshot. If the governance platform proposals pass well plan to upgrade these tools, but the early version won’t look too different from what we have now.

The basic verbs will remain unchanged:


HOWEVER, separating the community governance from the HOPR Association and establishing a legal wrapper does introduce some new security and compliance issues.

Proposal validity will be much stricter, as the trustee will not have ANY decision making authority to interpret proposals for implementation.

Proposal thresholds should be set to ensure funds are safe from governance attack and spam.

A new verb, AUDIT must be added to ensure that i) code in proposals does what it claims and ii) the proposal is legal in BVI (generally this will be find, but proposals can’t, e.g., send funds to sanctioned entities or be used to finance crimes. This all needs to be checked by someone).

The proposed process is as follows:

Someone with sufficient HOPR tokens PROPOSES something related to the community funds. They POST A BOND to show that they’re proposing in good faith and to cover potential costs at the AUDIT stage.

Sufficient users SIGN this proposal to signal that it passes a basic temperature check (it’s generally worth discussing, not obviously illegal)

Token holders DISCUSS the proposal, refining it to the point where it is clear, exhaustive, and can be implemented without any input from the trustee company

Sufficient users SIGN the finalized proposal to signal it should be put to vote

Token holders VOTE on the proposal. In addition to getting the most votes, a threshold of deployed tokens must be reached for it to pass (QUORUM). This is to prevent governance attacks.

At any point after the proposal is finalized, it can be put to AUDIT to confirm any code is safe and secure and that the proposal is legal.

If the vote and audit both pass, the proposal will be IMPLEMENTED by the trustee company.

When a proposal passes out of the system (either because it passes, it fails, or the proposer withdraws it, the bond is returned minus any incurred audit costs).

There are many individual parameters to set here (how long are the phases, what are the quorums, what should the bond be set at, what are the minimum proposal thresholds, etc. etc.)

There are also two separate cases: proposals about the governance (i.e., proposals to change what we decide this month) and emergency proposals which may need to be expedited instead of following the whole process. But we’ll discuss those in separate posts.

For now this explainer should hopefully give the shape of the proposed processes. We welcome all feedback.


I’m genuinely impressed with the depth and thought put into the proposed governance process. The rationale for choosing the BVI and the commitment to ensuring community trust while adhering to a legal framework is commendable. By adding an AUDIT step and clearly defining the proposal process, the proposal showcases a robust and balanced governance mechanism.


  • How does the selection process for the external auditor (who verifies the code and legal compliance) occur? Can the community have a say in this?
  • Given that the trustees have no decision-making power, what measures will be in place to handle unforeseen situations or crises which might require immediate intervention?
  • Are there provisions in the trust to manage potential conflicts of interest, given that members of the HOPR Association are expected to be directors?
  • How are you planning to ensure that the token holders from different regions, especially where DeFi is less understood, are aware of and comfortable with the legal implications of this new setup?
  • In cases where proposals don’t get implemented because they are either unclear or ambiguous, what mechanisms will be in place for feedback to the proposer?
  • With the BVI trying to establish itself as a friendly jurisdiction for DeFi, how does the proposal plan to adapt if there are major regulatory changes in the BVI?

I Have a Suggestion: Enhancement Proposal

Consider adapting our existing forum to serve as a “sandbox” mechanism for proposals. This integrated environment would allow for proposals to be temporarily implemented in a controlled manner without real-world implications to our ecosystem. Community members would have the opportunity to witness the potential outcomes of their suggestions in action, providing richer information for discussion and reflection prior to final voting. By utilizing the current resources of the forum in this new capacity, we can also swiftly identify and address any ambiguities or contradictions in proposals before their full-scale implementation.


Initially we would probably need to pick these from trusted people within the HOPR circle. Unfortunately having such people on retainer is expensive.

One planned part of the governance platform (which we’ll delve into next week) is to create a sort of “marketplace” for auditors. This would put out individual tasks out as bounties. This is both a cool web3 approach to the problem and should help reduce costs by properly aligning incentives.

This is something we’ll need to discuss at length. We have several options in mind, but increased governance responsiveness always has trade-offs in security. I’m opening a separate topic on this tomorrow.

We’re currently talking with our lawyers in the BVI about possibilities for these roles to be filled by externals or people from the community. There are also other roles like protector. This will also be discussed later in the month, but in short the protector’s role is to keep the trustees in check.

Another good question. We’re talking with lawyers to determine whether the setup of [different wrapped legal entities] + [distinct, wrapped governance platform] + [distinct sets of governed token holders] will provide sufficient liability protection, basically by creating an airgap between the participation and what’s actually being governed. It’s possible that proposers may need to meet different requirements than mere participants, which would suck but isn’t a disaster. We’re also looking into setting up separate legal wrappers for participation (e.g., a voting association). We’re trying our hardest to avoid situations where regular token holders need to identify themselves or rule themselves out of participating for legal reasons. Obviously at a certain point people will need to make themselves aware of the circumstances of their own jurisdiction, but we’re very keen for that not to be the norm. There are a lot of DAO constitutions out there which basically say “Not our problem” on this issue, and it’s pretty gross.

The hope is that 99% of such cases would fail at discussion / audit (which in some possible versions of the governance platform also includes moderation services). The bond mechanism and stricter proposal validity rules will hopefully create a strong incentive for proposers to put a lot of work into creating clear proposals. It’s also fairly usual for governance forums to have a separate section where people can workshop their proposals before submitting them to the system.

Of course there will always be proposals which cannot be implemented due to unforeseen circumstances after the vote. This is something we’ll need to discuss. The current plan is that the trustee will have a reporting obligation, and they would report the issue, refund any bond and basically try to reset things. Of course this is a potential avenue for exploitation, in this case the community would have ways to vote to change the directors or (in extreme cases) take legal recourse.

We’re in constant communication with our lawyers in the BVI, but I’m afraid I don’t have a more robust answer for you here. All I can say is we haven’t heard anything to suggest an upheaval like this is on the horizon. BVI is very different from US or even EU on this.

For the enhancement proposal, can you give some more details of what you’re imagining. We would simulate the outcome of the proposal to check that it can be implemented? That’s certainly possible for on-chain proposals, and the governance platform proposals will go into some options here. But for more “real world” proposals, I’m not sure what useful simulating can be done here, beyond talking out all the foreseeable consequences. But perhaps I’m not being imaginative enough?


Thank you for providing detailed information on the various aspects of your project. Let me address the questions and provide insights where applicable:

  1. Selection process for the external auditor: Your approach to creating a “marketplace” for auditors to crowdsource auditing tasks seems innovative. Considering the decentralized nature of your platform, would you be open to creating a reputation system within this marketplace? This way, the community can have insights into the quality of an auditor’s past work, making it easier to have confidence in the auditing process.
  2. Handling unforeseen situations: I look forward to the discussion on governance responsiveness. The balance between responsiveness and security is indeed crucial, especially when the stakes are high.
  3. Managing conflicts of interest: The idea of potentially allowing community members or external entities to fill roles is a good step towards transparency and trust. Depending on the feedback, you might also consider creating clear guidelines or codes of conduct to ensure ethical behavior among directors, trustees, and protectors.
  4. Ensuring comfort with legal implications: Your proactive approach to ensuring that token holders from various regions understand the legal implications is commendable. While you’re right in saying that individuals should be aware of their local laws, efforts to minimize legal burdens on the average token holder are important for a more inclusive platform.
  5. Feedback mechanisms for proposals: The approach of having a preliminary workshop for proposal discussions can greatly reduce the instances of unclear or ambiguous proposals reaching the voting stage. By investing in community education and a robust feedback loop, you could further streamline the proposal process.
  6. Adapting to regulatory changes in the BVI: Continuous communication with legal experts in the BVI is key. Having a contingency plan or considering diversifying your jurisdictional presence could help in mitigating potential risks.

For the enhancement proposal, can you give some more details of what you’re imagining. We would simulate the outcome of the proposal to check that it can be implemented? That’s certainly possible for on-chain proposals, and the governance platform proposals will go into some options here. But for more “real world” proposals, I’m not sure what useful simulating can be done here, beyond talking out all the foreseeable consequences. But perhaps I’m not being imaginative enough?

Thank you for your attention to this proposal. Allow me to clarify some aspects:

  1. Simulation of Real-World Outcomes: I completely agree with your sentiment that simulating real-world outcomes for off-chain proposals might be more challenging than for on-chain ones. However, the sandbox concept is not primarily about fully modeling real-world scenarios but more about testing and discussing the idea in a safe environment. This allows for potential issues to be identified and for the proposal to be refined and improved based on community feedback.
  2. Stages before the Final Voting:
  • Preliminary Discussion: Before a proposal reaches the voting stage, it should undergo multiple rounds of discussion. This allows community members to express their views, suggest improvements, or voice concerns.
  • Sandbox Voting: After discussion, the proposal can be temporarily implemented in the sandbox for a hands-on demonstration. This allows community members to better understand it and provides additional time for adjustments.
  • Main Voting: Only after successful sandbox testing and all necessary adjustments does the proposal proceed to the main voting stage.
  1. Utilizing Forum Resources: By adapting our existing forum as a sandbox, we can leverage tools and resources we already possess, simplifying and expediting the entire process.

I hope this provides clarity and offers a constructive pathway for the integration of this idea. Should you have further questions or concerns, I’m open to addressing them.


@AlexFOX Nailed all the questions here! @thewanderingeditor Thanks for answering most of them. @AlexFOX those are some valuable insights as well!


The cost manager side of me would like to see a “by the numbers” brief that shows the various pots of money, what the expected running expenditures are associated with this, and pros/cons of the proposal. If we’re going for transparency this is important to monitor if we’re truly going for a community managed operation.

I’d also like to have some form of Deadman’s-Switch implemented within the trust. That if no action or a lockout if enacted during a set period of time that entities vested (or disinterested) in the project will have a means of distributing the remains of the project if for whatever reason a catastrophic event occurs that prevent normal trustee business.

@AlexFOX bravo on each topic as well, kudos man.


Very wonderful


Will compile as much of that as possible for next week.

As for the dead man’s switch, the trust deed will include provisions for distributing the trust in event of dissolution. The named class of ultimate beneficiaries in this case is the HOPR token holders. More can be done here, but that’s the current working setup which has informed the specific choice of trust.


That last part was probably unclear. I mean that there are various trust types supported under BVI law (and elsewhere). One major distinction between them is how beneficiaries are handled.

A BVI discretionary trust has the useful dual purposes that we:

i) Can name the token holders as a generalized class of beneficiaries
ii) Don’t have to actually identify individual token holders

Being able to achieve both of these properties seems quite rare in the various jurisdictions we looked into. But obviously as a privacy project we’re keen to avoid situations where regular token holders have to doxx themselves. BVI is one of the few places where this seems to be possible.


Wow, it’s a lot to digest. Shout-out to @AlexFOX for deepen the discussion.
For now I have a simple question regarding;

So, if I understand correctly, the proposer needs to lock his/her tokens ($HOPR? $ETH?) and (if audit is required, its cost will be paid from this locked token. Am I correct?
But then isn’t it kind of demotivating the proposer as he/she has to cover the cost for the audit from his/her pocket?


While the proposed governance process for the new Community Trust seems comprehensive and well-thought-out, there are still several concerns and challenges that could be addressed:

1- Implementing an AUDIT stage introduces additional time and resource requirements to the process. How will the project manage potential delays caused by the auditing phase? Are there plans to ensure efficient and timely audits?

2- how will the project determine the appropriate values for QUORUM ? What considerations will be taken into account to strike a balance between participation and security?

3- How will the community determine what constitutes an emergency?

4- How does the project plan to engage and encourage broader participation from token holders who might not be as active or engaged in the governance process?

5- Requiring a bond to propose something might deter some community members from initiating proposals, particularly those who might have valuable ideas but limited financial resources. How will this potential barrier be addressed to ensure inclusivity?

Thank you,


The current working model is that all token interactions, including costs, would involve HOPR. This does introduce a couple of issues:

  • Auditors are unlikely to accept payment in HOPR. Conversion to stables or even fiat will need to happen. Where in the process does this occur and who should do it? There may be legal restrictions here. The BVI VASP Act covers activities which would qualify someone as a service provider. Converting crypto on someone else’s behalf might qualify if done as a business (wording of the Act). I have calls with our BVI lawyers next week about the details here.

  • HOPR (and ETH) change in value. The dollar value of the bond will fluctuate between posting and payment. What if there’s a shortfall? I have proposed processes for handling this, but it’s kind of messy.

Thanks for the questions. Sorry to only give half an answer so far. The issue of the bond and how to handle payment / refund will get its own thread next week.

So, if I understand correctly, the proposer needs to lock his/her tokens ($HOPR? $ETH?) and (if audit is required, its cost will be paid from this locked token. Am I correct?

Yes to the first part, the second part is complicated. I should also note that there will ALWAYS be an audit. At the very least, someone will need to affirm that the proposal is legal and possible. This might take five minutes and be totally obvious, but for liability reasons it will need to happen.

Who ultimately pays is up for discussion. My current preferred process is:

  • Proposer posts bond
  • Bond is used to cover audit costs
  • If proposal passes, the entire bond is refunded (treasury absorbs cost)
  • If proposal fails, only unspent bond is refunded
  • If audit costs exceed bond due to complexity, then proposer can choose to add more to fund the audit. In this case, if the proposal eventually passes, only the original bond is refunded.

What I like about this is that there is strong incentive to create proposals with minimal audit costs. The clearer and simpler the proposal, the easier it should be to audit and the lower this burden. Also clear and simple proposals are more likely to pass through the entire process and trigger a refund.

One huge issue with governance design is how to limit the proposal space. Left to their own devices (well-meaning) people create extremely vague proposals: it’s then a lot of work to turn this into something actionable.

But then isn’t it kind of demotivating the proposer as he/she has to cover the cost for the audit from his/her pocket?

So as explained above, it’s not necessarily from his/her pocket. But it could be.

This is, in many respects, a good thing. One thing that will be important to consider is: how much governance do we want? To which the glib answer is “exactly the right amount”. As always there are incentives to balance.

My position is the governance setup should facilitate governance, but it shouldn’t necessarily encourage it. Proposals all generate work for moderators and participants. And I don’t think there’s any correlation between number of proposals and quality.

Having a (potential) cost associated with proposing reduces pressure for spam. Just because people can propose stuff, doesn’t mean they should.

On the other hand, I’m very concerned about the costs being disproportionate: certain token holders will be priced out, whales might not even notice the cost. We also have proposals for mitigating this, including delegation and the possibility of a fund for communal proposals, but this answer is already extremely long, so I’ll return to those later.


Awesome questions. Thank you. In the same order as you asked:

1 - The hope is that auditing can be run in parallel with the other processes. Once a proposal is locked during discussion, it can move to auditing while the other phases are being carried out. Also the hope is that during discussion potential audit issues can be raised and fixed pre-emptively. The hope (maybe naive) is that beyond a certain point most auditing looks the same. Once the process has been run a few times, it will become clear how proposals need to be structured to minimize audit costs (both time and money).

2 - This is indeed a huge question. Setting these values and the trade-offs here with be the bulk of the discussion for August, starting Monday

3 - Another good question. Again, we’ll have dedicated thread(s) for this issue beginning Monday. Here I’m less confident on reaching an optimal solution. It’s a very hard problem to even define, let alone solve. But we’ve been thinking about this and do have some things to share already.

4 - I think the governance process as a whole should have as few barriers to participation as possible, but ultimately people who aren’t engaged are making a choice and only they can choose to be more engaged. I will say that I think our current (full) processes (discussion, referendum, vote), which we don’t always run do a good job of encouraging participation from different levels of engagement an token holdings: highly engaged people can participate throughout; people who care less can check in once the proposals are finalized and sign them (or not), even if they don’t hold many tokens; then at the vote stage people can once again jump in, even if they haven’t followed the full discussion.

This intuition is borne out by our consistently high participation rates relative to number of token holders, which is one of the highest in crypto. It remains to see if it will scale, of course.

5 - Pricing out those with good ideas but limited funds is indeed a concern. My current thinking is to have a separate “track” of proposals: a sort of community space where people can make proposals and petition for larger token holders to take up the mantle on their behalf. This might work, and is similar in thinking to various delegation models, although I always feel those have a little bit of a gross feudal feeling to them…

Another option is to have a community fund for supporting proposals. This would add an extra stage (people would have to first vote which proposals to fund the bond for, then on the proposals themselves), but I think it could be workable.


Hi, thanks for your inputs, very insightful. Implementing a community fund to support proposal bonds seems like an interesting idea. Could you elaborate on how this fund would be managed, funded, and governed? How will the decisions to allocate funds to specific proposals be made?

1 Like

Thanks for explaining some of the key factors regarding beneficiaries that led to choosing BVI.

Sifting through the other comments, such as requiring proposers to post bond in the response to Satopin; any idea on what a proposal bond could cost and using any particular asset? I like that idea to limit errant requests and have an option for community members within the vote to have responses with "yes or “no” or “irrelevant” where an irrelevant majority squashes the proposal and penalizes the bond.


Wow! A lot to digest here…
There are some very thoughtful & insightful comments here - so I don’t really have a lot to add…

  • Regarding token holders not engaging - have you considered allowing vote delegation (with maximum % cap for any individual delegate)
  • I like the community fund idea to allow smaller holders access to the process if they can convince enough people to support the proposal - maybe require some element of individual pooled bond
  • I expect that there will be different levels of Audit depending on the complexity & type of proposal - perhaps there could be 2 - 3 different bond levels depending on the Audit type (this could evolve over time)

A few questions wrt implementation:

  • Why rely on Snapshot for votes? It’s a centralized system, their backend has terrible reliability and they push breaking changes to their API with no warning. HOPR uses gnosis chain where gas is extremely cheap, surely a smart contract based system would be an improvement for a minor additional cost to users. The small tax on voting (gas fee) also means that voters may think a bit more before voting (rather than just vote for whatever and get an NFT later).

  • I think there’s a need to decouple the proposal from the BOND or at least to give other community members the opportunity to post/add BOND for a proposal. From experience, a lot of innovation and valuable contributions in DAOs (this isn’t exactly the case with HOPR for now since it has a more “corporate” structure and is relatively young) often comes from new entrants to the community (see Synthetix, Curve, Maker) who don’t always have a lot of tokens or money as opposed to whales/OGs who run more lazy and less creative with time.

  • With regards to payment, as someone else mentioned, using HOPR as a dump token to pay for everything will not be aligned with token holders’ benefits. This may result in a blocking situation where token holders refuse to finance innovation because they’re afraid it’ll devalue their token. We should discuss vesting systems or taking out loans backed by HOPR (if we can work with a lending platform to get that) so that the tokens can be turned to USD without dumping (ofc need a healthy collat ratio).

  • For smart-contract related code, why not enforce smart-contract updates or new features via smart contract at the protocol level? For instance with a deployer proxy that can be activated by the DAO, or similar solutions. IMO this seems more essential that setting up a whole legal entity whose sole job is to press a centralized team based on the outcome of a vote that is not binding anyways.


hopr to the moon

1 Like