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.