OpenZeppelin Governor

The framework separates concerns into distinct, pluggable contracts. The core Governor contract manages proposals and voting, while separate modules handle voting tokens (GovernorVotes), vote delegation (GovernorVotesQuorumFraction), and timelock execution (GovernorTimelockControl). This allows developers to compose a governance system tailored to their DAO's specific needs.

Supports multiple voting standards out of the box, enabling compatibility with various token types. Key modules include:

• GovernorVotes: For ERC-20Votes, ERC-721Votes, and ERC-5805-compliant tokens.
• GovernorVotesQuorumFraction: Dynamically calculates quorum based on the total token supply.
• GovernorCountingSimple: A simple majority counting module. This allows for governance with fungible tokens (ERC-20) or non-fungible tokens (ERC-721).

Integrates with TimelockController contracts to introduce a mandatory delay between a proposal's approval and its execution. This critical security feature provides a grace period for the community to react to malicious or erroneous proposals. The GovernorTimelockControl module ensures all successful proposals are queued and executed via the timelock, preventing instant, unilateral changes to the protocol.

Designed for cost-efficiency, especially for voters. It uses vote delegation (like EIP-712) and signature-based voting (EIP-1271) via the GovernorVotes module, allowing users to vote without moving tokens, saving significant gas. The contract architecture minimizes storage writes and state changes during the voting process, reducing transaction costs for all participants.

