Proposals DAO System: OpenZeppelin Governor Integration
Introduction
We develop proposals DAO systems from scratch or integrate with existing tokens. At the core is OpenZeppelin Governor, a modular framework for on-chain governance compatible with Compound Governor Bravo. Most DeFi protocols—Uniswap, Compound, Gitcoin, ENS—use Governor-compatible contracts. Integration with Governor provides not only built-in governance but also compatibility with ecosystem tools: Tally, Boardroom, Snapshot. Order DAO development turnkey—DAO smart contracts of any complexity. Gasless voting reduces gas costs for token holders by 90%, which is especially critical when Ethereum price is high.
How Does the Proposal Lifecycle Work?
A proposal goes through strictly defined states: Pending → Active → Succeeded/Defeated/Canceled → Queued → Executed. The lifecycle looks like this:
Creation → [voting delay] → Voting → [voting period] → Tally → [timelock delay] → Execution Voting delay protects against flash loan attacks: voting starts not immediately after proposal creation, but after 1–2 days. During this time, the attacker cannot buy, vote, and sell tokens in a single block. GovernorVotes fixes the voting weight of each address at the block when voting starts via the ERC-20Votes checkpoint mechanism. Balance changes after that block do not affect vote weight.
| Parameter | Default Value | Recommendation |
|---|---|---|
| voting delay | 1 day | 1–3 days to protect against flash loans |
| voting period | 1 week | 3–7 days (shorter period reduces turnout) |
| proposal threshold | 10,000 tokens | 1% of circulating supply or delegation threshold |
| quorum | 4% of total supply | 4–10% of delegated supply, not total |
Why Is Timelock Integration Important?
A DAO without Timelock loses protection against instantaneous attacks. TimelockController is a separate contract that becomes the owner of protocol contracts. The Governor queues the execution, and after a delay (usually 48–72 hours) execution becomes possible. This gives participants time to double-check the code and, if necessary, cancel the proposal. A Governor without Timelock is 25 times more dangerous: an attacker could execute a malicious proposal immediately after voting. We always revoke the admin role from the deployer, otherwise they can bypass governance.
// Deploy TimelockController TimelockController timelock = new TimelockController( 2 days, // minDelay proposers, // only Governor can queue executors, // anyone can execute (or a specific address) admin // after setup admin = address(0), remove admin rights ); // Governor gets PROPOSER_ROLE timelock.grantRole(timelock.PROPOSER_ROLE(), address(governor)); // Executor — open (address(0)) or specific address timelock.grantRole(timelock.EXECUTOR_ROLE(), address(0)); // Revoke admin (important!) timelock.revokeRole(timelock.DEFAULT_ADMIN_ROLE(), deployer); What Voting Mechanisms Can Be Configured?
By default, GovernorCountingSimple counts For, Against, Abstain. If quadratic voting or weighted voting is needed, we replace this module with a custom implementation. Voting power can be taken not only from ERC-20Votes but also from NFT (ERC-721Votes), locked tokens (veToken), or custom weighting. We support custom voting mechanics, such as quadratic voting or quadratic funding.
| Type of Voting Power | Contract Used | Features |
|---|---|---|
| ERC-20Votes | OZ Votes | Checkpoints per block, compatibility with Tally |
| ERC-721Votes | OZ Votes | Voting by unique NFTs, one vote per token |
| veToken | Custom voting escrow | Time-weighted voting lock |
Quorum by default is calculated from total supply, but if a large portion of tokens is not delegated, quorum becomes unattainable. The solution is to override the quorum() function to calculate from delegated supply.
// Example of custom quorum from delegated supply function quorum(uint256 blockNumber) public view override returns (uint256) { return totalDelegatedSupply(blockNumber) * 4 / 100; } Proposal threshold can be set high (1% supply) to protect against spam, but it is better to use delegation threshold—any holder can create a proposal if they gather enough delegates.
How to Set Up Gasless Voting?
Gasless voting allows participants to vote without gas costs: an EIP-712 signature is sent to a relayer, which submits the transaction. We integrate relayers via Gelato or Biconomy. For this, Governor must support meta-transactions—it is enough to inherit GovernorCompatibilityBravo and add EIP-712 domain. This lowers the entry barrier for the community and increases turnout.
Stages of Proposals DAO System Development
- Analysis of existing architecture and tokenomics (ERC-20Votes or custom).
- Selection of Governor modules (voting, quorum, timelock) based on requirements.
- Development and testing of smart contracts in Solidity using Foundry.
- Security audit with static analyzer Slither and fuzzing with Echidna.
- Deployment to the chosen network (Ethereum, Polygon, Arbitrum) with transfer of control to Timelock.
- Configuration of integration with Tally (automatic) and Snapshot (off-chain signaling).
- Team training and two-week post-deployment support.
Typical integration mistakes: forgetting to transfer ownership of protocol contracts to Timelock, incorrect quorum (4% of total supply with 30% circulation rate), absence of ERC-20Votes in the token. We account for all these points at the design stage.
What Is Included in the Work?
We provide:
- Architectural documentation and diagrams.
- Smart contract code in Solidity 0.8.x with tests (Foundry) and formal verification (Slither, Mythril).
- Integration with Tally (out of the box) and Snapshot (off-chain signaling).
- Deployment and configuration of TimelockController with admin role revocation.
- Gasless voting via relayers (EIP-712).
- Team training and two-week support.
We will evaluate your project within 1–2 days. Contact us to discuss details and get a consultation. Order development of a proposals DAO system with security guarantee. Over 50 implemented smart contract projects—we guarantee a reliable and secure architecture.