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.
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.
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):
votingDelay (snapshot lag before voting opens), votingPeriod (how long the poll stays open), and proposalThreshold (voting power required to submit).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.
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.
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:
_maxLateQuorumVoteExtension defaults to votingPeriod(), capping total voting duration at twice the period, because an unbounded extension could otherwise brick governance.AccessManager instead of a single TimelockController, so the delay is set per restricted function rather than globally for every proposal.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.GovernorSequentialProposalId numbers proposals 1, 2, 3 instead of hashing their calldata.GovernorNoncesKeyed, keyed nonces for voting by signature.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.
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.
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.
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.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.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.
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 front-ends like Tally, Agora and, since March 2026, Snapshot can index any Governor by reading the same well-known interface, no bespoke integration per DAO.
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.
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.
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)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)