How to Structure a Proposal Lifecycle

A proposal lifecycle defines the end-to-end process for creating, reviewing, voting on, and executing changes to a decentralized protocol. Unlike informal discussions, a formalized lifecycle provides deterministic execution and audit trails on-chain. Common stages include ideation, draft creation, temperature checks, formal proposal submission, voting, queuing, and execution. This structure prevents governance attacks, manages upgrade risks, and aligns community expectations. Major protocols like Compound and Uniswap implement variations of this model to manage billions in protocol-controlled value.

The lifecycle typically begins in a forum like Commonwealth or Discourse, where an idea is socialized as a Request for Comment (RFC). This off-chain phase gathers community feedback, refines the proposal's technical and economic impact, and builds consensus. Key considerations here include specification clarity, contract audit requirements, and voter delegation strategies. A well-drafted RFC should link to executable code, such as a Governor Bravo-compatible contract on Ethereum, and include a formal snapshot of the proposed state changes for review.

Once social consensus is reached, the proposal moves on-chain. A proposer must hold a minimum proposal threshold of governance tokens to submit. The proposal transaction includes the target contract addresses, calldata for the function calls, and a description hash. It then enters a voting delay period, allowing token holders to review the final code. For example, a proposal to adjust the borrowCap for a specific asset on Aave would specify the Aave V3 Pool contract address and the encoded setBorrowCap function call.

The voting period is the core decision-making phase, where token holders cast votes weighted by their stake. Voting strategies can include simple token-weighted voting, conviction voting, or quadratic voting. Critical security measures here are the quorum requirement (minimum voting participation for validity) and the vote differential (margin needed to pass). After voting ends, successful proposals often enter a timelock queue, a mandatory delay that allows users to exit the system or prepare for changes before the proposal's instructions are executed.

The final stage is execution, where the approved transactions are autonomously carried out by the governance executor, often the Timelock contract itself. This step is permissionless; anyone can trigger the execution once the timelock delay expires. A failed execution, perhaps due to a revert or changed contract state, requires a new proposal. Post-execution, the changes are live on-chain. Monitoring tools like Tally or Boardroom provide transparency throughout this entire lifecycle, tracking proposal state and voter participation in real time.

The core of a structured proposal lifecycle is a smart contract system that defines the rules. This includes a proposal factory contract for creation, a voting contract with a specific token standard (like ERC-20 or ERC-721 for voting power), and a treasury or executor contract for automated payouts. You'll need a development environment like Hardhat or Foundry, and a solid understanding of Solidity or Vyper to implement state machines that track a proposal's progress from Draft to Active, Queued, Executed, or Canceled.

Off-chain infrastructure is equally important for a functional user experience. You must set up a graph indexer (using The Graph or Subsquid) to query proposal data efficiently. A backend service is required to listen for on-chain events, update databases, and trigger notifications. For secure and transparent voting, integrate a signature-based voting system like EIP-712 or Snapshot's off-chain signing, which requires setting up corresponding message verification in your contracts.

Key technical parameters must be defined in your contracts. This includes setting proposal thresholds (minimum token balance to submit), voting periods (e.g., 7 days in blocks or timestamps), quorum requirements (minimum participation percentage), and vote differentials (e.g., simple majority or 60% for). These values are highly context-dependent; a grants program might have a lower threshold but a higher quorum than a simple parameter change proposal.

To enable automatic execution, your system needs a secure execution layer. This often involves a timelock contract (like OpenZeppelin's TimelockController) that queues successful proposals for a mandatory delay before they can affect the protocol. The executor must be given specific permissions via access control (e.g., OpenZeppelin's AccessControl) to call functions in your protocol's core contracts, ensuring only authorized, passed proposals can make changes.

Finally, comprehensive testing is non-negotiable. Write unit tests for every state transition and integration tests that simulate full proposal cycles with multiple voters. Use forking tests against mainnet state to validate treasury payout logic. Tools like Tenderly or OpenZeppelin Defender can be used to monitor and automate the execution of queued proposals in production, completing the technical loop from creation to implementation.

