[Request for Comment] Updating Voting Frameworks for Community Governance

đź—łMeta-Governance
1

The Hop DAO Community Governance Process currently relies on a combination of Snapshot temperature checks and on-chain voting for multisig execution and/or on-chain voting for decision-making. However, there is a need to update and clarify this process to better reflect the needs of the community and ensure that all decisions are made in a transparent and fair manner, while balancing efficiency and responsiveness in decision-making. To that end, we propose the creation of a modified voting framework that will allow for more flexibility and responsiveness in decision-making.

1) No vote nor HIP needed. The Community Multisig can execute autonomously if small values are involved/transferred (less than $5,000) and does not directly benefit any person/entity outside of the Hop DAO itself.

   Examples:
    - Claiming an airdrop (value of airdrop claim is <$5,000 market value)

2) Snapshot-only HIP. A simple snapshot vote (via snapshot) will be sufficient for decisions involving larger values (greater than $5,000) from the multisig or for decisions that do not impact the core Hop Protocol. This will allow the community to have a say in decisions that could have a significant impact on the Hop DAO, but will not require the full on-chain voting process which can be time consuming and resource intensive.

   Examples:
     - Directing community multisig's veNFT to a new Velodrome pool (market value of veNFT is ~$40,000, calculated as 2M VELO @ $.02)
     - This proposal modifying the Community Governance Process (no changes to core protocol)

3) Fully on-chain HIP. A fully on-chain vote (via tally.xyz) is only needed if executable code is attached to the vote or if changes are being made to the core Hop Protocol. These decisions are of the highest importance and will require the full transparency and participation of the community to ensure that they are made in the best interests of the Hop DAO. HIPs which fall into the category of a fully on-chain vote would also still require Snapshot temperature checks as currently outlined in the governance process.

   Examples:
     - Funding new multisig for grants program (requires on-chain transfer of $HOP via executable code)
     - Deploying Hop Bridge to new chain (change to core Hop Protocol)

If this RFC becomes a proposal, it would be the first HIP falling into category 2 for which only a Snapshot vote is necessary. This effectively replaces the current temperature check phase of the existing governance process. For proposals in category 3, however, a temperature check on Snapshot would still be needed before a fully on-chain vote.

8 Likes
2

I love how straight forward this is @fourpoops.

This is an ideal set up IMO. Snapshot voting enables higher participation and the liability is still capped by the value controlled by the multisig.

Another great outcome is that Hop can use cross-chain governance for all Snapshot votes which should cover the majority of decisions under this framework.

I believe it was discussed previously but it could be worth further defining “small values are involved/transferred (less than $5,000)”. Otherwise, I think this will bring some much needed clarity.

3 Likes
3

I think this is a great proposal and much needed.

Asking a question out of ignorance, aren’t claims or ERC20 transfer method still executable code? If so, then maybe a better definition could be done, something like “Executable code with an impact below $5,000 can be executed with no vote nor HIP needed”.

For the first category, we can also request proof of the transaction, e.g. tx hash and asset pricing to validate the amount being below threshold. This is may look as more work, but still less than going thru a snapshot + on-chain vote.

4

Very nice. There is beauty in brevity.

1 Like
5

We already discussed this slightly, but, while this is a great outcome, the one downside is that in the case of fully on-chain HIPs, it may mean the on-chain vote is slightly differently distributed than the cross-chain votes on snapshot preceding it. Generally, I think the pros of having cross-chain contributions on snapshot make it worthwhile anyway. Do you know who is able to change the voting parameters to include multi chain $HOP holders on snapshot or can any delegate do that when making a snapshot HIP?

Yeah, this is probably going to be a definition/method that runs into edge cases that need finessing down the road. Generally, I am thinking of “value” as the market value of whatever is being transacted upon. In other words, if the market value of an airdrop that the multisig is eligible for is currently valued at $4,000, the multisig can claim it autonomously. If the market value is valued higher, the multisig needs approval from a snapshot-only HIP. As an example of a potential edge case, we already know there are airdrops which start off with non-transferrable tokens. In this case is the market value 0? Maybe, so the multisig can claim it autonomously. Then if the token becomes transferrable and trades on the open market, the “value” rule could come into effect. If the multisig wants to then sell this airdrop for USDC or HOP, it would follow the guidelines based on the current market value of the sale of that token.

The distinction here is that the executable code is coming from the governance timelock contract (0xeeA8422a08258e73c139Fc32a25e10410c14bd7a) via an onchain vote from tally.xyz vs. a simple transaction from one of the community multisigs. For more context, the governance timelock currently has 590M $HOP whereas the multisig on Ethereum (0x60224984338DeDe521C56DEE7a09e446A5a163f4) currently has 9.1M $HOP and the multisig on Optimism (0xc988107688b750dee6237b85a3ca49ba0a65dab0) has $OP and a veNFT. Anything coming from the governance timelock contract would have executable code and is then automatically a fully on-chain HIP (category 3).

1 Like
6

Hello,

I voted yes on this proposal.

I think it streamlines and removes a lot of unnecessary work, especially with decisions that do not need to be strictly enacted on chain and a Snapshot vote is sufficient, which most of them are.

Thanks for your work, fourpoops.

7

Hey fren thanks!

This is exactly what we were discussing in the multisig compensation proposal that lead to a lot of confusion due to an on-chain vote also being opened for something that has no actionable movement.

I wholeheartedly agree with this amendment. There is no need to open an on-chain vote if nothing needs to happen on-chain.

Will vote yes. :+1:

Again thanks for this RFC.

8

This has been put up for a vote on snapshot, which is the first to be governed by its own proposal and would also fall into category 2 for which only a Snapshot vote is necessary: Snapshot