Tool OpenZeppelin Governor —– the modular, on-chain governa…ry Governance execution layer —– the smart contract that turns…ntracts/5.x/api/governance) ) —– snapshot balances + delegatio…ontracts/5.x/api/governance) —– a passed proposal is queued, …/tooling/dao-tooling-overview)

OpenZeppelin Governor is the s…run their governance on-chain —– where the vote and its execut…ontracts/governance) library.

From Compound Bravo to a reusa…eplaced it with GovernorBravo —– which put the governance logi…ound.finance/v2/governance/) —– roughly a week from proposal to execution.

A contract assembled from modu…nance) ): - GovernorSettings —– the tunable knobs: votingDela… to submit). - GovernorVotes —– hooks the Governor to an IVo…- GovernorVotesQuorumFraction —– defines quorum as a percentag…es. - GovernorCountingSimple —– the tally rule: three options… . - GovernorTimelockControl —– routes execution through a T… opens grants no extra weight —– a core defence discussed unde…oting/voting-and-delegation) .

The proposal lifecycle Every …l walks a fixed state machine —– the eight states (https://do…ct calldata that was voted on.

Strengths and known failure mo…rity-and-governance-attacks) —– low turnout letting a small q…epts/analysis/how-daos-fail) .

How Caper approaches this Ca…s from Governor's core stance —– what a vote authorises is car… not at a signer's discretion —– and narrows the execution sur…aper's own token metadata, or —– on the $CAPER caper alone —– an upgrade of the shared logi…aseline locked at the trigger —– so selling is a veto with a p…still has to survive a market.

How Caper approaches this Ca… can stop the action outright.A passing ballot only earns th…still has to survive a market.

