Topic-specific Validity Rules

Hi everyone! This is a complex topic, so there are quite a few stipulations on what qualifies as a valid proposal. This is the list from the announcement blog post, along with a short explanation of why these stipulations are in place.

  • Funds can only be redistributed to decentralized exchanges which are listed on Coingecko with an average 24h trade volume of at least $1m as of May 5th.

There are good arguments for moving liquidity to small DEXs, but tiny DEXs are too big a risk. They’re also likely to be a huge time / cost sink to set up, with limited upside.

  • Proposals can distribute liquidity across up to a maximum of five exchanges. All exchanges and chains must be clearly specified.

As above. Spreading liquidity too thinly introduces risk, and setting up pools on too many exchanges will be too much of an implementation burden. We don’t want to pull resources from the dev team any more than we have to.

  • For each decentralized exchange, the proposal must specify the intended token pairing(s) in addition to the amount of liquidity to be put there.

For obvious reasons, we need proposals to be clear and unambiguous. The HOPR Association will be in charge of implementation, but no meaningful decision making should be required, or that defeats the point of the governance exercise.

  • If a decentralized exchange has additional parameters (e.g., token weighting), these must be specified.

Every DEX is different, and some require quite a lot of decisions before a pool can be deployed. This is the validity clause that we expect to cause the most issues, as it’s constantly evolving as we look into the different exchanges. We’ll keep you updated as we do more research, but bear in mind that it’s possible that a proposal might change from VALID to INCOMPLETE as new information about a particular DEX becomes available.

  • ALL liquidity must be redistributed. If you would like to propose leaving some of the liquidity in its current location, this must be specified.

It might make sense to leave some liquidity untouched, but this still needs to be specified so moderators know that this is deliberate, rather than a failure to allocate the full 100%

  • Proposals must describe the planned redistribution in terms of percentages, not raw amounts.

The amount of UNI-V2 tokens to cash in is fixed, but their value fluctuates with the market. We won’t know precisely how much funding is available until the tokens are cashed in. For this reason, proposals in raw amounts might be impossible to fulfil, or leave liquidity unaccounted for.

The standard validity rules also apply, meaning a valid proposal must:

  • Fully address the topic of the vote

  • Be unambiguous in its implementation

  • Not contravene any laws or regulations

  • Be in accordance with the HOPR values and manifesto

There’s a small possibility that a proposal marked as valid can become incomplete as new information about implementation on specific DEXs come to light. If that happens, you’ll be notified and given help to make the proposal valid again.

1 Like

Additional validity requirements for Uni v3:

Proposals which move liquidity to UNI v3 must specify both the fee tier and the price range

More context can be found here:Uni V3 Validity requirements

And here:

Another rule which is perhaps an obvious combination of practicality and the HOPR values, but we feel should be stated outright:

It must be possible to add the HOPR Token or a bridged version of the HOPR Token to a proposed DEX. If bridges are involved they should be privacy respecting and not require KYC or signups. Bridges should be minimally custodial.

A new validity requirement relating to managing funds on DEXs:

All chains in a proposal need to support proper management of the liquidity on the chosen DEXs (i.e., adding, removing and whatever other interactions are required for LPs) through a 3-of-5 multisig