OpenZeppelin Governor Integration

Developing optimistic governance (optimistic approval)

Optimistic governance inverts the standard model. Standard Governor: proposal created → community votes → at quorum and majority passes. Optimistic: proposal created → auto-executes after delay → if community opposes, they must actively block it.

Idea borrowed from optimistic rollups: assume valid by default, challenge requires action. For DAO this solves main problem of most governance systems — voter apathy. When quorum isn't reached for months due to low turnout, protocol freezes. Optimistic governance works even with 90% passive holders.

When optimistic approach is justified

Not every DAO needs optimistic approval. Suitable when:

• Operations decided by team with delegated mandate (SubDAO, grants committee, security council)
• High-frequency administrative actions (risk parameter updates, new asset whitelist)
• Community trusts execution team but wants veto right
• Standard governance too slow for market event reaction

Unsuitable for: tokenomics changes, core contract upgrades, irreversible treasury decisions. For these — standard Governor with full voting.

Architectural patterns

Pattern 1: Optimistic Multisig

Simplest model. Trusted multisig (core team, 5/9 signatures) executes decisions. Timelock gives community veto window through emergency governance.

Multisig submits tx → TimelockController queues → [7 days window] → execute
                                                    ↑
                                         Community can invoke Guardian veto

Problem: this isn't true optimistic governance, just multisig with delay. No community veto mechanism without centralized Guardian.

Pattern 2: Veto-based Governor

More decentralized. Proposal auto-passes after delay if doesn't reach veto-quorum (e.g., 10% tokens voted AGAINST).

Mechanism: proposal created → votingPeriod (e.g., 7 days for veto vote collection) → if AGAINST < vetoThreshold — passes → queues in timelock → executes.

Who can create proposals is important for security: if threshold low — spammers. Solution: only Security Council or SubDAO members through separate approval contract can create.

Pattern 3: Optimistic SubDAO (Optimism model)

Optimism uses bicameral system. Token House (all OP holders) — full voting. Citizens' House (badgeholders) — counterbalance. For some decisions: Citizens' House can veto Token House majority.

For smaller protocols: SubDAO model. Core team = SubDAO with optimistic rights within limits. Beyond limits — full governance.

SubDAO Action Categories:
├── Tier 1 (< $50k, params) → Optimistic approval, 48h veto window
├── Tier 2 ($50k - $500k, integrations) → Multisig vote, 7d veto window  
└── Tier 3 (> $500k, upgrades) → Full token voting, no optimistic

Detailed veto mechanism implementation

VetoRegistry Contract

Separate contract registers veto votes and interacts with TimelockController:

contract VetoRegistry {
    TimelockController public immutable timelock;
    IVotes public immutable votingToken;
    
    uint256 public vetoQuorumBps;  // e.g. 1000 = 10%
    
    mapping(bytes32 => uint256) public vetoVotes;           // operationId => total weight
    mapping(bytes32 => mapping(address => bool)) public hasVetoed;
    mapping(bytes32 => uint256) public vetoSnapshotBlock;   // block for voting power calc
    
    event VetoCast(bytes32 indexed operationId, address indexed voter, uint256 weight);
    event OperationVetoed(bytes32 indexed operationId);
    
    function castVeto(bytes32 operationId) external {
        require(timelock.isOperationPending(operationId), "Not pending");
        require(!hasVetoed[operationId][msg.sender], "Already vetoed");
        
        uint256 snapshot = vetoSnapshotBlock[operationId];
        require(snapshot != 0, "Snapshot not set");
        
        uint256 weight = votingToken.getPastVotes(msg.sender, snapshot);
        require(weight > 0, "No voting power");
        
        hasVetoed[operationId][msg.sender] = true;
        vetoVotes[operationId] += weight;
        
        emit VetoCast(operationId, msg.sender, weight);
        
        // Check veto threshold reached
        uint256 totalSupply = votingToken.getPastTotalSupply(snapshot);
        if (vetoVotes[operationId] * 10000 / totalSupply >= vetoQuorumBps) {
            timelock.cancel(operationId);
            emit OperationVetoed(operationId);
        }
    }
}

Snapshot for veto votes

When queuing operation in TimelockController — fix snapshot block for veto calculations. Through onQueue hook or separate call:

function onOperationQueued(bytes32 operationId) external onlyTimelock {
    vetoSnapshotBlock[operationId] = block.number;
}

Important: snapshot must be at queue time, not proposal creation. Otherwise attacker can accumulate tokens after proposal creation, use them to block veto (if wants to pass harmful proposal) or reverse.

Canceller role management

TimelockController needs to grant VetoRegistry CANCELLER_ROLE. This lets contract cancel operations at veto threshold.

// At deploy
timelock.grantRole(timelock.CANCELLER_ROLE(), address(vetoRegistry));

// Remove CANCELLER from multisig after launch (or keep as emergency)
// timelock.revokeRole(timelock.CANCELLER_ROLE(), multisig);

Participation economics in veto

Problem with veto systems: gas cost of voting. If veto vote costs $5-50 in gas and holder has small stake — rational not to vote. This means only large holders really participate in veto.

Solutions:

• Gas refund. Protocol reimburses gas for veto voting if proposal was ultimately blocked. VetoRegistry sends refund upon cancellation.
• Gasless voting via EIP-712 + relayer. User signs veto off-chain, relayer publishes on-chain, paying gas. Uses meta-transactions (ERC-2771 with Forwarder).
• Optimism: L2 for veto. If protocol on L2 — gas already cheap (cent-level), problem less relevant.

Security considerations

Harmful proposal through optimistic path

Attack: attacker creates harmful proposal (drain treasury via malicious calldata), calculates community won't notice in veto window. Defenses:

• Proposal monitoring. Automatic alerts on new timelock proposals. Defender (OZ Defender), custom keeper, Tenderly Web3 Actions.
• High veto threshold doesn't help: attacker could have > (100% - threshold) votes, blocking veto. Threshold must be really achievable for active community.
• Multisig as backstop CANCELLER. Besides VetoRegistry — team has emergency cancel right. Centralizing, but necessary early stage.

Timelock bypass via delegatecall

If proposal includes delegatecall in TimelockController — critical vulnerability: delegatecall executes in Timelock context, can change storage including roles. OZ TimelockController has protection: _execute() doesn't accept delegatecall. Any custom implementation must reproduce this protection.

Replay attack on restart

If protocol redeploys or TimelockController changes — old salt/operationId might match new ones. Ensure new deploy doesn't inherit old timelock state.

Real examples

Optimism Foundation. Security Council can take emergency actions (upgrade, pause) with 24-hour timelock. Standard proposals — full Token House voting.

Gnosis DAO. Uses optimistic governance for routine decisions through specialized SubDAO.

Aragon. Aragon OSx supports optimistic through official OptimisticTokenVotingPlugin.

Stack and process

Contracts: Solidity 0.8.x + OZ TimelockController + custom VetoRegistry. Foundry tests: fuzz for veto threshold calcs, invariant tests (if vetoed → execution impossible).

Monitoring: OZ Defender Sentinels or Tenderly Alerts on CallScheduled events — Discord/Telegram alerts immediately.

Frontend: page of active timelock operations with veto interface. Show countdown to execution and current veto vote count.

Timeline: basic implementation (OptimisticGovernor + VetoRegistry + monitoring) — 3-4 weeks. With gasless voting and full frontend — 6-8 weeks. Audit mandatory — 2-4 weeks.

Cost calculated after architectural analysis of specific use case.