Every DAO decision has to answer two separate questions: where do members cast their votes, and where does the winning decision actually take effect. The two can live in different places. A vote can be a cheap, gasless signature that no contract ever reads, or it can be a transaction that a contract counts and then acts on automatically. The choice between off-chain and on-chain governance is really a choice about how much you trust the humans in between — and it is the single biggest architectural decision most DAOs make. Tally's own explainer frames it plainly: off-chain voting is a poll, on-chain voting is an execution.

Off-chain governance: gasless signals

Off-chain voting moves the ballot off the blockchain entirely. A voter signs a message with their wallet — the same cryptographic signature a transaction uses, but never broadcast to a validator — and the signed ballot is pinned to IPFS so it is tamper-evident and publicly auditable without ever touching gas. The dominant platform, Snapshot, tallies these signatures against a past block ("the snapshot") so voting power reflects who held the token before the proposal existed, not who bought in to swing it.

The appeal is participation. Because voting is free, turnout is higher, small holders are not priced out by gas, and a DAO can run frequent temperature checks without spending a cent of treasury on transaction fees. Snapshot also supports rich voting strategies — weight by token balance, by staked or vote-escrowed balance, quadratically, or by any composition a DAO defines — because none of it has to run inside a gas-metered contract.

The cost is the trust assumption at the end. An off-chain vote is only a signal: nothing happens on-chain until someone — almost always a multisig of trusted signers — reads the result and executes it manually. Members are trusting those signers to honour the vote and not to act while nobody is looking. That is a real, if usually socially-enforced, point of centralization, and it is the defining weakness off-chain governance trades away for cheapness. The Decentraland DAO is the canonical live example: MANA and LAND holders vote gaslessly on Snapshot, and a DAO Committee multisig then enacts the binding result on Ethereum.

On-chain governance: binding execution

On-chain voting puts the entire process inside smart contracts. Proposals are submitted as transactions, votes are transactions the contract counts, and once a proposal passes the contract itself carries out the action — moving treasury funds, changing a parameter, upgrading code — with no human in the loop. The reference implementation is OpenZeppelin's Governor, the pattern behind Compound's Governor Bravo and most of the DAOs listed in this wiki's ecosystem directory. Voting power typically comes from an ERC20Votes-style token that checkpoints balances by block so weight can be read at the proposal's snapshot without a separate off-chain tally.

What you buy is trustlessness. A passed proposal executes exactly as written; no multisig can quietly decline to run it, and no one has to be trusted to move the funds. What you pay is cost and speed. Every vote is a gas-metered transaction, which suppresses turnout and prices out small holders, and the full pipeline — proposal, voting period, timelock, execution — is deliberately slow. That slowness is a feature: the mandatory timelock between a vote passing and taking effect is the window in which members who disagree can exit before the change lands.

On-chain governance has classically meant one chain — the Governor contract, the token, and the treasury all live together. A newer pattern stretches it across chains: Wormhole's MultiGov keeps votes and execution fully on-chain but lets holders on any connected chain vote with tokens that never leave home, aggregating the ballots to a hub over cross-chain messaging. It buys reach at the price of a new trust assumption — the message layer carrying the votes must itself be trusted not to forge or drop them. That assumption, and the three ways DAOs in production have chosen to price it, are the subject of cross-chain governance and multi-chain execution.

The hybrid most DAOs actually run

In practice the two models are not rivals — they are stages of one pipeline. The mainstream DAO proposal lifecycle runs off-chain first and on-chain last:

• Forum discussion. An idea is floated and debated on a governance forum (Discourse, Commonwealth) with no vote at all.
• Off-chain temperature check. A Snapshot vote gauges support cheaply. Most ideas die here, before anyone spends gas — which is exactly the point of doing it off-chain.
• On-chain formal vote. Proposals that clear the temp check are submitted on-chain, where the binding vote and its quorum, proposal threshold, and timelock live.
• Execution. The contract self-executes, or a multisig executes the on-chain result.

This split lets a DAO filter cheaply and commit expensively: the throwaway signalling happens where it is free, and the treasury only pays gas for decisions that already have demonstrated support. a16z's governance FAQ treats this staged flow as the default shape of modern DAO governance.

Bridging the gap: SafeSnap and oSnap

The hybrid still leaves the trusted-executor problem: after an off-chain vote passes, a multisig must be trusted to enact it. Optimistic execution bridges close that gap. SafeSnap — built on Safe modules and the Zodiac Reality module — lets a Snapshot result be posted on-chain and then automatically executed unless someone challenges it within a dispute window, with the challenge adjudicated by an optimistic oracle. Its better-known successor, UMA's oSnap, no longer works: UMA retired it on 15 December 2025, and since that date the module cannot execute transactions from a DAO's Safe treasury at all. The distinction between the two, and what to check before trusting either, is set out under optimistic governance. The DAO keeps the cheapness and high turnout of off-chain voting while removing the multisig's discretion to ignore or alter the outcome. It is the closest the two-layer model comes to trustless off-chain governance — at the price of a new trust assumption in the oracle that resolves disputes.

Choosing a model

There is no universally right answer; the choice tracks what a DAO is deciding.

• Off-chain suits frequent, low-stakes, or signalling decisions — sentiment checks, grant rankings, social choices — where turnout matters more than trustless enforcement.
• On-chain suits high-stakes, adversarial, or irreversible actions — moving large treasury sums, upgrading contracts, changing who controls the protocol — where a trusted executor is exactly the risk you cannot accept. The Beanstalk attack is the cautionary tale: an on-chain governance system with no timelock let a flash-loaned supermajority execute a treasury drain in a single block.
• Hybrid — off-chain to filter, on-chain to commit — is where most large DAOs have landed, and optimistic bridges are steadily narrowing the trust gap between the two ends.

How Caper approaches this

A caper collapses the two-layer model into a single binding on-chain flow. There is no off-chain signalling layer and no multisig executor standing between the vote and the outcome: proposals are submitted, voted on with ranked choice, and — for the winning option — executed by the contract itself on Radix after the voting window and a short execution delay. A passed PAYOUT or INVEST moves treasury funds with no human able to decline it, and the execution delay plays the timelock's role — the window in which a dissenting member can take their participation-weighted exit before the action lands.

The trade-off is deliberate and honest: a caper gives up the gasless, high-frequency experimentation that off-chain signalling makes cheap, and in return removes the trusted-executor risk entirely — the failure mode that optimistic bridges exist to patch does not arise, because there is no off-chain result to enforce. Caper does not answer the one thing on-chain systems usually push off-chain: casting a DAO's collective voice inside another organization's decision. A VOTE proposal kind that would have done exactly that belonged to the pre-August 2026 escrow system and did not return with the ballots — the contract rejects kind 2 by name, and vote() admits only an account it checks against the caller, so a treasury cannot cast the tokens it holds. A caper's reach into another caper is economic: buy in with an INVEST, sell down with a DIVEST. As always the specifics live on the linked governance pages; this article is the map of the territory they sit in.

References

• Tally, On-chain vs off-chain voting.
• Snapshot, Documentation — gasless, IPFS-stored signed-message voting; and Snapshot X, the on-chain successor protocol.
• OpenZeppelin, Governor and ERC20Votes — the reference on-chain governance stack.
• Safe, Smart account modules; Gnosis Guild, Zodiac Reality module — the SafeSnap optimistic-execution bridge. UMA, oSnap deprecation notice (retired in December 2025).
• a16z crypto, Governance FAQ.
• Vitalik Buterin, Moving beyond coin voting governance (2021).