Zodiac is the missing piece between how most DAOs vote and how they act. A community runs its polls on Snapshot — gasless, off-chain, and non-binding — while its money sits in a Safe multisig that only a handful of signers can move. Between the two is a gap: something has to take a passed vote and actually execute the transaction, and for years that "something" was a small human multisig trusted to faithfully carry out the community's decision. Zodiac, an open contract standard built by Gnosis Guild and first released in 2022, is the toolkit that closes that gap — letting a Safe execute the outcome of a vote directly, on trust-minimised rails, without handing a multisig the keys to the treasury.
The Avatar / Module / Modifier / Guard standard
Zodiac's power is that it is a standard, not a single product. Per the Zodiac specification, it defines four composable roles around a programmable account:
- Avatar — the account that holds the assets and executes transactions (a Safe is the canonical avatar). It implements the
IAvatarinterface, whoseexecTransactionFromModulefunction is how everything else moves it. - Module — a contract the avatar enables that carries decision-making logic and can tell the avatar what to execute. A DAO can enable several at once.
- Modifier — a contract that sits between a module and the avatar and alters the module's behaviour — for example forcing a mandatory time delay on everything the module tries to do. A modifier looks like an avatar to the module above it, so modules and modifiers chain.
- Guard — a contract enabled on a module that runs pre- and post-checks on each transaction, constraining what it is allowed to do.
Because each role is just an interface, the pieces snap together like an expansion pack: you can chain a Delay modifier behind a Reality module behind a Safe, and the Safe neither knows nor cares which combination it is. That composability — rather than the monolithic, all-or-nothing design of a full framework like early Aragon — is the whole thesis.
Reality Module (SafeSnap): executing a Snapshot vote
The flagship module — originally shipped as SafeSnap and now the Reality Module — is what lets an off-chain Snapshot vote move an on-chain treasury. When a community drafts a Snapshot proposal, it can attach an array of transaction payloads to be executed if the vote passes. The outcome is then posted as a question to the Reality.eth optimistic oracle: anyone can assert "this proposal passed," a bond backs the assertion, and unless someone bonds a counter-claim within a challenge window, the result finalises. Disputes can escalate to Kleros arbitration. Once the answer resolves and a cooldown elapses, the transactions become executable by anyone through the Safe — the multisig is out of the loop entirely. The oracle, not a trusted signer, is what asserts the off-chain vote's result on-chain, which is why this pattern is called optimistic governance. A sibling module, the Optimistic Governor, does the same job against UMA's optimistic oracle instead of Reality.eth.
The rest of the kit: Delay, Roles, and Exit
The other modules address the everyday failure modes of running an on-chain organisation:
- Delay Modifier — enforces a mandatory cooldown between when a transaction is proposed and when it can execute, giving members a window to react (or exit) before anything moves. It turns any module into a timelocked one.
- Roles Modifier — grants scoped permissions, so a module or address can be allowed to call only specific functions on specific contracts (e.g. "this contributor may stake treasury assets in Aave but may not withdraw them"). It is the least-privilege layer for delegated treasury operations.
- Exit Module — lets any holder of a designated token redeem it at any time for a proportional share of the avatar's assets, generalising MolochDAO's
rageQuit()into a bolt-on any Safe can install (zodiac-module-exit, Exit App launched April 2022). It is the clearest on-chain expression of a member's right to exit: dissent by withdrawal rather than by vote.
Where it sits in the stack
Zodiac occupies the execution and permissioning layer of the DAO tooling stack — the connective tissue between the voting layer (Snapshot), the custody layer (Safe), and the binding on-chain governance that tools like Tally / Cactus front. Its appeal to large DAOs is that it lets them keep cheap, high-participation off-chain voting and get trust-minimised execution, without adopting a heavyweight on-chain Governor for every decision. The trade-off is assembly: a Zodiac-based DAO is a set of modules a team wires together and must configure correctly, and a misconfigured module or oracle is its own attack surface — the price of composability is that no single vendor hands you a finished, audited whole.
How Caper approaches this
Zodiac exists because, in the mainstream stack, voting, custody, execution and exit are separate contracts a DAO must bolt together — and each seam is a place where a multisig, an oracle, or a misconfiguration can sit between the members and their treasury. Caper takes the opposite route: those layers are one contract. A caper's proposals, votes and execution are native to the protocol, so there is no SafeSnap-style bridge to trust — a passed proposal is the authorisation to execute.
The contrast is sharpest at the Exit Module. Zodiac's exit is an optional add-on that returns a share strictly proportional to a redeemable token's balance. In Caper, exit is not a module you choose to install — every member holds it by construction, and the share is weighted by the same earned metric that sets voting power. A member redeeming caper tokens t together with their soulbound votes v receives a treasury fraction of (t · v) / (V · T) — the identical compute_vote_weight formula used when they vote (verified against contracts/src/caper_dao.rs). The vote tokens are soulbound and non-transferable, so exit weight is earned participation, not just a token you can buy on the way out. The right to leave with your fair share isn't a feature a caper's founders remembered to enable — it's the same primitive as the right to be heard.
References
- Gnosis Guild, Zodiac — composable tooling for onchain entities (standard & README).
- Gnosis Guild, Reality Module and Exit Module repositories.
- Snapshot, SafeSnap / Reality plugin documentation.
- Reality.eth, optimistic oracle; UMA, Optimistic Governor (oSnap).
- Gnosis Guild, zodiac.eco.