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 records off-chain sentiment and a 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, shipped as auditable, MIT-licensed modules in the OpenZeppelin Contracts library.

From Compound Bravo to a reusable library

The design descends from Compound. Compound 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 into a modular Governor that any project can deploy without forking Compound's code, keeping deliberate compatibility with GovernorAlpha and GovernorBravo (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 — 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):

• 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 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.
• GovernorTimelockControl — routes execution through a TimelockController so a passed proposal is queued and executes only after a mandatory delay, giving holders a window to exit 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 and delegation.

The proposal lifecycle

Every proposal walks a fixed state machine — the eight states 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: no step can be skipped, and the calldata that executes is the exact calldata that was voted on.

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 now holds seventeen contracts, and the CHANGELOG dates each one:

• v4.5.0 (9 February 2022) – GovernorPreventLateQuorum extends the deadline when a vote reaches quorum 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 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, the subject of the next section.
• v5.2.0 (8 January 2025) – GovernorCountingOverridable lets a token holder overrule the vote their delegate already cast, emitting OverrideVoteCast and a matching VoteReduced against the delegate. It requires a token inheriting VotesExtended, 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 and its supply-fraction variant let a proposal that clears a higher bar reach Succeeded before the deadline; GovernorProposalGuardian 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 relays a passed proposal to a remote executor on another chain over an ERC-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 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 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 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, built under a Uniswap Grants Program grant and introduced to the Uniswap DAO in July 2022. That temperature check drew two replies and went nowhere. In 2024 ScopeLift built it again for Arbitrum, as L2ArbitrumGovernorV2 with a GovernorCountingFractionalUpgradeable, and OpenZeppelin reviewed it between 8 and 19 July 2024 – nine issues, eight resolved.

The on-chain proposal to deploy it did not pass. The objection Offchain Labs raised in the follow-up thread 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 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.

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. 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.

Who runs on it

Governor and its Bravo ancestor underpin a large share of on-chain DAO governance: Compound, Uniswap, ENS, Gitcoin, Nouns, and the Arbitrum and Optimism L2 DAOs all execute through Governor-family contracts. That concentration is why the tooling ecosystem standardised on it: governance dashboards like Tally and 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 — 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.

How Caper approaches this

Caper starts from Governor's core stance — what a vote authorises is carried out by contract, not at a signer's discretion — and 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, a divestment back out of one, a rewrite of the caper's own token metadata, or — on the $CAPER caper alone — an upgrade of the shared logic (ProposalOptionData.kind in contracts/common/src/lib.rs). 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 guarantee 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 the market window, and the winning action executes at the close of that window if the caper's time-weighted price held at or above the baseline locked at the trigger — 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.

References

• OpenZeppelin Contracts – CHANGELOG (release dates for every governance extension cited above) and the v5.7.0 release, 29 July 2026
• contracts/governance/extensions – the seventeen modules, including GovernorCountingFractional.sol (the 255 support value, the packed uint128 params, usedVotes), GovernorCountingOverridable.sol (the early-closure note, OverrideVoteCast, VoteReduced), GovernorSuperQuorum.sol (the premature-success warning) and GovernorProposalGuardian.sol (_validateCancel and the unconfigured-guardian fallback)
• VotesExtended.sol – the delegation and balance checkpoints the override module requires of the token
• ScopeLift – Flexible Voting and flexiblevoting.com (the UGP grant, the use cases upstreamed into v5.1)
• Uniswap governance forum – Temperature Check: Upgrading to a Flexible Voting enabled Governor, 14 July 2022
• Arbitrum DAO forum – Arbitrum Governor V2 Review (OpenZeppelin's review of ScopeLift's L2ArbitrumGovernorV2, 8–19 July 2024) and Change to New Governance Contracts that Allow Proposal Cancellation (the failed vote, the Offchain Labs five-governor objection, the split, and the February 2026 status)
• OpenZeppelin docs – Governance and the Governance API reference