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 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 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.
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:
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.
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.
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). 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 and votes with locked coins included.
Vitalik Buterin's Notes on Blockchain Governance, 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.
There is no universally right answer; the choice tracks what a DAO is deciding.
A caper puts both layers on-chain. There is no off-chain signalling layer and no multisig executor between the vote and the outcome: proposals are created, ranked and tallied in the caper's own contract on Radix, and 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 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 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 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.