Topic Where a DAO's votes are …gned messages, stored on IPFS —– a signal (Snapshot) On-chain…tes + execution in a contract —– binding and trustless (Govern…per One binding on-chain flow —– the contract is both ballot b…vernance/tooling/voting/tally)

Every DAO decision has to answ…u trust the humans in between —– and it is the single biggest …s a message with their wallet —– the same cryptographic signat…ever broadcast to a validator —– and the signed ballot is pinn…pports rich voting strategies —– weight by token balance, by s…any composition a DAO defines —– because none of it has to run…appens on-chain until someone —– almost always a multisig (/w…ury/safe) of trusted signers —– reads the result and executes…itself carries out the action —– moving treasury funds, changi…g a parameter, upgrading code —– with no human in the loop. Th…olders, and the full pipeline —– proposal, voting period, timelock, execution —– is deliberately slow. That sl…s classically meant one chain —– the Governor contract, the to…ice of a new trust assumption —– the message layer carrying th…the two models are not rivals —– they are stages of one pipeli…ere, before anyone spends gas —– which is exactly the point of…dges close that gap. SafeSnap —– built on Safe modules (https…guild/zodiac-module-reality) —– lets a Snapshot result be pos…rustless off-chain governance —– at the price of a new trust a…akes, or signalling decisions —– sentiment checks, grant rankings, social choices —– where turnout matters more th…rial, or irreversible actions —– moving large treasury sums, u…ing who controls the protocol —– where a trusted executor is e… in a single block. - Hybrid —– off-chain to filter, on-chain to commit —– is where most large DAOs have…rusted-executor risk entirely —– the failure mode that optimis…d not return with the ballots —– the contract rejects kind 2 b…(https://docs.snapshot.box/) —– gasless, IPFS-stored signed-m…/api/token/erc20#ERC20Votes) —– the reference on-chain govern…guild/zodiac-module-reality) —– the SafeSnap optimistic-execu…17/12/17/voting.html) (2017).

Every DAO decision has to answ… a DAO's Safe treasury at all.The distinction between the tw…cessary party to every change.Nodes cannot be given votes, b… changing the outcome is tiny.His example of low turnout is …other organization's decision.A VOTE proposal (/wiki/govern…17/12/17/voting.html) (2017).

Every DAO decision has to answ…s has to organise a hard fork. A DAO that runs Snapshot votes through a multisig keeps a version of the loose form: its signers can decline to execute a vote they judge to be an attack. Choosing a model There is n…17/12/17/voting.html) (2017).

Every DAO decision has to answ…acle that resolves disputes. The 2017 case against binding votes Two essays from December 2017 made the case against binding votes, about blockchain protocols rather than DAOs. The Ethereum researcher Vlad Zamfir published a rebuttal of an essay on blockchain governance by Fred Ehrsam, arguing against on-chain governance, which he defined as nodes upgrading automatically once an on-chain process approves an upgrade ( Against on-chain governance (https://medium.com/@Vlad_Zamfir/against-on-chain-governance-a4ceacd040ca) ). Under the off-chain process that was the norm, each node operator decides whether to install a hard fork, an upgrade that changes the chain's rules, so operators are a necessary party to every change. Nodes cannot be given votes, because one party can run any number of them, so a chain that upgrades itself on a coin vote takes the decision away from node operators and, through them, from users. Zamfir also argued that coin holders and users want opposite things: users have to buy the coin from holders, and holders gain when using the chain costs more. In his view that conflict applies to any process driven by coin holders, futarchy (/wiki/dao-governance/concepts/voting/futarchy) and votes with locked coins included. Vitalik Buterin's Notes on Blockchain Governance (https://vitalik.eth.limo/general/2017/12/17/voting.html) , published later that month and linking Zamfir's essay, separates tightly coupled voting, where the result takes effect automatically, from loosely coupled voting, where the result is a signal that people still choose whether to act on. Both kinds share the problems of coin voting he sets out: turnout so low that a small share of coins can swing a result, and bribes that work because each voter's chance of changing the outcome is tiny. His example of low turnout is the 2016 Carbonvote, an ETH-weighted poll on whether Ethereum should hard-fork to reverse the theft from The DAO, which drew a participation rate of 4.5%. The two kinds differ in what a community can do about an attack. A loosely coupled vote can be ignored once the community agrees it is an attack, and the Carbonvote left out ballots from known exchange addresses. A tightly coupled vote has no such remedy, because deciding whose votes to exclude would itself be a governance decision, and a minority that objects has to organise a hard fork. A DAO that runs Snapshot votes through a multisig keeps a version of the loose form: its signers can decline to execute a vote they judge to be an attack. Choosing a model There is no …1/08/16/voting3.html) (2021). - Vlad Zamfir, Against on-chain governance (https://medium.com/@Vlad_Zamfir/against-on-chain-governance-a4ceacd040ca) (2017). - Vitalik Buterin, Notes on Blockchain Governance (https://vitalik.eth.limo/general/2017/12/17/voting.html) (2017).

Every DAO decision has to answ…foundations/what-is-a-caper) collapses the two-layer model into a single bindingputs both layers on-chain flow. There is no off-chain signal…ayer and no multisig executor standing between the vote and the outco…ki/governance/proposals) are submitted, voted on with ranked choice, and — for the winning option — executed by thecreated, ranked and tallied in the caper's own contract itself on Radix (https://www.radixdlt.com/) , after the voting window and a short execution delay. A passed PAYOUT or INVEST (/wiki/governance/execution) 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 (/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) before the action landnd a passed action is performed by that contract when anyone calls it, with no signer able to alter or decline the payload. The vote alone does not move funds. After the tally a market window opens, and the action executes (/wiki/governance/execution) only if the caper's average price over the window holds at or above a baseline locked when the window opened. That window plays the timelock's role: a member who objects can sell, or, if they have cast a ballot, take their exit (/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) for a share of the treasury before the action lands. A passed action that nobody executes within a fixed deadline lapses. The trade-off is deliberat…1/08/16/voting3.html) (2021).

