History – Optimistic governance (veto-based approval)

Back
v1.3.4 · currentVote-weight formula replaced with outcome-only wording (VOICE.md §4 Caper overlay)–
1 block modified
  • Modified – Text at Block 10

    How Caper approaches this Opt…ho has cast a ranked ballot a priced way out that is standing rather than scoped to one proposal: calling exiting redeems athat member's fair share of the treasury equal to that member's canonical vote, set by the same earned weight – their token holdings multiplied by the soulbound vote tokens their own ballots minted, (t·v)/(V·T) – whileat governs their votes, and burnings the soulbound proof-of-vote tokens the share is computed fromir ballots earned. So where optimistic governa…Right (/blog/the-exit-right) .

v1.3.3Split paragraphs over 150 words at sentence boundaries; wording unchanged.–
3 blocks modified
  • Modified – Text at Block 5

    Optimistic execution: the orac…ry treasury still carrying it.The kill switch sits one layer… back to trusting its signers.

  • Modified – Text at Block 6

    Two questions that separate op…above half of that same total.No contract knew any of it, so…osnap-proposal-verification) .The challenge was terminal, an…ne that can void the question.

  • Modified – Text at Block 10

    How Caper approaches this Opt…oundations/leaving-a-caper) ).Those tokens are earned on one…Right (/blog/the-exit-right) .

v1.3.2Open with a definition: the first sentence now says what the subject is before it says what it does.–
1 block modified
  • Modified – Text at Block 2

    Optimistic governance is a DAO voting design that flips the default of a DAO vote. In ordinary token-weigh…liably show up to click "yes".

v1.3.1Link the new nexus-mutual page (awesome-DAOs list directory batch, 2 Oct 2026)–
1 block modified
  • Modified – Text at Block 9

    Trade-offs and criticisms The…cause nobody objected in time. Nexus Mutual (/wiki/daos/infrastructure/nexus-mutual) runs both layers through one body: its Advisory Board sets the default outcome members may reject on Snapshot and then, sitting as the council of the mutual's Panama foundation, enacts the result on-chain. Both DAO-LLC statutes rank th…ership/dao-legal-structures) .

