---
title: "OpenZeppelin Governor"
url: "https://caper.network/wiki/dao-governance/tooling/voting/openzeppelin-governor"
updated: 2026-09-07
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# OpenZeppelin Governor

|  |  |
| --- | --- |
| **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) |

**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/dao-governance/tooling/voting/snapshot) records off-chain sentiment and a [Safe](/wiki/dao-governance/tooling/treasury/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/dao-governance/concepts/fundamentals/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/lending/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/dao-governance/concepts/membership/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/dao-governance/concepts/voting/token-weighted-voting) and [delegation](/wiki/dao-governance/concepts/voting/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/dao-governance/concepts/voting/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](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.

## Who runs on it

Governor and its Bravo ancestor underpin a large share of on-chain DAO governance: [Compound](/wiki/daos/lending/compound-dao), [Uniswap](/wiki/daos/dexs/uniswap-dao), [ENS](/wiki/daos/infrastructure/ens-dao), [Gitcoin](/wiki/daos/public-goods/gitcoin-dao), [Nouns](/wiki/daos/social/nouns-dao), and the [Arbitrum](/wiki/daos/networks/arbitrum-dao) and [Optimism](/wiki/daos/networks/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/dao-governance/tooling/voting/tally) and [Agora](/wiki/dao-governance/tooling/voting/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/dao-governance/concepts/analysis/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/dao-governance/concepts/analysis/how-daos-fail).

## How Caper approaches this

[Caper](/wiki/foundations/what-is-a-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](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance) 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](/wiki/governance/execution) 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](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)