Every DAO decision has to answ…hain result to enforce. Caper also has a nativedoes not answer to the one thing on-chain systems…ther organization's decision. ItsA VOTE proposal (/wiki/governance/proposals) kind lets one caper vote, on-chain and by its members' ranked choice, in anothat 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 ther caper's proposal — org-to-org delegation without a signalling detourller, 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…1/08/16/voting3.html) (2021).

Topic Where a DAO's votes are …d execution Bridges SafeSnap / oSnap —(Zodiac Reality) – post an off-chain result on-c…, executable unless challenged. UMA's oSnap was retired 15 Dec 2025 (https://docs.uma.xyz/resources/osnap) On Caper One binding on-chai…vernance/tooling/voting/tally)

Every DAO decision has to answ…ution bridges close that gap. Tools like SafeSnap and its successor oSafeSnap — built on Safe modules …ule (https://github.com/gnosisguild/zodiac-module-reality) — lets a Snapshot result be posted o…cated by an optimistic oracle. Its better-known successor, UMA's oSnap, no longer works: UMA retired it on 15 December 2025 (https://docs.uma.xyz/resources/osnap) , 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 (/wiki/dao-governance/concepts/voting/optimistic-governance) . The DAO keeps the cheapness a…ule (https://github.com/gnosisguild/zodiac-module-reality) — the SafeSnap / oSnap optimistic-execution bridge. UMA, oSnap deprecation notice (https://docs.uma.xyz/resources/osnap) (retired in December 2025). - a16z crypto, Governance F…1/08/16/voting3.html) (2021).

Every DAO decision has to answ…ted 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 (/wiki/dao-governance/concepts/fundamentals/cross-chain-governance) . The hybrid most DAOs actuall…1/08/16/voting3.html) (2021).

Every DAO decision has to answ…nting member can take their pro-rataarticipation-weighted exit (/wiki/dao-governance/co…1/08/16/voting3.html) (2021).

Every DAO decision has to answ…a governance forum (Discourse, Commonwealth (/wiki/dao-governance/tooling/voting/commonwealth) ) with no vote at all. - Off-…1/08/16/voting3.html) (2021).

Topic Where a DAO's votes are … Proposal lifecycle (/wiki/daos-governance/concepts/voting/proposal-life…ken-weighted voting (/wiki/daos-governance/concepts/voting/token-weighte…voting) , Snapshot (/wiki/daos-governance/tooling/voting/snapshot) , Tally (/wiki/daos-governance/tooling/voting/tally)

