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:
- PROPOSE
- SIGN
- VOTE
- IMPLEMENT
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
Discussion
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.
Timelines
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.
Audit
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]
Referendum
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
Auditing
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.
Vote
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
Implementation
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.