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.

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 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 guarantee with a smaller blast radius.