At its core, a governance proposal is a state machine. It begins in a draft or pending state, where it is created but not yet open for voting. This allows proposers to finalize details and gather community feedback off-chain before committing to a formal on-chain vote. In systems like Compound's Governor Bravo or OpenZeppelin's Governor contracts, a proposal moves to an active state once it meets specific conditions, such as passing a proposal threshold or a designated timelock delay. This is when token holders can cast their votes.

The active voting period has a fixed duration, typically 3-7 days. During this phase, votes are tallied, and the proposal's success is determined by rules defined in the governance contract's voting module. These rules include the quorum (minimum voting power required) and the vote differential (e.g., simple majority or supermajority). If a proposal fails to meet quorum or the required vote margin by the deadline, it transitions to a defeated state. A successful proposal moves to a queued state, where it awaits execution, often after a mandatory timelock period for security review.

The queued and timelocked states are crucial security features. They prevent immediate execution of passed proposals, giving the community a final window to react to malicious or erroneous governance actions. After the timelock expires, the proposal enters an executable or succeeded state. An authorized executor (often any address) can then call the execute function, which runs the encoded transactions in the proposal. Finally, the proposal reaches a closed or executed state, completing its lifecycle. Some systems also include a canceled state for proposals revoked by the proposer or guardian.

Implementing these states requires careful smart contract design. For example, in an OpenZeppelin Governor contract, the state is determined by a public state() function that returns an enum like Pending, Active, Canceled, Defeated, Succeeded, Queued, Expired, or Executed. The logic within this function checks block numbers against proposal timestamps and the results of vote tallying. Developers must ensure state transitions are atomic and permissioned correctly to prevent attacks.

Real-world governance systems add complexity. In Compound, a proposal must be queued before execution, invoking a timelock contract. Uniswap's governance introduces an additional objection-period state for high-stakes upgrades. Aave uses a cross-chain governance system where proposals are created on Ethereum but executed on other networks via bridges, adding states for created, bridged, and executed_on_target. Mapping these states is essential for building user interfaces and bots that track proposal progress accurately.

When structuring a proposal lifecycle, key decisions include: the duration of each state, who can trigger state transitions, and how failures are handled. A well-defined state machine makes governance transparent, reduces ambiguity, and is a foundational element of any decentralized autonomous organization (DAO). Always audit the state transition logic, as flaws here can lead to proposals being stuck, executed prematurely, or manipulated.

A robust DAO governance lifecycle typically consists of three phases: a temperature check (or signaling), a formal on-chain voting period, and a timelock execution phase. The temperature check is an informal, off-chain vote—often conducted on platforms like Snapshot—that gauges community sentiment before committing gas fees for an on-chain proposal. This step filters out clearly unpopular ideas and allows for iterative discussion. A successful signal, often passing a simple majority or quorum threshold, then proceeds to a binding on-chain vote.

The on-chain voting period is implemented via a governance smart contract, such as OpenZeppelin's Governor contracts or Compound's GovernorBravo. Key parameters must be carefully set: the voting delay (time between proposal submission and vote start), the voting period (duration of the vote, commonly 3-7 days), and the proposal threshold (minimum token weight needed to submit). For example, a Uniswap-style governance contract might initialize with votingDelay = 1 block, votingPeriod = 6586 blocks (~1 day), and proposalThreshold = 1000000e18 (1 million UNI).

Here is a simplified code snippet for a Governor contract setup using OpenZeppelin, demonstrating parameter configuration:

solidityCopy
import "@openzeppelin/contracts/governance/Governor.sol";
contract MyGovernor is Governor {
    constructor() Governor("MyGovernor") {}
    function votingDelay() public pure override returns (uint256) { return 1; } // 1 block
    function votingPeriod() public pure override returns (uint256) { return 45818; } // ~7 days
    function quorum(uint256 blockNumber) public pure override returns (uint256) {
        return 100000e18; // 100,000 token quorum
    }
    // ... other required functions
}

This contract enforces a 7-day voting period after a 1-block delay.

Security and fairness considerations are paramount. A timelock contract should sit between the governor and the treasury, introducing a mandatory delay (e.g., 2 days) between a proposal's passage and its execution. This gives tokenholders a final window to exit protocols if they disagree with a passed proposal. Furthermore, consider vote delegation (like ERC-20Votes) to ensure voter flexibility and proposal lifecycle state management (Pending, Active, Defeated, Succeeded, Queued, Executed) to prevent reentrancy or replay attacks.

