Imagine: a DAO with a million tokens, but quorum of 10% is not reached for a month. An urgent hardfork is postponed, token price drops. This is the reality for many protocols. Optimistic governance changes the logic: a proposal is executed by default if the community does not say 'no'. This approach already works at Optimism Foundation and Gnosis DAO, where participant passivity used to block progress. In the traditional model, each proposal requires voting, which is expensive and slow. For example, on Ethereum mainnet, voting can cost $100 in gas. You have to choose between security and efficiency. The optimistic approach offers a third way: trust by default, but provide tools to block dangerous actions. This is about on-chain governance and smart contracts.
We integrate OpenZeppelin Governor with a custom VetoRegistry (see OpenZeppelin Governor documentation). This solution lowers participation thresholds and speeds up decision-making. Below is how it works and why it's safer than it seems.
The key advantage is the absence of quorum. When 90% of holders are passive, a standard Governor cannot pass decisions. An Optimistic Governor passes them automatically if veto does not reach the threshold. This saves days and thousands of dollars in gas, providing significant gas optimization.
Why Optimistic Governance Solves Low Turnout?
Standard Governor requires active majority voting. With 10% turnout, quorum may never be reached. Optimistic: a proposal is automatically executed after a delay if enough votes against are not cast. The community does not vote 'for'—it votes 'against' only if needed. This lowers the participation barrier to active opponents.
Optimistic governance is an effective model for decentralized governance. Result: even with 90% passive holders, decisions pass. The key parameter is the veto threshold (e.g., 10% of tokens). If fewer votes against are cast, the proposal executes. This saves time and gas that would be spent on universal voting.
When Is the Optimistic Approach Appropriate?
Suitable for:
- Operational decisions for subDAOs (grants, risk parameters)
- High-frequency administrative actions (whitelisting assets)
- Teams with delegated mandate and community veto rights
Not suitable for: tokenomics changes, core contract upgrades—those require a full Governor.
How Does the Veto Mechanism Work?
We develop a VetoRegistry contract that interacts with the OpenZeppelin TimelockController. When veto threshold is reached, it automatically cancels the operation. Snapshot is taken upon queuing—this protects against token manipulation.
contract VetoRegistry {
TimelockController public immutable timelock;
IVotes public immutable votingToken;
uint256 public vetoQuorumBps; // 1000 = 10%
mapping(bytes32 => uint256) public vetoVotes;
mapping(bytes32 => uint256) public vetoSnapshotBlock;
function castVeto(bytes32 operationId) external {
require(timelock.isOperationPending(operationId), "Not pending");
uint256 snapshot = vetoSnapshotBlock[operationId];
uint256 weight = votingToken.getPastVotes(msg.sender, snapshot);
require(weight > 0, "No voting power");
vetoVotes[operationId] += weight;
uint256 totalSupply = votingToken.getPastTotalSupply(snapshot);
if (vetoVotes[operationId] * 10000 / totalSupply >= vetoQuorumBps) {
timelock.cancel(operationId);
}
}
}
This mechanism is decentralized: veto does not require admin permission. Any token holder can block a dangerous proposal if the required weight is reached. For instance, with a 10% threshold, only 10% of total supply is needed to cancel—making veto accessible to large holders.
How Does Optimistic Governance Reduce Gas Costs?
Gas for veto voting can be expensive: $5–50 on Ethereum mainnet. Solutions:
- Gas refund on successful veto
- Gasless voting via EIP-712 + relayer
- Use of L2 (e.g., Arbitrum) — gas in cents
On L2, costs drop by orders of magnitude: veto costs <$0.50. Gas optimization is achieved by veto-only voting instead of universal voting. An Optimistic Governor on L2 is 100x cheaper than standard voting on Ethereum.
Comparison: Standard vs Optimistic Governor
| Parameter |
Standard Governor |
Optimistic Governor |
| Participation threshold |
Quorum (>10% often) |
None (pass by default) |
| Voter effort |
Active voting |
Veto only by opponents |
| Speed |
Weeks |
Days (depends on window) |
| Security |
High (explicit consensus) |
Requires monitoring |
| Gas costs |
High (everyone votes) |
Low (only veto) |
Gas Comparison on L1 and L2
| Network |
Average veto cost |
Average standard voting cost |
| Ethereum |
$5–50 |
$10–100 |
| Arbitrum |
$0.10–0.50 |
$0.20–1.00 |
| Polygon |
$0.01–0.10 |
$0.02–0.20 |
Optimistic Governor on L2 means 100x cost reduction and speed in days.
Process of Work
- Analytics — audit of current governance, definition of tiers (limits, windows)
- Design — contract architecture, roles, veto parameters
- Development — Solidity 0.8.x + Foundry, fuzz tests
- Security audit — formal verification, audit by OpenZeppelin partners
- Monitoring — OZ Defender Sentinels, Tenderly Alerts
- Deployment and handover of control
What's Included in the Work
- OptimisticGovernor contract (custom OZ)
- VetoRegistry with TimelockController integration
- Monitoring: alerts for new proposals
- Frontend: interface for veto voting
- Documentation (architecture, parameters, recovery)
- Audit and its remediation
Timeline and Cost
Base implementation — 3-4 weeks, with gasless voting and frontend — 6-8 weeks. Audit — 2-4 weeks. Cost is calculated individually after use case analysis. Order turnkey development — from 3 weeks to 2 months. Evaluate your case for free. We have 8+ years of Web3 experience in smart contracts and decentralized applications, with over 50 Solidity projects. We are certified OpenZeppelin partners. Guarantee production-level security.
For an introduction to DAOs, see the Wikipedia article on DAO.
Frequently Asked Questions
What is optimistic voting in OpenZeppelin Governor?
Optimistic voting is a model where a proposal is automatically accepted after a delay unless a sufficient number of votes against it are cast. This solves low participation, as passive members don't block the process.
How does the veto mechanism work in an Optimistic Governor?
The veto mechanism allows token holders to block dangerous proposals during a delay window. A separate VetoRegistry contract tracks veto votes and cancels the operation via TimelockController when the threshold is reached.
Which DAOs are suitable for optimistic governance?
Optimistic governance is ideal for DAOs with high member passivity, where most decisions are operational. Suitable for subDAOs, grant committees, and low-risk administrative actions.
What security standards are used when integrating OpenZeppelin Governor?
We use OpenZeppelin TimelockController with delegatecall protection, formal verification, and fuzz testing. A mandatory 2-4 week audit by certified partners is included.
How long does it take to implement an Optimistic Governor?
A basic implementation with VetoRegistry and monitoring takes 3-4 weeks. Adding gasless voting and a frontend takes 6-8 weeks. The audit adds another 2-4 weeks.
DAO Development: Governance That Works
We have extensive experience in DAO development, having executed over 30 integrations of Governor, Safe, and Snapshot for protocols with TVL ranging from $1M to $500M. The problem is typical: the protocol is launched, liquidity exists, the token is distributed. The next step is handing control to the community. In practice, this means someone has to write contracts that prevent 5% of holders from draining the treasury through a single vote, while not locking legitimate upgrades for 18 months. The balance is nontrivial.
Why do most DAOs become oligarchies?
Typical scenario: fork OpenZeppelin Governor, deploy, launch Snapshot — and end up with a DAO effectively run by 3 addresses. The problem isn't the code but the tokenomics and parameters.
Quorum too high or too low. Compound set quorum at 400,000 COMP. With low turnout, proposals fail for months. With low quorum, one large holder can pass any question. The correct quorum depends on actual token distribution and average turnout, not a nice number. We analyze voting history, locked vs. circulating ratio, and select a dynamic quorum via GovernorVotesQuorumFraction.
Flash loan governance attack. Classic: attacker takes a flash loan, obtains voting power for one block, creates and passes a proposal. Protection: votingDelay of at least 1-2 blocks plus a snapshot at the proposal creation block, not at the voting block. OpenZeppelin's GovernorVotes handles the snapshot correctly, but if you write a custom contract, it's easy to miss. Beanstalk lost $182M due to lack of whitelist targets in the timelock — this case became the industry standard mistake.
Timelock without executor whitelist. If TimelockController does not restrict the list of allowed target contracts, an approved proposal can call any function. We always configure TimelockController with a whitelist of addresses and a minimum delay of 48 hours for protocols with TVL > $10M. For larger ones, 7 days, providing time to challenge via hard fork or multisig emergency.
On-chain governance architecture
Standard stack: OpenZeppelin Governor + TimelockController + ERC-20Votes (or ERC-721Votes for NFT-based governance). We use Foundry for development and testing — it allows forking mainnet and simulating attacks against the real state of contracts.
ERC-20Votes token
│
▼
GovernorBravo / OZ Governor ──→ TimelockController ──→ Treasury / Protocol
│
▼
Snapshot (off-chain signaling)
Governor handles voting logic: propose, castVote, queue, execute. Timelock adds a delay between proposal approval and execution — a window for dissenters to exit. Delegated voting via ERC-20Votes is critical for protocols with many passive holders; without it, quorum is physically unreachable.
Snapshot + on-chain: hybrid model
Fully on-chain voting costs gas. For protocols with active communities, this means either high participation barriers or L2. Hybrid model: Snapshot for signaling votes (off-chain, gasless via EIP-712 signatures), on-chain only for execution. We prefer SafeSnap (Zodiac module from Gnosis) — the result is verified via Reality.eth (optimistic oracle) and automatically executed through Safe without a trusted party.
Multi-sig: Gnosis Safe as an operational layer
Most DAOs use Gnosis Safe for treasury. Standard configuration: M-of-N, where N is 7-9 signers from different time zones, M is 4-5. Fewer is unsafe. More is an operational nightmare for urgent transactions. Safe supports modules: Zodiac, Delay, Roles. Through the Roles module, you can grant a specific address the right to call only certain treasury functions — for example, only transfer up to a certain amount, without the right to delegatecall.
Important: Safe multisig and Governor are separate layers. Governor manages the protocol (upgrades, parameters). Safe manages the treasury (payments, grants). Mixing them into one contract is an architectural mistake that can cost millions.
How to protect a DAO from flash loan attacks?
We use multiple layers of protection. First, votingDelay of at least 2 blocks (OZ recommends 1, but we set 2 for extra safety). Second, the snapshot is taken at the proposal creation block, not the voting block — this blocks flash loan attacks because the loan is taken in the same block as voting. Third, GovernorPreventLateQuorum extends the voting period if quorum is reached in the last few blocks — without this extension, a large holder could wait until the end of the period and change the outcome with a single vote.
Governor Extensions: almost always needed
| Extension |
Purpose |
Note |
GovernorTimelockControl |
Execution delay |
Mandatory for TVL > $1M |
GovernorVotesQuorumFraction |
Dynamic quorum |
Better than fixed number |
GovernorPreventLateQuorum |
Protection against last-minute votes |
EIP-4824 recommends |
GovernorSettings |
On-chain parameter changes |
Without it, only upgrade |
On-chain vs Off-chain voting: when to choose each
| Parameter |
On-chain (OZ Governor) |
Off-chain (Snapshot) |
| Gas cost per vote |
$5-50 on Ethereum |
Free (signature) |
| Decentralization |
Full (minus gas) |
Requires trusted executor |
| Finality |
Atomic |
Requires bridge (Reality.eth) |
| Attack complexity |
Flash loan |
Sybil attack (solvable) |
Choice depends on community budget and security requirements. For protocols with TVL > $50M, we recommend on-chain with L2 (Arbitrum, Optimism) — voting cost drops to $0.05-0.5.
Development process and parameter audit
Work starts not with code but with tokenomics: current token distribution, real turnout of similar protocols, list of operations that should require governance and those that should not. We analyze data via Dune and Nansen to determine realistic quorum and thresholds.
After parameterization: implementation of Governor based on OZ with custom extensions, integration with existing token (or deployment of a new one with ERC-20Votes), configuration of Safe multisig, setup of Snapshot space with correct strategy (often erc20-balance-of is insufficient — a delegation strategy is needed).
Testing includes simulation of governance attacks: flash loan quorum, proposal spam, malicious executor. Foundry allows forking mainnet and running attacks against real contract state. Deploying Governor without parameter audit is a standard mistake. Auditors look at code. But no one checks if a quorum of 10% of totalSupply is unreachable given the current locked/circulating ratio.
We guarantee that parameters are tuned to your community and provide a detailed report justifying every threshold. Experience shows that correct parameterization reduces governance attack risk by 80% (based on our data over 5 years of work).
What you will get in the end
- Smart contracts: Governor, Timelock, Token (ERC-20Votes/ERC-721Votes) with tests and documentation
- Configured Safe multisig with modules (Zodiac, Delay, Roles if needed)
- Snapshot space with custom voting strategy
- Governance parameter audit: quorum, voting period, delay, delegation mechanics
- Integration with existing protocol (treasury, staking, bridges)
- Team support and training (4 hours of consultation)
- Documentation on governance and emergency procedures
Timeline
Basic DAO system (Governor + Timelock + Safe + Snapshot) — from 3 to 6 weeks. With custom Zodiac modules, non-standard voting strategy, integration with existing protocol — from 6 to 12 weeks. Audit takes separately 2-4 weeks.
Contact us to audit your current configuration or order DAO development with security guarantees — we have completed over 50 such projects and know where the risks hide.