v1.3.0Add Aragon's 2023 optimistic dual governance design and Taiko's DAO–
3 blocks modified
  • Modified – Text at Block 1 → Block 1

    Topic Governance in which prop…rnance-101-explainer/) (2025); Taiko DAO (https://blog.aragon.org/introducing-taikos-optimistic-onchain-governance/) (2025)

  • Modified – Text at Block 4

    How a veto window works An op…thing or never ships anything. Aragon's November 2023 design note for the plugin, which it called optimistic dual governance, pairs it with an allowlist: multisigs or subDAOs on the list may propose, and the main DAO's token holders may veto during the timelock. It credits designs explored by Lido, StakedFLIP and Zora ( Aragon (https://blog.aragon.org/optimistic-dual-governance-a-new-governance-design-leveraging-aragon-osx-plugins/) ).

  • Modified – Text at Block 8

    In production Beyond Aragon's…ury/standing-authorizations) . Taiko's DAO, built with Aragon and launched in January 2025, puts a security council in the proposer's seat: three of the council's eight members approve a proposal, token holders and delegates may veto it during a review period, and a proposal that is not vetoed executes after a seven-day timelock ( Aragon (https://blog.aragon.org/introducing-taikos-optimistic-onchain-governance/) ; Taiko Labs (https://paragraph.com/@taiko-labs/introducing-the-taiko-dao) ). Its emergency path needs six of eight and skips the veto; see security councils (/wiki/dao-governance/concepts/fundamentals/security-councils) .

v1.2.6Sweep #439: Reality.eth contracts docs moved off reality.eth.limo/app/docs (404) to realitio.github.io–
1 block modified
  • Modified – Text at Block 6

    Two questions that separate op…. Reality.eth (https://reality.eth.limo/appio.github.io/docs/html/contracts.html) re…ne that can void the question.

v1.2.5Sweep #412 (dao-governance/concepts): corrected for the 11 September 2026 redeploy – v is minted only by a ranked ballot (trade-side mint removed), the settlement-gas subsidy is gone so each crank pays its own fee, exit takes amounts withdrawn from the member's account, and the first ballot's snapshot counts its own mint. Verified at contracts/logic/src/lib.rs (VOTE_MINT, vote, exit, SINGLE_PASS_MAX_VOTERS, EXECUTION_WINDOW_SECONDS; source last moved bd5892a) and the live CaperMain component_tdx_2_1cq64v5tw…jjflhcr. 4 span(s) on this page.–
1 block modified
  • Modified – Text at Block 10

    How Caper approaches this Opt…aper gives any holder who has traded or votedcast a ranked ballot a priced way out that is stan…ulbound vote tokens their own trading and votingballots minted, (t·v)/(V·T) – while b…an encouraged: exit asserts a non-emptypositive amount of vote-token buckets alongside the governance tokens, so a holder who has earned no vote tokens at both withdrawn from the member's own account, so a holder who has never cast a ballot is not paid zero – the call a…dations/leaving-a-caper) ). That bucket isose tokens are earned on eitherone surface: 1 vote token per ranked ballot cast, and 0.01 per XRD of gross value on aminted in the same transaction as the ballot. A buy or a sell, each minted in the same transaction as the act that earned ithem too until the redeploy of 11 September 2026 removed the trade-side mint. Nothing is escrowed and not…e-locked, so a member who has boughtvoted once already satisfies the condition, and a member who has only bought does not – though they can always sell back to the curve. The exit disciplines the mem…Right (/blog/the-exit-right) .

v1.2.4The exit slice is weighted, not proportional (sweep #390)–
1 block modified
  • Modified – Text at Block 10

    How Caper approaches this Opt… goes against you, leave with your proportional slice of what the treasury holdsthe share of the treasury that weight has earned you." There is no coordination th…Right (/blog/the-exit-right) .

v1.2.3Correct the exit precondition: v is minted the moment a member trades or votes, with no release step (contracts/logic/src/lib.rs exit(), vote(), buy/sell v accrual)–
1 block modified
  • Modified – Text at Block 10

    How Caper approaches this Opt…n holdings multiplied by the share of votes they actually castoulbound vote tokens their own trading and voting minted, (t·v)/(V·T) – while burning …Right (/blog/the-exit-right) .

v1.0.0Sweep #337: state the vote-token mint on all three surfaces (exit-condition); settled against contracts/logic/src/lib.rs at d0b26a1–
1 block modified
  • Modified – Text at Block 10

    How Caper approaches this Opt…aper gives any holder who has traded or voted a priced way out that is…Right (/blog/the-exit-right) .

v1.2.2Sweep #333: v is minted by trading as well as by voting (0.01/XRD gross on each leg, 1 per ranked ballot, all at the moment of the act) — corrected every clause making a ballot the sole source of weight–
1 block modified
  • Modified – Text at Block 10

    How Caper approaches this Opt…nance tokens, so a holder who never votedhas earned no vote tokens at all is not paid zero – the call a…dations/leaving-a-caper) ). The condition also has a clock: a caper mints those vote tokens at ballot release rather than at cast, and release cannot begin until casting closes, so a vote still awaiting its count buys no exit and the staked tokens behind it stay locked until it is releasedat bucket is earned on either surface: 1 vote token per ranked ballot cast, and 0.01 per XRD of gross value on a buy or a sell, each minted in the same transaction as the act that earned it. Nothing is escrowed and nothing is time-locked, so a member who has bought once already satisfies the condition. The exit disciplines the mem…Right (/blog/the-exit-right) .

v1.2.1Ballot-era exit precondition: the exit spends vote tokens minted at ballot release, not at cast, so a ballot awaiting its count confers no exit and locks the stake behind it. Verified against contracts/logic/src/lib.rs exit() and contracts/ballot/src/lib.rs unstake_inner/take_release_batch. Em dashes normalised to en dashes on the same pass (VOICE.md §7).–
9 blocks modified
  • Modified – Text at Block 1 → Block 1

    Topic Governance in which prop…ule Silence counts as consent —– a queued proposal executes au…rnance-101-explainer/) (2025)

  • Modified – Text at Block 3

    Why flip the default Affirmat…on) thins, routine proposals —– a grant, a parameter tweak, a contractor renewal —– start failing not because any…le by anyone who would object.

  • Modified – Text at Block 4

    How a veto window works An op…permission submits the action —– that permission might sit wit…w long the window stays open) —– set them wrong and the mechan…thing or never ships anything.

  • Modified – Text at Block 5

    Optimistic execution: the orac…ling/treasury/safe) treasury —– a deliberate pause so that a …governance-attacks) to watch —– the security of the outcome i…) in favour of ASSERT_TRUTH2 —– identical specifications, UMA… back to trusting its signers.

  • Modified – Text at Block 6

    Two questions that separate op…t parameters on-chain instead —– OptimisticGovernanceSettings…ide the ordinary answer space —– 0xff…ff for invalid and 0xff…fe for answered too soon —– so a bonded challenger can ar…ne that can void the question.

  • Modified – Text at Block 7

    Milestone escrow: optimistic s… assertable, disputable claim —– so members are asked to act o…thDefaults now always reverts.

  • Modified – Text at Block 8

    In production Beyond Aragon's…, the timelock starts to grow —– from five extra days at 1% up…o a maximum of 45 days at 10% —– buying time for the DAO to re…DAOs usually treat separately —– a graduated veto and a rage-… be bound by it. That pairing —– object, and if objection is not enough, exit —– is the sharpest version of wh…ury/standing-authorizations) .

  • Modified – Text at Block 9

    Trade-offs and criticisms The…O by vetoing routine business —– a mirror of the capture and … so the honesty of that party —– a council, a core team, a multisig —– becomes load-bearing. That is…rapper's controls are ex ante —– signer sets, thresholds, a du… to refuse unlawful execution —– while an optimistic default t…ership/dao-legal-structures) .

  • Modified – Text at Block 10

    How Caper approaches this Opt…ho has voted a priced way out that any momentis standing rather than scoped to one proposal: calling exit redeems a share…ember's canonical vote weight —– their token holdings multipli…ey actually cast, (t·v)/(V·T) —– while burning the soulbound p…oundations/leaving-a-caper) ). The condition also has a clock: a caper mints those vote tokens at ballot release rather than at cast, and release cannot begin until casting closes, so a vote still awaiting its count buys no exit and the staked tokens behind it stay locked until it is released. The exit disciplines the memb…s a different bet than a veto —– that a credible, always-availablestanding exit disciplines a treasury m…Right (/blog/the-exit-right) .

