Skip to main content

Overview

This guide covers setup and configuration only. For what SafeSnap is, its components, and how the end-to-end flow works, see the SafeSnap product page.

Setup Steps

1

Deploy Zodiac Reality Module

Deploy the Reality Module through the Zodiac app and connect it to your Gnosis Safe. Configure it with:
  • The Reality.eth contract address for your chain
  • A Kleros arbitrator proxy as the arbitrator
  • Minimum bond and timeout parameters
2

Install SafeSnap Plugin

Add the SafeSnap plugin to your Snapshot space. This adds a transaction builder to proposals, allowing proposers to attach on-chain transactions.
3

Set DAO Requirements

Upload a DAO requirements document to IPFS and register it as an ENS text record under the key daorequirements on your Snapshot space’s ENS name.This document defines the criteria for valid proposals. Kleros jurors evaluate proposals against this document when arbitrating disputes.
4

Monitor Proposals

Any address can post a question to the Reality Module, so monitoring is part of the security model, not optional. Run kleros/zodiac-bots, the open-source service Kleros maintains for watching Zodiac Reality modules. It tracks one or more Snapshot spaces — identified by ENS name and a starting block — and pushes alerts to Slack, Telegram, or email when proposals and answers appear:
Email recipients can be scoped per space, so different DAOs’ alerts route to different inboxes. If you would rather not self-host, a general-purpose monitoring service such as OpenZeppelin Defender or a custom bot can watch the same Reality.eth events.

Reality.eth Question Format

The Reality Module creates questions in this format:
Jurors evaluate:
  • Whether the Snapshot vote actually passed per the space’s voting rules
  • Whether the proposed transactions match what was described in the proposal
  • Whether the proposal complies with the DAO requirements document

Arbitration

When a Reality.eth answer is disputed, anyone can request arbitration by paying the Kleros arbitration fee. The Kleros Arbitrator Proxy:
  1. Creates a dispute in Kleros Court (typically the Blockchain or Technical subcourt)
  2. Displays the proposal details, transaction data, and DAO requirements document to jurors
  3. Returns the ruling to Reality.eth, which finalizes the answer

Evidence

Evidence is submitted through the Kleros Arbitrator Proxy. Typical evidence includes:
  • Screenshots of the Snapshot vote results
  • Links to the proposal discussion
  • Transaction simulation results
  • References to the DAO requirements document

Configuration Reference


Security Considerations

Malicious proposals: Anyone can submit proposals to the Reality Module. The bond requirement and Kleros arbitration backstop mitigate this, but active monitoring is essential. Missing DAO requirements: If the daorequirements ENS record is not set, questions may be resolved ambiguously. Set this record before activating the module. Bond exhaustion: A well-funded attacker can force multiple bond escalation rounds. The Kleros arbitration option provides a fixed-cost resolution path when bonds become prohibitively expensive.

Resources

Zodiac Documentation

Full Zodiac module documentation

SafeSnap Guide

Snapshot SafeSnap plugin setup

Reality.eth Integration

Kleros + Reality.eth documentation

Kleros Reality Module Guide

Detailed module setup instructions