Kleros Reality Module

From the Zodiac app within the Safe app, you can deploy a Kleros Snapshot Module. This is a wrapper of the already existing Reality Module, and will automatically deploy it using Kleros as arbitrator. This module is available in Mainnet, Gnosis Chain, and Polygon.

Setup

Open your Safe dashboard, and click on Apps, search Zodiac, and open it.

Click on Kleros Snapshot Module. If you can't see it, it might mean your safe is in a different chain. Kleros is only available on Mainnet, Gnosis and Polygon.

Fill in the information. Some guidelines:

Timeout is a setting that affects the questions that will be created in Reality. An answer will be considered true if it remains unchanged during this period, unless called to arbitration.
Cooldown is the period from the point the answer is final, to the point the transaction batch can be executed. This is used to prevent malicious answers that might have slipped through from causing immediate damage, by allowing potential victims to react. In order to prevent damage, parties using the Safe are expected to stay vigilant and regularly pay attention to questions created by this module, as anyone is able to create them, without going through a Snapshot proposal.
Expiration is how long until an accepted transaction batch becomes too outdated to be executed.
Bond is the minimum amount required to post an answer to a question. Keeping it large makes it more punishing to attackers. Remember this amount is denominated in the chain's native token.

Monitoring

You can use Open Zeppelin Sentinel to monitor proposals. Take into account that anyone can submit a proposal to the Reality Module, so they are not to be trusted. With this monitoring system, you will be notified through various channels whenever a proposal is submitted. If a proposal turns out to be malicious, it must be countered through rejecting it's validity in the reality.eth question it will create.

SafeSnap

If you encountered this warning:

Install SafeSnap after creating the module

it means one of the following:

The controller of the ENS is not the Safe.
You are not in Mainnet.

From here, you have two options. Most of the time, you will want to install SafeSnap manually.

Have the Safe in control of the Snapshot Space

This is only supported if you are in Mainnet.

Don't do this if you're just testing.
Don't do this if you're planning on decentralizing later. You can do it later when you're ready.
Do this if you know what you're doing, and you want to decentralize immediately by removing all the signers of the Safe later.
This will cost more gas.

To do this, go to the ENS frontend and type the ENS in. The deployment will work if you just Set the Controller of the ENS with the address of the Safe, but, if you want the Space to be fully in control of the Safe, and not in the control of anything else, you will need to Transfer the ENS itself.

Configuring SafeSnap manually

Just fill in the parameters normally, click on Add Module, and sign the resulting transactions. This will create a Reality Module with everything set up.

After doing this, use a wallet you can use to change the Snapshot Space settings. Open Snapshot, and go to settings.

Go to the Settings -> Advanced, Add Plugin.

In network, type in the network id of the chain the Safe is in, quotes included.

Mainnet: "1", Gnosis Chain: "100", Polygon: "137"

In realityAddress, paste in the address of the Reality Module. You can find this address in your Zodiac App. Check the screenshot below, the left side of the screen.

For the field umaAddress, you can either ignore it or remove the line. Check the sample config below for a deployment on Mainnet.

{
  "safes": [
    {
      "network": "1",
      "realityAddress": "0x0811dE7b6CA6fF61C24eB8C6C885F44d1Bca4c28"
    }
  ]
}

Missing `daorequirements`

When you deploy the Reality Module, you will also setup a default template for the Reality questions that will be created. Within this template, there is a section that mentions the following:

and does it meet the requirements of the document referenced in the dao requirements record at ${dao}.eth?

For reference, here is a sample question created by the Reality Module.

If this dao requirements record document does not exist, then it can be possible to resolve the question as No, since it is not possible to match the requirements of a document that does not exist. Alternatively, it could be resolve as Yes, since, if there are no requirements, that means there are also no restrictions.

Questions can ultimately be applied for arbitration, by clicking Apply for arbitration in Reality. This has a fixed cost, but parties that have already posted an answer might be incentivized to pay this cost, instead of posting a new answer and doubling the bond. This fixed arbitration cost can change depending on the chain. The Terms of Service of the Kleros Arbitrator for Reality include some guidelines to limit the potential damage of not having set the daorequirements record, instructing the jurors to investigate the project, forum, etc, to find a reasonable frame of reference to find out these requirements, and assume some defaults if these requirements cannot be found. Still, this is a failsafe mechanism that should not be relied upon, at it can lead to different assumptions.

In order to avoid this uncertainty, we advice adding a daorequirements record in the Snapshot Space ENS. To do so:

Create an acceptance document (plain text, pdf, anything is fine)
Proofread it to ensure it will not have unintended consequences. Kleros has experience writing policies and acceptance documents for subjective oracles, feel free to contact us if you want us to take a look.
Upload the document to IPFS.
Go to the ENS frontend, access the ENS of the Snapshot Space, click on Add/Edit Record, and add a new record by selecting text on the left selector, typing in daorequirements in the right selector, and pasting the IPFS identifier.

For reference, here is the ENS record of gnosis.eth, you can find a daorequirements record that points to a plaintext file with a well defined acceptance criteria.

How to Use the Reality Module

After the SafeSnap plugin is installed in your space, there will be an extra step when creating proposals, that will allow the creator of the proposal to propose a batch of transaction batches. After you do, a proposal like this will be created.

If the proposal passes, you will be allowed to begin execution. This will create a question in Reality.

From here, you can answer the question directly, using Set outcome.

You can handle it directly from Snapshot, or go to Reality by clicking Question. It is adviced to do it in Reality, as you will be able to read extra details, such the contents of the question, the terms of service of the arbitrator, and how long does it take for the current answer to be valid.

When the question is finally resolved, execution will not be able to start until the Cooldown period passes. When it passes, you can use Snapshot to execute. Open the proposal that was accepted, and on the SafeSnap plugin on the bottom, you can execute the transaction.

Legal entity for your DAO

After activating a Zodiac Reality module, you may consider establishing a legal entity in jurisdictions that enable your DAO to manage a real-world legal entity. This step is beneficial for managing real-world assets and participating in legal contracts.

To facilitate this, we recommend consulting with one of our partners who specialize in these arrangements: