GIP-11: Enable SafeSnap

Governance GIPs
1

GIP-11: Enable SafeSnap

  • Enable SafeSnap
  • Make no changes

0 voters 

GIP: 11
title: Enable SafeSnap
author: @auryn_macmillan
status: Phase 3
type: Meta
created: 2021-06-10
requires: GIP-10

Simple Summary

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.

Motivation

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.

Specification

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.

Rationale

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.

Implementation

The DAO module should have the following parameters set:

  • Oracle: GNO denominated instance of Reality.eth 0x8f1CC53bf34932591177CDA24723486205CA7510
  • Reality question timeout: 48 hours
  • Proposal cooldown: 48 hours
  • Proposal expiration: 7 days
  • Minimum bond: 10 GNO
  • Question Template: see this document
  • Arbitrator: Reality.eth contract, so that it is not possible to call arbitration
    0x8f1CC53bf34932591177CDA24723486205CA7510

Transactions that need to be executed:

On the gnosis.eth ENS name:

  • set snapshot text record to ipfs://QmPdrDbYVPCz6ASgYvvYWkdpDmZ7pph7TnT4K3zhq1dfP7
  • set daorequirements text record to ipfs://QmP5ptVAmAcBLJB5bpZntADLieaWRc2iN2V8UQBRoQDA56
  • set registrant and controller to 0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe
  • set quorum text record to 60,183.480050548

On the deployed DaoModule:

  • update questionArbitrator to 0x8f1CC53bf34932591177CDA24723486205CA7510
  • update minimumBond to 10 GNO
  • update questionCooldown to 48 hours

On the GnosisDAO’s safe:

  • call enableModule("0x0eBaC21F7f6A6599B5fa5f57Baaa974ADFEC4613")

GnosisDAO Snapshot

GIP-11 Snapshot proposal

7 Likes
2

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?

3

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

1 Like
4

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?

5

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.

6

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.).

image
image734×255 54 KB

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.

7

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.

8

I just realized that this has been sitting in Phase 1 for a while, so I’ve gone ahead and moved it to Phase 2 and opened a poll.

I also re-organized the content of the OP to match the GIP template.

9

You could argue that as long as the multisig owners have control over the DAO they can also be arbitrators. But this IMO gives them unnecessary extra power since they could determine who would win the escalation game of reality.eth.

So I guess I would be in favor of removing the arbitrator all together and if that is technically not an option simply set the arbitration fee to 100m ETH or something like that.

1 Like
10

They have unilateral control over the Safe either way, so they don’t really have any extra power in this case. That said, I do agree that there is a subtle distinction between them being able to decide the outcome of a proposal and them having veto power and unilateral control.

One option would be to just set the arbitrator to 0x0000000000000000000000000000000000000000, or some other invalid account.

11

@auryn_macmillan it still gives them extra power.
While true that they fully control the Safe (might be restricted with “guardians” in the new Safe version) they CAN NOT determine the winner of the Reality.eth staking game. Theoretically - if there should be a big escalation that could mean control over a large percentage of the circulating GNO.

This is an explicit extra power that they currently don’t have and I see no reason to give it to them.

1 Like
12

Wouldn’t removing the arbitrator and having an unbounded GNO-based escalation game just give power over Reality.eth to the biggest GNO holder? In the sense that he could always outbid the opposing answer, except if a very ambitious crowdfunding campaign enables other holders to oppose him.

I don’t actually know who the biggest GNO holder is but it could well be one of the signatories of the multi-sig and just make the model less secure in the end.

13

No, because users can pool funds.
However, it would give power to the largest coalition of GNO holders that can coordinate around the same answer.

1 Like
14

Right - but here the idea is simply, that the largest coalition of GNO holders controls the DAO anyhow

2 Likes
15

So your preference is set the the arbitrator to 0x0 (or some other invalid address) or to set it to Kleros with some unreasonably high arbitration cost?

16

basically, simply make sure arbitration can never be called.

I don’t know the contract well enough to decide how to best achieve that. E.g. is there any problem if you set the arbitrator to 0x0000
cc @edmundedgar

17

Unfortunately the existing contracts check for a missing arbitrator out of an excess of caution and will refuse to let you create a question with 0x0. I can’t think of anything bad that wouldn’t have happened if they hadn’t done that.

It’s a bit hacky but I guess we could do 0xffff…ffff, that mirrors the value we use for “invalid” answers. I’m not sure how the current UI code will handle that but if it doesn’t work I can fix it. I like having a fixed address to mean “not gonna arbitrate” because I can display that information fast without doing extra RPC calls.

1 Like
18

@edmundedgar is there any other way to simply “disable” arbitration? E.g. set the arbitration fee to 10000000000 ETH? Or can the arbitrator set the outcome even if no one pays the arbitration fee?

19

Yes, setting an arbitrator contract that doesn’t have the feature of being able to send arbitration notifications will disable arbitration. Any address will do, as long as it doesn’t either have that specific feature or have the ability to do make arbitrary contract calls. A “legitimate” arbitration contract with an unfeasibly high fee as you mention would also work.

Currently if the arbitrator contract doesn’t respond to getDisputeFee I’ve got the UI showing a message, however the message could be a bit clearer if we knew that arbitration couldn’t happen, either because it was a specific previously-deployed arbitration-impossible contract with a registered address or because it was a known nothing-up-my-sleeve address like 0xffff…ffff or address(keccak256(“no arbitration”))

20

That being the case, I’d suggest that 0xffff...ffff is probably the right solution.