Tool OpenZeppelin Governor — t…tes after a delay Front-ends Snapshot (/wiki/dao-governance/tooling/voting/snapshot) (since March 2026 (https://blog.snapshot.box/snapshot-is-now-home-for-governor-daos) ) · Cactus, formerly Tally (/wiki/dao-governance/t…/tooling/dao-tooling-overview)

Who runs on it Governor and i…tandardised on it: governance dashboarfront-ends like Tally (/wiki/dao-governance/tooling/voting/tally) and, Agora (/wiki/dao-governance/tooling/voting/agora) and, since March 2026, Snapshot (/wiki/dao-governance/tooling/voting/snapshot) can index any Governor by re…o bespoke integration per DAO.

How Caper approaches this Ca… only earns the right to open a 48-hourthe market window, and the winnin… or above the baseline locked when it openedat the trigger — so selling is a veto with a…still has to survive a market.

How Caper approaches this Ca…oundations/what-is-a-caper) shtarests from Governor's core stance — a passed vote executes on-chainwhat a vote authorises is carried out by contract, not at a signer's discretion — butand narrows the execution surface… a divestment back out of one, or a rewrite of the caper's own token metadata, or — on the $CAPER caper alone — an upgrade of the shared logic (ProposalOptionData.kind in c…e with a smaller blast radius. The two models have since parted company on the gap between the vote and the act, and the comparison is worth stating precisely because Caper's side of it moved. Governor's timelock is a fixed delay: it exists so holders can see what is coming and act before it lands, but the delay itself does not change the verdict, and the queued call executes when it expires. Caper's equivalent phase can stop the action outright. A passing ballot only earns the right to open a 48-hour market window, and the winning action executes (/wiki/governance/execution) at the close of that window if the caper's time-weighted price held at or above the baseline locked when it opened — so selling is a veto with a price attached rather than a protest registered elsewhere. One option kind, DEBATE, carries no action at all and is terminal at the tally: a ballot it wins opens no window and executes nothing. Under Governor, a passed vote is a queued transaction; under Caper, a passed vote is a mandate that still has to survive a market.

How Caper approaches this Ca…nvestment into another caper, or a vote it casta divestment back out of one, or a rewrite of the caper's own the DAO's behalfoken metadata (ProposalOptionData.kind in contracts/common/src/lib.rs). Each type runs through its o…e with a smaller blast radius.

OpenZeppelin Governor is the s…on. Where Snapshot (/wiki/daos-governance/tooling/voting/snapshot) rec…ntiment and a Safe (/wiki/daos-governance/tooling/treasury/safe) multi…on-chain governance (/wiki/daos-governance/concepts/fundamentals/on-chai…ontracts/governance) library.

From Compound Bravo to a reusa…mpound. Compound (/wiki/daos/organizations/lending/compound-dao) shipped…ek from proposal to execution.

A contract assembled from modu…s a window to exit (/wiki/daos-governance/concepts/membership/rage-quit…ken-weighted voting (/wiki/daos-governance/concepts/voting/token-weighte…g) and delegation (/wiki/daos-governance/concepts/voting/voting-and-delegation) .

The proposal lifecycle Every … proposal lifecycle (/wiki/daos-governance/concepts/voting/proposal-life…ct calldata that was voted on.

Who runs on it Governor and i…rnance: Compound (/wiki/daos/organizations/lending/compound-dao) , Uniswap (/wiki/daos/organizations/dexs/uniswap-dao) , ENS (/wiki/daos/organizations/infrastructure/ens-dao) , Gitcoin (/wiki/daos/organizations/public-goods/gitcoin-dao) , Nouns (/wiki/daos/organizations/social/nouns-dao) , and the Arbitrum (/wiki/daos/organizations/networks/arbitrum-dao) and Optimism (/wiki/daos/organizations/networks/optimism-collective) …hboards like Tally (/wiki/daos-governance/tooling/voting/tally) and Agora (/wiki/daos-governance/tooling/voting/agora) can in…o bespoke integration per DAO.

Strengths and known failure mo… governance attacks (/wiki/daos-governance/concepts/analysis/dao-securit…nd incentive design (/wiki/daos-governance/concepts/analysis/how-daos-fail) .

How Caper approaches this Ca… on-chain-execution (/wiki/daos-governance/concepts/fundamentals/on-chai…e with a smaller blast radius.

Tool OpenZeppelin Governor — the modular, on-chain governance contract library used by most token-voting DAOs Category Governance execution layer — the smart contract that turns a passed vote into an on-chain action Lineage Compound GovernorAlpha (2020) → GovernorBravo (2021) → OpenZeppelin generalised the pattern into a reusable Governor (https://docs.openzeppelin.com/contracts/5.x/governance) library Voting power Read from an IVotes (https://docs.openzeppelin.com/contracts/5.x/api/governance) token ( ERC20Votes (https://docs.openzeppelin.com/contracts/5.x/api/governance) / ERC721Votes (https://docs.openzeppelin.com/contracts/5.x/api/governance) ) — snapshot balances + delegation, not raw balances Execution Optional TimelockController (https://docs.openzeppelin.com/contracts/5.x/api/governance) — a passed proposal is queued, then executes after a delay Front-ends Tally (/wiki/daos/tooling/voting/tally) · Agora (/wiki/daos/tooling/voting/agora) read Governor state directly from chain Licence MIT (OpenZeppelin Contracts) · source on GitHub (https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance) Related On- vs off-chain governance (/wiki/daos/concepts/fundamentals/on-chain-vs-off-chain-governance) · Proposal lifecycle (/wiki/daos/concepts/voting/proposal-lifecycle) · DAO tooling stack (/wiki/daos/tooling/dao-tooling-overview)

Tool OpenZeppelin Governor — the modular, on-chain governance contract library used by most token-voting DAOs Category Governance execution layer — the smart contract that turns a passed vote into an on-chain action Lineage Compound GovernorAlpha (2020) → GovernorBravo (2021) → OpenZeppelin generalised the pattern into a reusable Governor (https://docs.openzeppelin.com/contracts/5.x/governance) library Voting power Read from an IVotes (https://docs.openzeppelin.com/contracts/5.x/api/governance) token ( ERC20Votes (https://docs.openzeppelin.com/contracts/5.x/api/governance) / ERC721Votes (https://docs.openzeppelin.com/contracts/5.x/api/governance) ) — snapshot balances + delegation, not raw balances Execution Optional TimelockController (https://docs.openzeppelin.com/contracts/5.x/api/governance) — a passed proposal is queued, then executes after a delay Front-ends Tally (/wiki/dao-governance/tooling/voting/tally) · Agora (/wiki/dao-governance/tooling/voting/agora) read Governor state directly from chain Licence MIT (OpenZeppelin Contracts) · source on GitHub (https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance) Library version v5.7.0 (https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v5.7.0) , released 29 July 2026 · governance extensions dated in the CHANGELOG (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CHANGELOG.md) Module count 17 contracts in contracts/governance/extensions (https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance/extensions) – most descriptions of Governor stop at the original five Related On- vs off-chain governance (/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) · Proposal lifecycle (/wiki/dao-governance/concepts/voting/proposal-lifecycle) · DAO tooling stack (/wiki/dao-governance/tooling/dao-tooling-overview)

What the library added after 2023 The five modules above are the set almost every live Governor was assembled from, and the set most descriptions of Governor still stop at. The library did not stop there. The extensions directory (https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance/extensions) now holds seventeen contracts, and the CHANGELOG (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CHANGELOG.md) dates each one: - v4.5.0 (9 February 2022) – GovernorPreventLateQuorum (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorPreventLateQuorum.sol) extends the deadline when a vote reaches quorum (/wiki/dao-governance/concepts/voting/quorum-and-threshold-design) late, so a large holder cannot trip quorum in the closing minutes and end the poll before anyone can answer. v5.7.0 bounded it: _maxLateQuorumVoteExtension defaults to votingPeriod(), capping total voting duration at twice the period, because an unbounded extension could otherwise brick governance. - v5.0.0 (5 October 2023) – GovernorTimelockAccess (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorTimelockAccess.sol) routes execution through an AccessManager instead of a single TimelockController, so the delay is set per restricted function rather than globally for every proposal. - v5.1.0 (17 October 2024) – GovernorCountingFractional (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingFractional.sol) , the subject of the next section. - v5.2.0 (8 January 2025) – GovernorCountingOverridable (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingOverridable.sol) lets a token holder overrule the vote their delegate (/wiki/dao-governance/concepts/voting/voting-and-delegation) already cast, emitting OverrideVoteCast and a matching VoteReduced against the delegate. It requires a token inheriting VotesExtended (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/VotesExtended.sol) , which checkpoints delegations and balances rather than voting units alone – so an existing ERC20Votes token cannot switch it on without changing the token. - v5.3.0 (9 April 2025) – four at once: GovernorSuperQuorum (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorSuperQuorum.sol) and its supply-fraction variant let a proposal that clears a higher bar reach Succeeded before the deadline; GovernorProposalGuardian (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorProposalGuardian.sol) names an address that may cancel any proposal at any stage; and GovernorSequentialProposalId numbers proposals 1, 2, 3 instead of hashing their calldata. - v5.4.0 (17 July 2025) – GovernorNoncesKeyed, keyed nonces for voting by signature. - v5.7.0 (29 July 2026) – GovernorCrosschain (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCrosschain.sol) relays a passed proposal to a remote executor on another chain over an ERC-7786 (https://eips.ethereum.org/EIPS/eip-7786) gateway, which is the first time the library treats the executing chain as a parameter rather than an assumption. The pattern is worth naming. Every one of these changes what a vote means – who may cast it, when counting stops, who may stop it – while leaving the proposal interface untouched. A DAO can therefore alter its own franchise by swapping a counting module, and the change is invisible to any dashboard reading only proposal state.

Fractional voting, and the DAOs that paid for it and never switched it on GovernorCountingFractional (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingFractional.sol) adds a fourth support value alongside For, Against and Abstain: 255, which means "split my weight". A vote cast with it carries a params blob of three packed uint128 values – against, for, abstain – and the module tracks usedVotes per voter, so weight can be spent across several transactions rather than all at once. Cast a plain Bravo vote instead and it consumes the whole remaining balance in one option, exactly as GovernorCountingSimple (https://docs.openzeppelin.com/contracts/5.x/api/governance) does. The point is not that individuals want to hedge. It is that a contract holding tokens on behalf of many people can finally vote the way those people actually split. The library's own header lists the cases: tokens sitting in a DeFi pool, tokens bridged to an L2 and held by the bridge, and shielded voting (/wiki/dao-governance/concepts/voting/private-and-shielded-voting) from a pool using zero-knowledge proofs. Without it, a pooled position votes as one bloc or not at all – which is why so much delegated weight goes uncast. The module is not OpenZeppelin's invention. Its source header credits ScopeLift's Flexible Voting (https://github.com/ScopeLift/flexible-voting) , built under a Uniswap Grants Program grant and introduced to the Uniswap DAO in July 2022 (https://gov.uniswap.org/t/temperature-check-upgrading-to-a-flexible-voting-enabled-governor/17098) . That temperature check drew two replies and went nowhere. In 2024 ScopeLift built it again for Arbitrum (/wiki/daos/networks/arbitrum-dao) , as L2ArbitrumGovernorV2 with a GovernorCountingFractionalUpgradeable, and OpenZeppelin reviewed it between 8 and 19 July 2024 (https://forum.arbitrum.foundation/t/arbitrum-governor-v2-review/26118) – nine issues, eight resolved. The on-chain proposal to deploy it did not pass. The objection Offchain Labs raised in the follow-up thread (https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531) is the sharpest available argument about adopting a counting module piecemeal: Arbitrum One runs five governors, the upgrade covered two, and the three Security Council (/wiki/dao-governance/concepts/fundamentals/security-councils) governors would have been left behind – so voters using fractional clients would not take part in council elections by default, "giving non-flexible votes an exaggerated effect ... and affecting quorums". The work was then split, and the half that kept moving was proposal cancellation, not fractional voting. By February 2026 the cancellation upgrade had been audited and bundled onto a constitutional AIP, while a delegate noted in the same thread that Flexible Voting "is still pending to be delivered" – from a temperature check approved in March 2024. So the mechanism outlived both proposals that commissioned it. It is in the standard library, MIT-licensed, available to any DAO deploying a new Governor today; the two DAOs that paid to have it built still do not run it. That gap between what the tooling can do and what deployed governance does is the recurring shape of DAO tooling discontinuity (/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity) .

Where the modules pull against each other Modules compose mechanically but not always politically, and the library says so in its own comments – which makes these the cheapest governance-design warnings a DAO will ever get. - Early closure defeats the override. GovernorCountingOverridable notes that override votes can only be cast while a proposal is active, so "mechanisms that shorten the voting duration, such as the early closure implemented in GovernorSuperQuorum, may therefore prevent token holders from overriding the votes cast with their tokens by their delegates". A DAO that adopts both has handed holders a check on their delegates and then built the thing that can close the window before they use it. - A low super quorum can decide a vote before the opposition arrives. GovernorSuperQuorum warns that if the bar is set low enough for For votes to clear it early, a proposal "can succeed prematurely before enough AGAINST voters have a chance to vote". The module's safety depends entirely on a parameter, and that parameter is set by the DAO that benefits from setting it low. - The proposal guardian is a discretionary actor by another name. GovernorProposalGuardian lets one address cancel any proposal at any stage of its lifecycle – and if no guardian is configured, the proposer inherits that power over their own proposals (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorProposalGuardian.sol) . Governor's selling point is that no one has discretion over a passed vote; this module reintroduces discretion before the vote finishes, which is a defensible safety valve and a governance decision that deserves to be argued rather than inherited from a default. None of these is a bug. Each is a real trade-off written down where an integrator can read it, which is more than most governance frameworks offer – but a DAO that assembles modules without reading the trade-offs has changed its constitution by import.

References - OpenZeppelin Contracts – CHANGELOG (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CHANGELOG.md) (release dates for every governance extension cited above) and the v5.7.0 release (https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v5.7.0) , 29 July 2026 - contracts/governance/extensions (https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance/extensions) – the seventeen modules, including GovernorCountingFractional.sol (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingFractional.sol) (the 255 support value, the packed uint128 params, usedVotes), GovernorCountingOverridable.sol (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorCountingOverridable.sol) (the early-closure note, OverrideVoteCast, VoteReduced), GovernorSuperQuorum.sol (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorSuperQuorum.sol) (the premature-success warning) and GovernorProposalGuardian.sol (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorProposalGuardian.sol) (_validateCancel and the unconfigured-guardian fallback) - VotesExtended.sol (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/VotesExtended.sol) – the delegation and balance checkpoints the override module requires of the token - ScopeLift – Flexible Voting (https://github.com/ScopeLift/flexible-voting) and flexiblevoting.com (https://flexiblevoting.com) (the UGP grant, the use cases upstreamed into v5.1) - Uniswap governance forum – Temperature Check: Upgrading to a Flexible Voting enabled Governor (https://gov.uniswap.org/t/temperature-check-upgrading-to-a-flexible-voting-enabled-governor/17098) , 14 July 2022 - Arbitrum DAO forum – Arbitrum Governor V2 Review (https://forum.arbitrum.foundation/t/arbitrum-governor-v2-review/26118) (OpenZeppelin's review of ScopeLift's L2ArbitrumGovernorV2, 8–19 July 2024) and Change to New Governance Contracts that Allow Proposal Cancellation (https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531) (the failed vote, the Offchain Labs five-governor objection, the split, and the February 2026 status) - OpenZeppelin docs – Governance (https://docs.openzeppelin.com/contracts/5.x/governance) and the Governance API reference (https://docs.openzeppelin.com/contracts/5.x/api/governance)

Tool OpenZeppelin Governor — t…ds Tally (/wiki/daos/tooling/voting/tally) · Agora (/wiki/daos/tooling/voting/agora) read Governor state di…vernance (/wiki/daos/concepts/fundamentals/on-chain-vs-off-chain-governan…ifecycle (/wiki/daos/concepts/voting/proposal-lifecycle) · DAO to…/tooling/dao-tooling-overview)

OpenZeppelin Governor is the s… Snapshot (/wiki/daos/tooling/voting/snapshot) records off-chain s…d a Safe (/wiki/daos/tooling/treasury/safe) multisig then acts on i…vernance (/wiki/daos/concepts/fundamentals/on-chain-vs-off-chain-governan…ontracts/governance) library.

From Compound Bravo to a reusa…mpound. Compound (/wiki/daos/organizations/lending/compound-dao) shipped Governo…ek from proposal to execution.

A contract assembled from modu…to exit (/wiki/daos/concepts/membership/rage-quit-and-exit-rights) be…d voting (/wiki/daos/concepts/voting/token-weighted-voting) and d…on (/wiki/daos/concepts/voting/voting-and-delegation) .

The proposal lifecycle Every …ifecycle (/wiki/daos/concepts/voting/proposal-lifecycle) : no step …ct calldata that was voted on.

Who runs on it Governor and i…rnance: Compound (/wiki/daos/organizations/lending/compound-dao) , Uniswap (/wiki/daos/organizations/dexs/uniswap-dao) , ENS (/wiki/daos/organizations/infrastructure/ens-dao) , Gitcoin (/wiki/daos/organizations/public-goods/gitcoin-dao) , Nouns (/wiki/daos/organizations/social/nouns-dao) , and the Arbitrum (/wiki/daos/organizations/networks/arbitrum-dao) and Optimism (/wiki/daos/organizations/networks/optimism-collective) L2 DAOs …ke Tally (/wiki/daos/tooling/voting/tally) and Agora (/wiki/daos/tooling/voting/agora) can index any Governor…o bespoke integration per DAO.

Strengths and known failure mo… attacks (/wiki/daos/concepts/analysis/dao-security-and-governance-at…e design (/wiki/daos/concepts/analysis/how-daos-fail) .

How Caper approaches this Ca…xecution (/wiki/daos/concepts/fundamentals/on-chain-vs-off-chain-governan…e with a smaller blast radius.

Tool OpenZeppelin Governor — the modular, on-chain governance contract library used by most token-voting DAOs Category Governance execution layer — the smart contract that turns a passed vote into an on-chain action Lineage Compound GovernorAlpha (2020) → GovernorBravo (2021) → OpenZeppelin generalised the pattern into a reusable Governor (https://docs.openzeppelin.com/contracts/5.x/governance) library Voting power Read from an IVotes (https://docs.openzeppelin.com/contracts/5.x/api/governance) token ( ERC20Votes (https://docs.openzeppelin.com/contracts/5.x/api/governance) / ERC721Votes (https://docs.openzeppelin.com/contracts/5.x/api/governance) ) — snapshot balances + delegation, not raw balances Execution Optional TimelockController (https://docs.openzeppelin.com/contracts/5.x/api/governance) — a passed proposal is queued, then executes after a delay Front-ends Tally (/wiki/daos/tooling/tally) · Agora (/wiki/daos/tooling/agora) read Governor state directly from chain Licence MIT (OpenZeppelin Contracts) · source on GitHub (https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance) Related On- vs off-chain governance (/wiki/daos/concepts/on-chain-vs-off-chain-governance) · Proposal lifecycle (/wiki/daos/concepts/proposal-lifecycle) · DAO tooling stack (/wiki/daos/tooling/dao-tooling-overview)

OpenZeppelin Governor is the smart-contract framework that most token-voting DAOs use to run their governance on-chain — where the vote and its execution both live in code, not on a signer's discretion. Where Snapshot (/wiki/daos/tooling/snapshot) records off-chain sentiment and a Safe (/wiki/daos/tooling/safe) multisig then acts on it by hand, a Governor closes the loop: a proposal carries the exact calls it will make, token holders vote, and if it passes anyone can trigger the execution the contract already holds. It is the reference implementation of on-chain governance (/wiki/daos/concepts/on-chain-vs-off-chain-governance) , shipped as auditable, MIT-licensed modules in the OpenZeppelin Contracts (https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance) library.

From Compound Bravo to a reusable library The design descends from Compound. Compound (/wiki/daos/compound-dao) shipped GovernorAlpha in 2020 to hand protocol control to COMP holders, then replaced it with GovernorBravo — which put the governance logic behind an upgradeable proxy and added an explicit Abstain option alongside For and Against. OpenZeppelin then generalised that pattern (https://docs.openzeppelin.com/contracts/5.x/governance) into a modular Governor that any project can deploy without forking Compound's code, keeping deliberate compatibility with GovernorAlpha and GovernorBravo (https://docs.openzeppelin.com/contracts/5.x/governance) (via ERC20VotesComp and GovernorTimelockCompound) so Compound-lineage DAOs can migrate. Compound's live parameters still read as the canonical example: a 25,000 COMP proposal threshold, a 2-day review period, 3 days of voting, a 400,000-vote quorum, and a 2-day timelock (https://docs.compound.finance/v2/governance/) — roughly a week from proposal to execution.

A contract assembled from modules Governor is not one monolith but a base contract plus opt-in extensions, so a DAO composes only the policy it wants ( full module reference (https://docs.openzeppelin.com/contracts/5.x/api/governance) ): - GovernorSettings — the tunable knobs: votingDelay (snapshot lag before voting opens), votingPeriod (how long the poll stays open), and proposalThreshold (voting power required to submit). - GovernorVotes — hooks the Governor to an IVotes (https://docs.openzeppelin.com/contracts/5.x/api/governance) token so voting power is read from historical, delegated balances rather than whatever a wallet holds at the moment of voting. - GovernorVotesQuorumFraction — defines quorum as a percentage of total token supply, so it scales as the token does. - GovernorCountingSimple — the tally rule: three options (For, Against, Abstain), where only For and Abstain count toward quorum (https://docs.openzeppelin.com/contracts/5.x/governance) . - GovernorTimelockControl — routes execution through a TimelockController (https://docs.openzeppelin.com/contracts/5.x/api/governance) so a passed proposal is queued and executes only after a mandatory delay, giving holders a window to exit (/wiki/daos/concepts/rage-quit-and-exit-rights) before a change lands. Because voting power comes from a snapshot taken at the proposal's start block, buying tokens after a vote opens grants no extra weight — a core defence discussed under token-weighted voting (/wiki/daos/concepts/token-weighted-voting) and delegation (/wiki/daos/concepts/voting-and-delegation) .

The proposal lifecycle Every proposal walks a fixed state machine — the eight states (https://docs.compound.finance/v2/governance/) shared by Bravo and OZ Governor: Pending (submitted, waiting out the voting delay), Active (voting open), then a terminal branch. A proposal that fails to reach quorum or a majority becomes Defeated; one that passes becomes Succeeded, is Queued in the timelock, and finally Executed. A proposer below threshold can be Canceled, and a queued proposal left un-executed past its grace window turns Expired. This is the concrete, code-enforced version of the abstract proposal lifecycle (/wiki/daos/concepts/proposal-lifecycle) : no step can be skipped, and the calldata that executes is the exact calldata that was voted on.

Who runs on it Governor and its Bravo ancestor underpin a large share of on-chain DAO governance: Compound (/wiki/daos/compound-dao) , Uniswap (/wiki/daos/uniswap-dao) , ENS (/wiki/daos/ens-dao) , Gitcoin (/wiki/daos/gitcoin-dao) , Nouns (/wiki/daos/nouns-dao) , and the Arbitrum (/wiki/daos/arbitrum-dao) and Optimism (/wiki/daos/optimism-collective) L2 DAOs all execute through Governor-family contracts. That concentration is why the tooling ecosystem standardised on it: governance dashboards like Tally (/wiki/daos/tooling/tally) and Agora (/wiki/daos/tooling/agora) can index any Governor by reading the same well-known interface, no bespoke integration per DAO.

Strengths and known failure modes Governor's value is credible neutrality: the rules are public, immutable per-deployment, and execute without a trusted operator. But on-chain execution is not the same as good governance. The recurring failure modes are covered under DAO security and governance attacks (/wiki/daos/concepts/dao-security-and-governance-attacks) — low turnout letting a small quorum decide, whales or delegated blocs steering outcomes, and the sharpest risk, a malicious proposal whose on-chain execution is exactly what makes it dangerous once it clears the timelock. The timelock is the mitigation, not a cure: it buys review and exit time, but a passed proposal still runs the calldata it carried. Governor gives a DAO a trustworthy machine; whether the machine does the right thing still depends on participation and incentive design (/wiki/daos/concepts/how-daos-fail) .

How Caper approaches this Caper (/wiki/foundations/what-is-a-caper) shares Governor's core stance — a passed vote executes on-chain, not at a signer's discretion — but narrows the execution surface deliberately. Rather than arbitrary calldata queued behind a timelock, a Caper proposal resolves to one of a few typed actions: a treasury payout, an investment into another caper, or a vote it casts on the DAO's behalf. Each type runs through its own dedicated execution path rather than a general-purpose call, so the set of things a winning proposal can do is bounded by the contract, not by whatever bytecode a proposer attached. It is the same on-chain-execution (/wiki/daos/concepts/on-chain-vs-off-chain-governance) guarantee with a smaller blast radius.