Snapshot with on-chain execution and a fallback to on-chain voting

Knowledge Base Archive
1

SafeSnap

TL;DR

This is a proposal to update the GnosisDAO’s governance structure in a way that keeps the benefits of off-chain voting while allowing for trustless and permissionless on-chain execution. It uses a combination of existing tools (Gnosis Safe, Snapshot, Reality, and Compound Governance), and will require a relatively small amount of custom dev work.

Why?

The current governance structure is designed to be maximally inclusive; gas-free voting with delegation. This, however, comes at the cost of some additional trust in the system. Primarily, the DAO must trust that the multi-sig will faithfully execute it’s will on chain.

In order to make the GnosisDAO more autonomous, we should more meaningfully give it control over its on-chain execution.

What?

Here are a couple of

  • Trustless and permissionless on-chain execution of arbitrary function calls
  • ERC20 token weighted voting
  • Cheap/free and low friction for voters
  • Good user interface and experience
  • Silent Ending (no last minute votes that change the outcome)
  • Safe module (must be able to control a Gnosis Safe)
  • Audited and secure (are we ok with trusting this system with thousands of ETH?)

How?

I’d like to propose an oracle-based solution, that looks something like this.

  • A Gnosis Safe module, where anyone can create a new proposal.
  • Each proposal is a Reality.eth question asking whether a linked Snapshot proposal passed.
  • If the proposal passes on snapshot, then reality should resolve to the same outcome and the proposal should be executed.
  • As a safeguard, we should use compound governance¹ as the arbitrator in Reality. That way we can always fallback to an onchain vote if an outcome is contentious.
  • There should be a delay (say 24 hours) between calling arbitration and the corresponding compound governance proposal starting, to give voters time to move their funds appropriately.

This setup means:

  1. no on-chain voting for the vast majority of proposals
  2. no need to wrap tokens, for the vast majority of proposals
  3. falls back to an audited and on-chain secure mechanism in the case of contention
  4. Relatively little implementation work since it’s plugging together several existing pieces

It is missing the silent ending feature, however, I don’t think it’s quite as important in this scenario because anything contentious enough to actually go to a vote on-chain should command high enough voter turnout as to render silent ending somewhat moot. That said, it still I nice feature to add and should be considered as either a stretch goal or a v2 improvement².

¹ it’s worth noting that compound governance will require an upgrade to the GNO contract to enable token snapshots. Since the GNO contract itself is not upgradable, this would likely be achieved via a wrapper contract used specifically for voting. This is part of reason for the delay between arbitration call and voting starting.
² There are several possible improvements for a v2 implementation of the compound governance module, including silent ending and snapshot at the end of the proposal rather than the beginning.

4 Likes
2

Great proposal. Thank you Auryn!

The arbitration fee could be set in GNO and paid to the compound governance participants as a reward. Also, the escalation process in Reality.eth itself could be done using GNO instead of ETH.

I am still a bit concerned to use Compound governance as-is for arbitration. Once someone calls arbitration, which can be done immediately after publishing a proposal, 24h might not be enough time to get GNO holders depositing their GNO to prevent a malicious proposal to pass.

I think this is good enough for a start when the multisig signers still have a veto option but not after the signers were removed.

Some additions to the Compound fork idea:

  1. Instead of a fixed deadline when a proposal is decided we implement a silent ending: In case the vote is flipping in the last 24h of the proposal deadline, the deadline is moved to 24h after the vote flipped.
  2. Instead of doing the snapshot of token holdings at the time the proposal is made to define voting rights, we allow users to deposit GNO anytime to gain more voting rights also for ongoing proposals. This is needed to make the silent ending feature really effective and allow escalation by having eventually more and more GNO locked and used for voting.
  3. GNO tokens, which are not used for voting on any of the active proposals can be withdrawn anytime. We can limit the number of active proposals at a time to 8 to allow on-chain verification of active proposal participation. This is important to convince users to deposit their tokens for voting in the first place and make capital costs for voters as small as possible. With a silent ending feature implementation, proposals don’t have a fixed duration, and withdrawals of GNO would have to be prevented for a long time to prevent double votes if we cannot keep track of active participation.
  4. We should require either a bond in GNO or locking a significant amount of GNO to create a proposal. This prevents spamming and makes malicious proposals costly.
1 Like