---
# System prepended metadata

title: 'Towards a (1) permissionless, (2) automated and (3) transparent governance mechanism'

---

# Towards a (1) permissionless, (2) automated and (3) transparent governance mechanism

In a "traditional" governance setup, token holders vote on proposal off-chain (mostly via Snapshot) and the owners of a multi-sig Gnosis Safe execute the proposal outcome, that is they assemble and execute the specific transaction that has been voted on (if it has been voted _for_). In this model, the voters basically depend on the goodwill of the multi-sig owners for a timely execution of the their (the voters') will.

## 1. Permissionless: Safesnap (aka Gnosis DAO module)

Safesnap, aka the Gnosis DAO module, creates a permissionless alternative to the "traditional" governance setup by placing the power to execute transaction from a Gnosis Safe in the hands of the users.

### Safesnap in a nutshell

SafeSnap connects Snapshot (offchain) votes with onchain transaction execution through a Gnosis Safe. It uses a protocol called realitio/reality.eth to serve as oracle for the outcome of the offchain-voting.

The process looks as follows: Users vote on a proposal via Snapshot. The proposal includes the transaction(s) to be voted on in a standardized fashion. When the vote has finished, anyone can feed the outcome of the vote ("should the following transaction(s) be executed by the Safe? yes/no") into the Reality.eth (realitio) smart contract (= anyone can feed the oracle). This smart contract had previously been set up by the Gnosis Safe owners and given rights to execute transactions without their (the owners') consent. There is an economic escalation game in place that disincentivizes users to feed incorrect proposal outcomes to the oracle.

If still the oracle is fed with wrong proposal outcomes, any user can request arbitration. Practically this means that a third smart contract that had previously been defined by the Gnosis Safe is requested to determine the proposal's final outcome. This arbitrator contract can be customized.

If the outcome of a proposal has been finalized - let's say people voted for a given transaction - depending on the configuration there can be a predefined cooldown period during which the Gnosis Safe can still dismiss the transaction (optional!). After this cooldown period has passed, anyone can initiate the execution of the proposal transaction through the Snapshot UI. It is **not** necessary for the Gnosis Safe owners to sign off the transaction.

The idea would be to implement a **custom arbitrator contract** that bases the arbitration outcome on **on-chain voting**. Basically the proposed governance system can be reduced to **off-chain voting on on-chain transaction execution with on-chain voting as last resort in case of a dispute**.

### Realitio/reality.eth key principles (escalation game)

- anyone can answer a question via realitio:
  - the question in our case is the snapshot proposal and
  - the answer is its outcome
- to answer a question you need to stake some tokens (e.g. ETH), if your answer is accepted (= not challenged for a certain period of time) you receive your stake back
- if you overturn someone else's answer by staking more than them, you receive their stake
- arbitration costs a fixed fee (which can be configured)
- arbitration can optionally be requested by any user to determine the final answer of a question in case of a dispute
- the arbitration fee is not returned (it is kept by the arbitrator)

### Example User Flow

Assumption: Arbitration fee is set to 5 ETH

1. There is a new proposal to send all DAO funds to malicious Joe on snapshot
2. DAO members vote NO => snapshot outcome is NO (off-chain)
   (now anyone can stake 1 ETH and "feed" the proposal outcome into the blockchain)
3. I stake 1 ETH and feed the correct answer (NO) into the blockchain
4. malicious Joe stakes 2 ETH and overturns my answer to YES on the blockchain (he receives my 1 ETH stake)
5. I stake 4 ETH to again propose the correct answer NO (I get his 2 ETH stake)
6. Joe stakes 8 ETH to propose YES (gets my 4 ETH)
   (at this point my net balance is minus 3 ETH and the wrong answer is set on the blockchain)
7. Now, I could stake 16 ETH and hope that Joe doesn't have sufficient funds to overturn me. However, the optimal strategy for me is to request arbitration. I pay 5 ETH to the arbitrator, who will determine that my answer was in fact correct (by comparing the snaphost outcome to my proposed answer). I will receive the latest stake (Joe's 8 ETH), my net balance is zero (neglecting gas) and the correct answer is finalized on the blockchain.
8. Since in this example the finalized outcome is to NOT send all DAO funds to Joe, there is no transaction to be executed by the Gnosis Safe. If the outcome would have been to execute a certain transaction, any user could initiate the execution of the transaction by the Gnosis Safe (via the Snapshot UI). Depending on the configuration, the transaction could be executed immediately, or after a cooldown period during which the safe owners could still veto the transaction. The user would incur the gas costs of the transaction.

## 2. Automation: server

As described above, anyone can feed the outcome of a proposal into the realitio contract. After an outcome has been finalized (that is it has not been challenged over a period of time _or_ it has been determined by the arbitrator) it can be executed by anyone. This is what makes the governance mechanism permissionless, but it also creates friction in that it requires users to take these actions (and to incur gas costs as a consequence).

This friction could be reduced by setting up a server that takes over these basic tasks: (1) feeding the proposal outcome into the oracle and (2) executing finalized proposals.

### Server tasks

- monitor the PrimeDAO snapshot location for new finalized proposals
- retrieve the proposal outcomes for these new finalized proposals from snapshot (accepted or not accepted?)
- feed the proposal outcome to the realitio contract via its own PK
- monitor the realitio contract
- TBD: defend against malicious actors by going through the escalation game & requesting arbitration when necessary
- when outcome on the smart contract side has been finalized, initiate the transaction (if there is any)

### Is this still permissionless?

Short answer is yes. The server would only take over cumbersome manual work by feeding the oracle that would otherwise need to be done by some user. At any point any user can overturn the proposal outcome that is fed into the oracle, or request arbitration.

## 3. Transparency: UI

Even though the proposed system is fully decentralized, it still can only be trusted by users if it is also tranpsarent. Transparency in this context means that users must be able to easily (1) monitor the proposal outcomes that have been fed into the oracle, (2) feed proposal outcomes into the oracle by themselves, (3) request arbitration.

The existing realitio UI does not fulfill these requirements and there is currently no Safesnap integration for the boardroom UI.

Creating a simple UI that enables these three functions would significantly improve the value of the proposed governance mechanism.