v1.2.0Accuracy (contract): correct the 'any holder, always open' exit claim - exit() asserts a non-empty vote-token bucket, so a holder who never voted has no exit at all rather than a zero-value one. Second carrier of the class #235 found on holographic-consensus.–
1 block modified
  • Modified – Text at Block 10

    How Caper approaches this Opt… every caper gives any holder who has voted a priced way out at any moment…age-quit-and-exit-rights) is always openstanding rather than scoped to a proposal, and its price is set by the …rve) the caper was funded on. The one condition is participation, and it is enforced rather than encouraged: exit asserts a non-empty vote-token bucket alongside the governance tokens, so a holder who never voted is not paid zero – the call aborts ( leaving a caper (/wiki/foundations/leaving-a-caper) ). The exit disciplines the members who showed up, which is a narrower claim than a veto's and a stronger one for them. It is a different bet than a …Right (/blog/the-exit-right) .

v1.0.0Deepen: where the rules-validity check lives (oSnap rules string vs Aragon's on-chain OptimisticGovernanceSettings), the dispute outcome set (Reality.eth invalid/too-soon; oSnap's terminal dispute), and milestone escrow via UMA OOv3. Record UMA's 15 Dec 2025 oSnap retirement and the ASSERT_TRUTH deprecation behind it. Fix a /wiki/blog link that 404s.–
2 blocks added, 2 blocks modified, 3 blocks reordered
  • Modified – Text at Block 5

    Optimistic execution: the orac…he incentive to dispute a lie. The other implementation of this route no longer exists. UMA's oSnap – the Optimistic Governor module paired with a Snapshot front end, and the bridge most DAO documentation still points at – was retired on 15 December 2025. UMA's notice is unambiguous: after that date "oSnap will not be able to execute transactions from your DAO's Safe treasury" (https://docs.uma.xyz/resources/osnap) , and integrators were told to disable the module on every treasury still carrying it. The kill switch sits one layer below the module, in the oracle: the ASSERT_TRUTH identifier every oSnap assertion resolved against was deprecated in the same week (https://docs.uma.xyz/developers/optimistic-oracle-v3/assert_truth-deprecation) in favour of ASSERT_TRUTH2 — identical specifications, UMA says, the change existing only "to break support for deprecated projects". The Reality.eth route described above is unaffected and Snapshot still documents it (https://docs.snapshot.box/v1-interface/plugins/safesnap-reality) . A DAO whose constitution names oSnap as its execution path has, since that date, been back to trusting its signers.

  • Moved – Text at Block 8
  • Moved – Text at Block 9
  • Moved – Text at Block 10
  • Modified – Text at Block 10

    How Caper approaches this Opt… full is in The Exit Right (/wiki/blog/the-exit-right) .

  • Added – Text at Block 6

    Two questions that separate optimistic systems Every optimistic design has the same silhouette – default pass, bonded objection, challenge window – and two differences decide how much protection the window actually buys. Neither is the veto threshold, which is where comparisons usually start and stop. Where the validity check lives. oSnap kept a space's rules as a plain text string in the Safe module's settings. A disputer was shown "the oSnap rules that the request should be reviewed against (including minimum quorum and voting period for the Snapshot proposal)" (https://docs.uma.xyz/resources/osnap/osnap-proposal-verification) and had to judge, by reading, whether the proposal met them: quorum counted FOR + AGAINST + ABSTAIN against the space's floor, and passage required a FOR share above half of that same total. No contract knew any of it, so the check was re-made from scratch on every request by whoever happened to be watching. Aragon's plugin pins the equivalent parameters on-chain instead — OptimisticGovernanceSettings (https://github.com/aragon/optimistic-token-voting-plugin/blob/main/src/OptimisticTokenVotingPlugin.sol) holds minVetoRatio, minDuration and minProposerVotingPower, and canExecute resolves the routine case by calling isMinVetoRatioReached. A rules string is far more expressive; it can encode conditions no contract could check. That expressiveness is exactly what has to be re-litigated, unpaid, every single time. What the dispute layer is allowed to say. The narrow version of a challenge is "the tally is wrong". Wider outcome sets are a materially different power. Reality.eth (https://reality.eth.limo/app/docs/html/contracts.html) reserves two answers outside the ordinary answer space — 0xff…ff for invalid and 0xff…fe for answered too soon — so a bonded challenger can argue not that the answer is wrong but that the question should never settle at all, or not yet. oSnap pushed the same idea to its limit in the other direction: a disputed request "can not be executed no matter how UMA resolves the dispute" (https://docs.uma.xyz/resources/osnap/osnap-proposal-verification) . The challenge was terminal, and a DAO that won its dispute still had to propose again from the start. That gap matters more than the threshold in front of it: a low bar guarding a layer that can only correct arithmetic is weaker protection than a high bar guarding one that can void the question.

  • Added – Text at Block 7

    Milestone escrow: optimistic settlement for proposals that have deliveries A veto window fits a decision that happens once. Much of what a treasury funds does not. A grant is approved as a lump and then paid against work arriving over months, and the DAO has no natural place to object to the third tranche short of re-running governance. UMA's Insurance (https://docs.uma.xyz/developers/optimistic-oracle-v3/in-depth-tutorial-insurance) reference contract, written as an Optimistic Oracle V3 tutorial rather than a governance tool, is the shape that fits. Funds are locked at issuance against a described event and a named beneficiary. Anyone may request payout at any time; the request posts a bonded assertion that the event has occurred, and if that assertion survives its window the contract pays the beneficiary automatically (https://github.com/UMAprotocol/dev-quickstart-oov3/blob/master/src/Insurance.sol) . A rejected request does not close the policy: it stays live, there is no cap on attempts, and only the first truthfully resolved request settles the money. Substitute "milestone delivered" for "insured event" and that is tranche release. The DAO votes once on the grant, the funds sit in escrow, and each release becomes its own assertable, disputable claim — so members are asked to act only when they believe a milestone was not met. It is the same economy of attention the veto window is reaching for, applied to the part of a treasury's work that has deliveries rather than a single moment of consent. The non-optimistic version of the same problem is standing authorizations and delegated mandates (/wiki/dao-governance/concepts/treasury/standing-authorizations) ; where escrowed grants sit in the wider picture is treasury management (/wiki/dao-governance/concepts/treasury/dao-treasury-management) . One trap for anyone building from that tutorial: its constructor reads oo.defaultIdentifier(), which still returns the deprecated ASSERT_TRUTH, and assertTruthWithDefaults now always reverts.

v1.1.0Add Easy Track as the second Lido optimistic mechanism (committee mandates rather than holder veto), with the 72h / 0.5% / permissionless-enactment parameters and an inbound link to the new standing-authorizations cornerstone.–
1 block modified
  • Modified – Text at Block 6

    In production Beyond Aragon's…ic governance is reaching for. Lido runs a second, quieter optimistic mechanism in the opposite direction. Where Dual Governance gives holders a veto over the DAO, Easy Track (https://docs.lido.fi/guides/easy-track-guide/) gives named committees a right to act without the DAO: a motion enacts after 72 hours unless holders of 0.5% of LDO object, and enactMotion carries no role gate, so anyone may execute a passed motion. The veto window is the same shape; what is being waved through is a class of recurring spending rather than one decision. See standing authorizations and delegated mandates (/wiki/dao-governance/concepts/treasury/standing-authorizations) .

v1.0.1Sweep #213: add the legal-wrapper tension to Trade-offs, with an inbound link to the new 'when the wrapper and the code disagree' section on dao-legal-structures.–
2 blocks modified
  • Modified – Text at Block 6

    In production Beyond Aragon's… example is Lido (/wiki/daos/organizations/staking/lido-dao) 's Dual Gov…ic governance is reaching for.

  • Modified – Text at Block 7

    Trade-offs and criticisms The…rubber stamp with extra steps. A third tension only shows up once a DAO has a legal wrapper (/wiki/dao-governance/concepts/membership/dao-legal-structures) . A wrapper's controls are ex ante — signer sets, thresholds, a duty to refuse unlawful execution — while an optimistic default treats a proposal as authorised because nobody objected in time. Both DAO-LLC statutes rank the smart contract above the paperwork it conflicts with, so the two layers can reach different answers about whether a treasury outflow was ever authorised at all; the drafting responses are set out under when the wrapper and the code disagree (/wiki/dao-governance/concepts/membership/dao-legal-structures) .

v1.0.0Fix dead link: Snapshot SafeSnap:Reality docs moved /user-guides/ -> /v1-interface/ (404 -> 200)–
7 blocks modified
  • Modified – Text at Block 1 → Block 1

    Topic Governance in which prop…ken-weighted voting (/wiki/daos-governance/concepts/voting/token-weighte…rnance-101-explainer/) (2025)

  • Modified – Text at Block 2

    Optimistic governance flips th…ken-weighted voting (/wiki/daos-governance/concepts/voting/token-weighte…liably show up to click "yes".

  • Modified – Text at Block 3

    Why flip the default Affirmat…out and delegation (/wiki/daos-governance/concepts/voting/voting-and-de…on ways DAOs stall (/wiki/daos-governance/concepts/analysis/how-daos-fa…le by anyone who would object.

  • Modified – Text at Block 5

    Optimistic execution: the orac…-chain on Snapshot (/wiki/daos-governance/tooling/voting/snapshot) whi…ap (https://docs.snapshot.box/user-guidesv1-interface/plugins/safesnap-reality) ) p… an off-chain vote (/wiki/daos-governance/concepts/fundamentals/on-chai…e against the Safe (/wiki/daos-governance/tooling/treasury/safe) treas…the attack surface (/wiki/daos-governance/concepts/analysis/dao-securit…he incentive to dispute a lie.

  • Modified – Text at Block 6

    In production Beyond Aragon's…d a rage-quit exit (/wiki/daos-governance/concepts/membership/rage-quit…ic governance is reaching for.

  • Modified – Text at Block 7

    Trade-offs and criticisms The…apture and gridlock (/wiki/daos-governance/concepts/analysis/how-daos-fa…rubber stamp with extra steps.

  • Modified – Text at Block 8

    How Caper approaches this Opt…ss; the exit right (/wiki/daos-governance/concepts/membership/rage-quit… (/wiki/blog/the-exit-right) .

v1.0.0Create cornerstone concept pillar: optimistic / veto-based governance (Aragon Optimistic Token Voting, Zodiac Reality Module/SafeSnap, Lido Dual Governance) + contract-verified How-Caper exit-right note–
8 blocks added
  • Added – Text at Block 1 → Block 1

    Topic Governance in which proposals pass by default and can only be stopped by an explicit veto Core rule Silence counts as consent — a queued proposal executes automatically after a timelock unless enough tokens veto it inside the window Also called Veto-based governance, optimistic approval, negative-consent voting Solves Chronic voter fatigue and quorum failure in affirmative token-weighted voting (/wiki/daos/concepts/voting/token-weighted-voting) Key risk A veto threshold set too high for real dissent to reach, or over-centralised proposer permission In production Aragon Optimistic Token Voting plugin (https://github.com/aragon/optimistic-token-voting-plugin) ; Zodiac Reality Module (SafeSnap) (https://github.com/gnosisguild/zodiac-module-reality) ; Lido Dual Governance (https://blog.lido.fi/dual-governance-101-explainer/) (2025)

  • Added – Text at Block 2

    Optimistic governance flips the default of a DAO vote. In ordinary token-weighted voting (/wiki/daos/concepts/voting/token-weighted-voting) a proposal starts life rejected and must gather affirmative support to pass; in optimistic governance a proposal starts life approved and executes on its own after a waiting period unless a threshold of token holders actively vetoes it first. The design borrows its name and its logic from optimistic rollups: assume the action is fine, and only require work from the people who think it is not. It is aimed squarely at the failure mode where a small, engaged proposer set is slowed to a halt by a large, disengaged electorate that will never reliably show up to click "yes".

  • Added – Text at Block 3

    Why flip the default Affirmative voting quietly assumes that a DAO can summon a quorum on demand. Most cannot. As token holders spread out and delegation (/wiki/daos/concepts/voting/voting-and-delegation) thins, routine proposals — a grant, a parameter tweak, a contractor renewal — start failing not because anyone opposes them but because not enough wallets vote at all. Chronic low turnout and missed quorum are among the most common ways DAOs stall (/wiki/daos/concepts/analysis/how-daos-fail) , and every unnecessary vote spends attention the DAO needs for the decisions that actually matter. Optimistic governance treats participation as scarce and spends it only on disagreement. Uncontested business clears itself; the electorate is asked to act solely when it wants to stop something. In exchange for that efficiency the DAO accepts a real trade: an action nobody bothered to examine can still go live, so the safety of the whole scheme rests on the veto being genuinely reachable by anyone who would object.

  • Added – Text at Block 4

    How a veto window works An optimistic proposal moves through three stages. First, an address holding a specific proposer permission submits the action — that permission might sit with a council multisig, another governance plugin, or a plain wallet. Second, the proposal enters a timelock: a fixed window during which token holders can register a veto by locking or committing tokens against it. Third, if vetoes stay below the configured threshold when the window closes, the execution (/wiki/governance/execution) becomes callable by anyone; if the threshold is crossed, the proposal is blocked. Aragon's Optimistic Token Voting (https://docs.aragon.org/token-voting/1.x) plugin is a clean reference implementation: only holders of PROPOSER_PERMISSION_ID may create proposals, and a proposal executes once its veto window has elapsed without a set fraction of the token supply objecting. The two dials that define the regime are the veto ratio (how much of the supply must object to kill a proposal) and the minimum duration (how long the window stays open) — set them wrong and the mechanism either rubber-stamps everything or never ships anything.

  • Added – Text at Block 5

    Optimistic execution: the oracle route A closely related pattern lets a DAO keep voting off-chain on Snapshot (/wiki/daos/tooling/voting/snapshot) while still executing trustlessly on-chain. The Zodiac Reality Module (https://github.com/gnosisguild/zodiac-module-reality) (marketed to Snapshot users as SafeSnap (https://docs.snapshot.box/user-guides/plugins/safesnap-reality) ) posts the outcome of an off-chain vote (/wiki/daos/concepts/fundamentals/on-chain-vs-off-chain-governance) as a question to the Reality.eth (https://reality.eth.limo/) escalation oracle. Anyone can assert that the linked proposal passed, backing the claim with a bond; the assertion is assumed correct unless it is challenged and escalated within the answer window. Once the answer is final, a further 24-hour cooldown elapses before the transaction batch becomes executable by anyone against the Safe (/wiki/daos/tooling/treasury/safe) treasury — a deliberate pause so that a wrong answer which slipped through can still be caught before it moves funds. It is optimistic in exactly the same sense: no on-chain vote tally is trusted directly, only a bonded claim that survived a challenge period. The same escrow-and-challenge shape underpins the attack surface (/wiki/daos/concepts/analysis/dao-security-and-governance-attacks) to watch — the security of the outcome is only as good as the incentive to dispute a lie.

  • Added – Text at Block 6

    In production Beyond Aragon's plugin, the most consequential live example is Lido (/wiki/daos/organizations/staking/lido-dao) 's Dual Governance (https://blog.lido.fi/dual-governance-101-explainer/) , enabled in 2025. It inserts a dynamic timelock between the LDO-holder DAO's decisions and their execution, and hands stETH holders a veto they exercise by locking stETH into an escrow. Once locked stake crosses a first seal at 1% of Lido-on-Ethereum TVL, the timelock starts to grow — from five extra days at 1% up to a maximum of 45 days at 10% — buying time for the DAO to reconsider. Crossing a second seal at 10% of TVL triggers rage quit: execution is fully blocked until every objecting holder has withdrawn. Lido is worth studying because it fuses the two escape valves DAOs usually treat separately — a graduated veto and a rage-quit exit (/wiki/daos/concepts/membership/rage-quit-and-exit-rights) . Dissenters do not merely delay a decision; if they are numerous enough they can leave rather than be bound by it. That pairing — object, and if objection is not enough, exit — is the sharpest version of what optimistic governance is reaching for.

  • Added – Text at Block 7

    Trade-offs and criticisms The central objection is that silence is not consent. Optimistic governance reads a non-response as approval, but a non-response can equally mean a holder never saw the proposal, could not decode its calldata, or lacked the tokens to matter. If the veto threshold is set higher than a diffuse, part-time electorate can realistically coordinate to reach, the safety valve is decorative and the proposer set governs unchecked. Set it too low and a small, motivated minority can grief the DAO by vetoing routine business — a mirror of the capture and gridlock (/wiki/daos/concepts/analysis/how-daos-fail) the design was meant to escape. The other tension is who holds proposer permission. Optimistic schemes trade broad affirmative participation for a trusted party that drafts and queues actions, so the honesty of that party — a council, a core team, a multisig — becomes load-bearing. That is a reasonable bargain for an established protocol with a credible team and an engaged token base able to veto, and a poor one for a young, thinly-distributed DAO where the "veto" nobody can reach is just a rubber stamp with extra steps.

  • Added – Text at Block 8

    How Caper approaches this Optimistic governance answers "a decision I object to is about to pass" with a collective veto window, and Lido shows the strongest form of it pairs that veto with an exit. A caper (/wiki/foundations/what-is-a-caper) leans entirely on the exit side and makes it individual rather than collective. Instead of asking dissenters to coordinate enough tokens to clear a veto threshold in time, every caper gives any holder a priced way out at any moment: calling exit redeems a share of the treasury equal to that member's canonical vote weight — their token holdings multiplied by the share of votes they actually cast, (t·v)/(V·T) — while burning the soulbound proof-of-vote tokens the share is computed from. So where optimistic governance says "you are bound unless enough of you together veto in time," a caper says "if a decision goes against you, leave with your proportional slice of what the treasury holds." There is no coordination threshold to reach and no window to miss; the exit right (/wiki/daos/concepts/membership/rage-quit-and-exit-rights) is always open, and its price is set by the bonding curve (/wiki/markets/bonding-curve) the caper was funded on. It is a different bet than a veto — that a credible, always-available exit disciplines a treasury more reliably than a veto most holders can never quite muster. The argument in full is in The Exit Right (/wiki/blog/the-exit-right) .