Should GnosisDAO Enable 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, using the recently released DAO module and SafeSnap plugin.

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, GnosisDAO must trust that the GnosisDAO Safe Multisig will faithfully execute its will on-chain.

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

What?

Gnosis Ltd recently developed the DAO module and SafeSnap Snapshot Plugin.

In combination with the Gnosis Safe, this tool allows for:

  • Trustless and permissionless on-chain execution of arbitrary function calls
  • Continued use of our existing Snapshot strategies (ERC20 BalanceOf and Delegated ERC20 BalanceOf)
  • Cheap/free and low friction participation for Participants.

How?

As described in the SafeSnap announcement post, the path to progressive decentralization can be broken down into three steps.

  1. Multi-sig as a proxy: Gnosis Safe + Snapshot, in which the multi-sig promises to act in accordance with the off-chain votes. This is the status quo.
  2. Multi-sig as a safeguard: Gnosis Safe + Snapshot + SafeSnap, in which on-chain execution of off-chain votes is handled by the SafeSnap module, but there are still multisig owners that can veto malicious actions or act quickly in the case of an emergency.
  3. Look ma, no hands!: Gnosis Safe + Snapshot + SafeSnap, in which the multi-sig owners have been removed, and the only way to execute transactions is via the SafeSnap module.

This proposal is to move from (1) to (2) by deploying an instance of the DAO module, enabling it in the GnosisDAO Gnosis Safe, and updating the GnosisDAO Snapshot space to include the SafeSnap module.

The DAO module should have the following parameters set:

  • Oracle: GNO denominated instance of Reality.eth
  • Reality question timeout: 48 hours
  • Proposal cooldown: 48 hours
  • Proposal expiration: 7 days
  • Minimum bond: 10 GNO
  • Question Template: see this document
4 Likes

I’m obviously pretty biased, but I’d definitely support this.

One question, since the Reality arbitrator is not specified, I assume that means that the Safe itself would be the arbitrator?

It is a necessary step to decentralize GnosisDAO. I am in favor.

1 Like

One question, since the Reality arbitrator is not specified, I assume that means that the Safe itself would be the arbitrator?

I’m also biased (not leaning in the same direction though) but:
Would the GnosisDAO Safe being the arbitrator of its own proposal enforcement disputes a bit antithetical to the initial concept of giving over control?

Since this proposal doesn’t remove the multi-sig owners, I don’t really see this as an issue. The multi-sig owners have the ability to veto the dao-module transaction anyway (or do whatever else they want with the safe, for that matter), so I’m not sure there is a compelling reason to add a third-party arbitrator to the setup.

That said, perhaps if the GnosisDAO later chooses to remove the multi-sig owners, then it would be prudent to have some other fallback or arbitration option.

My (perhaps incorrect) understanding was that the veto power of multi-sig owners in the step 2 of the decentralization path was at the Gnosis safe level (by simply not executing the Tx.).

My thought here was that setting up the GnosisDAO safe as the arbitrator of Reality.eth would actually just add a redundant way to veto enforcement of proposal earlier in the process at the oracle level, which could have been done at the Safe level anyway. Please correct me if I’m wrong.

This would mean setting up 2 safeguards, when one could have sufficient.
Maybe, there is a step 2.1 as you described and a step 2.2, where the arbitrator is a decentralized 3rd party but multi-sig owners still have veto power of not executing Tx.

Yeah, you’re correct. This does essentially act as a redundant veto.
In fact, there is a third redundant veto in this setup; multi-sig owners could disable the module.

The additional step of adding a third-party arbitrator sounds reasonable to me. Perhaps someone can suggest this as a later proposal if this GIP is enacted.