Built with transparent proxy patterns (using OpenZeppelin's Upgrades Plugins), allowing the governance logic to be upgraded without migrating assets or voting power. It is also forward-compatible, designed to work with emerging standards like ERC-6372 (Clock) for timekeeping and ERC-5805 (Delegation) for more flexible vote delegation models.

The framework is the industry standard, securing billions in assets. Prominent implementations include:

• Uniswap: Uses a GovernorAlpha/GovernorBravo-inspired system, with OpenZeppelin's contracts forming the basis for many forks.
• Compound's Governor Bravo: The original inspiration, with OpenZeppelin Governor providing a more modular and secure evolution.
• Liquity: Uses a custom Governor implementation for its stability pool and token management.

The base Governor contract defines the essential lifecycle of a proposal: proposal creation, voting, and execution. It handles core state management and enforces timing rules, but delegates specific logic—like vote counting and quorum—to separate modules. This separation of concerns is the framework's architectural cornerstone.

These modules determine how votes are cast and tallied. Key implementations include:

• GovernorVotes: Tracks voting power from an ERC20Votes or ERC721Votes token.
• GovernorVotesQuorumFraction: Sets a dynamic quorum based on a percentage of the total token supply.
• GovernorCountingSimple: A simple majority vote counter.
• GovernorCountingSplit: Supports complex vote splitting (e.g., For, Against, Abstain).

The GovernorTimelock module binds the Governor to OpenZeppelin's TimelockController. When a proposal succeeds, its actions are queued in the Timelock, introducing a mandatory delay before execution. This provides a critical security mechanism, allowing token holders a grace period to react to malicious or erroneous proposals before they are enacted on-chain.

Additional modules configure proposal parameters and extend functionality:

• GovernorSettings: Allows setting adjustable parameters like votingDelay, votingPeriod, and proposalThreshold.
• GovernorProposalThreshold: Enforces a minimum token balance to create a proposal.
• GovernorPreventLateQuorum: Extends the voting period if quorum is nearly met near the deadline.
• GovernorCompatibilityBravo: Provides backward compatibility with the Compound Governor Bravo interface.

Developers can implement custom voting strategies by writing new modules that adhere to the framework's interfaces. Examples include:

• Weighted voting based on NFT attributes or staking duration.
• Cross-chain governance using message bridges.
• Gasless voting via signature-based delegation (e.g., using EIP-712). This extensibility is key for building governance tailored to specific DAO needs.

A typical deployment stacks multiple modules. For example:

codeCopy
Governor contract
├── GovernorVotes (for ERC20Votes token)
├── GovernorVotesQuorumFraction (4% quorum)
├── GovernorTimelockControl (2-day delay)
└── GovernorSettings (3-day vote, 1-block delay)

This composability allows protocols like Uniswap, Aave, and Compound to build secure, customized governance with minimal custom code.

Prominent protocols built on OpenZeppelin Governor demonstrate its versatility across DeFi, NFTs, and infrastructure:

• Uniswap: Uses a custom Governor for protocol fee changes and treasury management.
• Aave: Leverages Governor for risk parameter updates and ecosystem grants.
• Nouns DAO: Employs Governor for daily NFT auctions and treasury spending.
• Lido: Utilizes it for validator set management and staking parameter adjustments.

A robust ecosystem of tools and frontends has emerged to interact with Governor contracts, lowering the barrier to participation:

• Snapshot: Often used for gasless, off-chain signaling that informs on-chain proposals.
• Tally: A dedicated governance dashboard for proposal creation, delegation, and voting.
• Safe (Gnosis Safe): Commonly used as the Timelock or executor contract for secure, multi-sig execution of passed proposals.
• Indexers: Subgraphs and APIs from The Graph and others provide easy querying of proposal data.

While providing a secure foundation, proper implementation requires careful attention to key parameters:

• Quorum and Voting Period: Setting appropriate thresholds to balance security with participation.
• Timelock Duration: Configuring a delay long enough for users to react to malicious proposals.
• Proposal Threshold: Determining the minimum token power needed to create a proposal.
• Governor Upgrades: Managing upgrades via a proxy pattern or a new Governor instance with explicit migration paths.

The ecosystem continues to evolve with new extensions and patterns built on the core standard:

• GovernorVotesQuorumFraction: Dynamically adjusts quorum based on circulating supply.
• Cross-chain Governance: Proposals that execute actions on other chains via bridges (e.g., using Governor with Axelar or LayerZero).
• Optimistic Governance: Patterns that allow for faster execution with a challenge period, blending with optimistic rollup concepts.
• Gasless Voting: Integration with EIP-712 signatures and relayers to subsidize voter transaction costs.

Governor's security depends on the integrity of the underlying voting token. Common attack vectors include:

• Flash loan attacks: Borrowing tokens to gain temporary voting power for a single block.
• Token whale dominance: A single entity controlling a majority of tokens can force proposals.
• Delegation exploits: Bugs in the token's delegation logic can lead to unauthorized voting power accumulation. Mitigation involves using tokens with safeguards like vote-escrow or time-locks.

Incorrectly set governance parameters are a primary failure mode.

• Voting delay/period: Too short risks voter suppression; too long creates stagnation.
• Proposal threshold: Set too low, it enables spam; too high, it centralizes power.
• Quorum: A dynamic quorum (e.g., OZ's GovernorVotesQuorumFraction) is often safer than a fixed value, which can be exploited when participation is low. Parameters must be stress-tested against various participation scenarios.

The execute function is high-risk as it calls arbitrary addresses.

• Malicious calldata: A proposal can execute code that drains the treasury or upgrades the governor itself.
• Reentrancy attacks: If the target contract is malicious, it could re-enter the Governor during execution. While Governor itself uses Checks-Effects-Interactions, it cannot protect against reentrancy in the called contract. Rigorous proposal vetting and timelock controllers are essential safeguards.

If the Governor contract is upgradeable (via UUPS or Transparent Proxy), extreme caution is required.

• Proxies add complexity: Increases attack surface for initialization and storage collision bugs.
• Governance freeze: A malicious upgrade could permanently disable the governance system.
• Timelock for upgrades: The upgrade mechanism itself must be behind a timelock, often separate from the operational timelock, to prevent a single proposal from seizing absolute control.

On-chain governance is constrained by block gas limits and economic costs.

• Gas-intensive voting: If voting requires complex logic, gas costs may disenfranchise smaller holders.
• Proposal execution gas limit: The execute function's operations must fit within a block's gas limit, which can be a vector for denial-of-service by designing proposals that exceed it.
• Economic attacks: Attackers may spam proposals or votes to drain opponents' funds through gas costs, a form of governance fatigue attack.

The defined states a proposal moves through from creation to completion.

1. Pending: Created, waiting for the voting delay to start.
2. Active: Voting period is open; delegates can cast votes.
3. Defeated: Fails to meet quorum or vote thresholds.
4. Succeeded: Passes vote but awaits execution via the Timelock.
5. Queued: Scheduled for execution after the timelock delay.
6. Executed: The proposed transactions have been successfully executed.
7. Canceled: Canceled by the proposer or guardian.