Best practices include using off-chain signature verification (EIP-712) for gasless voting on Snapshot during temperature checks, setting a quorum that is a percentage of circulating supply to prevent low-participation attacks, and implementing emergency proposal veto powers (e.g., a multisig or guardian) for critical security responses—though this reduces decentralization. Always audit governance contracts and consider battle-tested frameworks from OpenZeppelin, Compound, or Aave before writing custom logic.

The proposal lifecycle is a formalized sequence of states that a governance proposal transitions through, from ideation to execution. A typical lifecycle includes the following core stages: Draft, Active Voting, Queued, Executable, and Executed/Canceled. Each stage is governed by specific rules and timers defined in the protocol's smart contracts. Structuring this lifecycle correctly is critical for security, preventing race conditions, and ensuring voter intent is accurately translated into on-chain state changes. Protocols like Compound and Uniswap have established widely-adopted models for this process.

The lifecycle begins with proposal creation and a mandatory timelock period. When a proposal is submitted, it enters a draft or pending state. Most systems enforce a delay before voting can start, allowing the community to review the proposal's calldata. This is implemented using a timelock contract, which holds the proposal's execution payload. For example, OpenZeppelin's TimelockController is a common standard that queues transactions for a minimum delay, a pattern used by protocols like Aave to prevent malicious or erroneous proposals from executing immediately.

The voting period is the next critical phase. Proposals move to an active state where token holders cast votes, typically weighted by their stake. The voting logic must account for quorum requirements (minimum participation) and a passing threshold (e.g., a majority or supermajority). Smart contracts must securely track votes, often using a snapshot of token balances from a specific block to prevent manipulation. After the voting period ends, the contract checks if the proposal succeeded by verifying both quorum and the vote differential.

Successful proposals do not execute instantly. They enter a grace or queueing period. This second delay provides a final safety check, allowing users to react—such as exiting a protocol—if they disagree with the outcome. After this delay, the proposal state becomes Executable. Any authorized executor (often a multisig or the TimelockController itself) can then call the execute function, which retrieves the calldata from the timelock and performs the intended on-chain action, such as upgrading a contract or transferring treasury funds.

The lifecycle must also handle edge cases: cancellation and expiration. A proposal creator or admin should be able to cancel a proposal before it is executed, typically only during the voting or queued stages. Proposals should also have a maximum lifetime; if not executed within a set period (e.g., 30 days after becoming executable), they should expire and become invalid to prevent stale transactions from being executed unexpectedly. These mechanisms are essential for maintaining the system's operational hygiene and security.

Implementing this requires careful smart contract architecture. Key contracts include a Governor contract (like OpenZeppelin's Governor) that manages the state machine and voting, a Voting Token (often an ERC-20 or ERC-721), and a Timelock contract. The Governor must be configured with parameters for voting delay, voting period, quorum, proposal threshold, and timelock duration. Testing this lifecycle thoroughly with tools like Foundry or Hardhat, including simulations of malicious scenarios, is non-negotiable for securing decentralized governance.

Implementing this lifecycle requires selecting the right tooling. For on-chain execution, consider frameworks like OpenZeppelin Governor or Compound's Governor Bravo, which provide audited, modular contracts for voting and timelocks. For off-chain coordination and discussion, platforms like Snapshot for gasless voting, Discourse for forums, and Tally for proposal discovery are industry standards. The choice depends on your need for decentralization, gas costs, and voter accessibility.

Key metrics are essential for measuring governance health. Track proposal throughput (proposals per month), average voter participation rate, delegation activity, and execution success rate. Tools like DeepDAO and Boardroom provide analytics dashboards. Monitoring these helps identify bottlenecks—like low turnout signaling voter apathy or complex proposals failing due to poor communication—enabling iterative improvements to the process.

For next steps, start by formalizing your process in a governance charter or documentation. Publish it on your project's website or a dedicated docs site like GitBook. Then, run a test proposal on a testnet (e.g., Sepolia or Goerli) using a small amount of real governance tokens to simulate the full cycle. Finally, establish a clear feedback loop by creating a post-mortem template for all executed proposals to capture lessons learned and refine future iterations.