Every DAO decision has to answ… always a multisig (/wiki/daos-governance/tooling/treasury/safe) of tr… Decentraland DAO (/wiki/daos/organizations/social/decentraland-dao) is t…osystem directory (/wiki/daos/organizations/dexs/uniswap-dao) . Voting pow…mandatory timelock (/wiki/daos-governance/concepts/voting/proposal-life…xit 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 (/wiki/daos/infrastructure/wormhole) 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. The hybrid most DAOs actually … proposal lifecycle (/wiki/daos-governance/concepts/voting/proposal-life…e Beanstalk attack (/wiki/daos-governance/concepts/analysis/dao-securit…heir pro-rata exit (/wiki/daos-governance/concepts/membership/rage-quit…1/08/16/voting3.html) (2021).

Topic Where a DAO's votes are …ifecycle (/wiki/daos/concepts/voting/proposal-lifecycle) , Token-w…d voting (/wiki/daos/concepts/voting/token-weighted-voting) , Snapshot (/wiki/daos/tooling/voting/snapshot) , Tally (/wiki/daos/tooling/voting/tally)

Every DAO decision has to answ… multisig (/wiki/daos/tooling/treasury/safe) of trusted signers — re… Decentraland DAO (/wiki/daos/organizations/social/decentraland-dao) is the cano…osystem directory (/wiki/daos/organizations/dexs/uniswap-dao) . Voting power ty…timelock (/wiki/daos/concepts/voting/proposal-lifecycle) between a…ifecycle (/wiki/daos/concepts/voting/proposal-lifecycle) runs off-…k attack (/wiki/daos/concepts/analysis/dao-security-and-governance-at…ata exit (/wiki/daos/concepts/membership/rage-quit-and-exit-rights) be…1/08/16/voting3.html) (2021).

Topic Where a DAO's votes are … Proposal lifecycle (/wiki/daos/concepts/proposal-lifecycle) …ken-weighted voting (/wiki/daos/concepts/token-weighted-voting) , Snapshot (/wiki/daos/tooling/snapshot) , Tally (/wiki/daos/tooling/tally)

Every DAO decision has to answ… always a multisig (/wiki/daos/tooling/safe) of trusted sig…nce trades away for cheapness. The Decentraland DAO (/wiki/daos/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…ecosystem directory (/wiki/dao/ecosystems/uniswap-dao) . Voting power t…mandatory timelock (/wiki/daos/concepts/proposal-lifecycle) … proposal lifecycle (/wiki/daos/concepts/proposal-lifecycle) …e Beanstalk attack (/wiki/daos/concepts/dao-security-and-gov…heir pro-rata exit (/wiki/daos/concepts/rage-quit-and-exit-r…1/08/16/voting3.html) (2021).

Topic Where a DAO's votes are cast and enforced Off-chain Gasless signed messages, stored on IPFS — a signal (Snapshot) On-chain Votes + execution in a contract — binding and trustless (Governor) Common pattern Off-chain temp check → on-chain formal vote → timelocked execution Bridges SafeSnap / oSnap — post an off-chain result on-chain, executable unless challenged On Caper One binding on-chain flow — the contract is both ballot box and executor Related Proposal lifecycle (/wiki/dao/concepts/proposal-lifecycle) , Token-weighted voting (/wiki/dao/concepts/token-weighted-voting) , Snapshot (/wiki/dao/tooling/snapshot) , Tally (/wiki/dao/tooling/tally)

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 (https://docs.tally.xyz/user-guides/governance-concepts/onchain-vs-offchain-voting/) . 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 (https://ipfs.tech/) so it is tamper-evident and publicly auditable without ever touching gas. The dominant platform, Snapshot (https://docs.snapshot.box/) , 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 (/wiki/dao/tooling/safe) 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. 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 (https://docs.openzeppelin.com/contracts/5.x/governance) , the pattern behind Compound's Governor Bravo and most of the DAOs listed in this wiki's ecosystem directory (/wiki/dao/ecosystem/uniswap-dao) . Voting power typically comes from an ERC20Votes (https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#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 (/wiki/dao/concepts/proposal-lifecycle) between a vote passing and taking effect is the window in which members who disagree can exit before the change lands. 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 (/wiki/dao/concepts/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 (https://a16zcrypto.com/posts/article/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. Tools like SafeSnap and its successor oSnap — built on Safe modules (https://docs.safe.global/advanced/smart-account-modules) and the Zodiac Reality module (https://github.com/gnosis/zodiac-module-reality) — let 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. 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 (/wiki/dao/concepts/dao-security-and-governance-attacks) 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 (/wiki/foundations/what-is-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 (/wiki/governance/proposals) are submitted, voted on with ranked choice, and — for the winning option — executed by the contract itself on Radix (https://www.radixdlt.com/) after the voting window and a short execution delay. A passed PAYOUT or INVEST (/wiki/governance/execution) 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 pro-rata exit (/wiki/dao/concepts/rage-quit-and-exit-rights) 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 also has a native answer to the one thing on-chain systems usually push off-chain: casting a DAO's collective voice inside another organization's decision. Its VOTE proposal (/wiki/governance/proposals) kind lets one caper vote, on-chain and by its members' ranked choice, in another caper's proposal — org-to-org delegation without a signalling detour. As always the specifics live on the linked governance (/wiki/governance/voting) pages; this article is the map of the territory they sit in. References - Tally, On-chain vs off-chain voting (https://docs.tally.xyz/user-guides/governance-concepts/onchain-vs-offchain-voting/) . - Snapshot, Documentation (https://docs.snapshot.box/) — gasless, IPFS-stored signed-message voting; and Snapshot X (https://github.com/snapshot-labs/sx-monorepo) , the on-chain successor protocol. - OpenZeppelin, Governor (https://docs.openzeppelin.com/contracts/5.x/governance) and ERC20Votes (https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20Votes) — the reference on-chain governance stack. - Safe, Smart account modules (https://docs.safe.global/advanced/smart-account-modules) ; Gnosis Guild, Zodiac Reality module (https://github.com/gnosis/zodiac-module-reality) — the SafeSnap / oSnap optimistic-execution bridge. - a16z crypto, Governance FAQ (https://a16zcrypto.com/posts/article/governance-faq/) . - Vitalik Buterin, Moving beyond coin voting governance (https://vitalik.eth.limo/general/2021/08/16/voting3.html) (2021).