How to Design a Proposal Lifecycle Process

A proposal lifecycle is the formal process a community uses to submit, review, vote on, and implement changes to a protocol. In DAOs like Compound or Uniswap, this process is encoded in smart contracts, making it transparent and tamper-proof. A well-designed lifecycle balances efficiency with thorough deliberation, ensuring that only high-quality, widely-supported proposals are executed. Key phases typically include ideation, temperature checks, formal submission, on-chain voting, a timelock delay, and finally, execution. Each stage serves a distinct purpose, from gauging sentiment to preventing malicious code from being deployed immediately.

The lifecycle begins with an ideation and discussion phase, often conducted off-chain in forums like the Uniswap Governance Forum or Discord. Here, community members refine ideas, solicit feedback, and build consensus before incurring the gas costs of an on-chain proposal. A common next step is a temperature check or snapshot vote, a lightweight, off-chain signal vote using tools like Snapshot. This validates that there is sufficient community interest to proceed to a formal, binding on-chain proposal. This staged approach prevents governance fatigue and ensures only serious proposals consume on-chain resources.

The core of the process is the on-chain voting phase. A proposal, containing the calldata for the desired actions, is submitted to the governance contract (e.g., Compound's Governor Bravo or OpenZeppelin's Governor). Token holders then cast votes, with their voting power typically proportional to their token balance. Critical design choices here include the voting period length (e.g., 3-7 days), quorum requirements (the minimum participation needed for validity), and vote thresholds (e.g., a simple majority or a 4% supply requirement for passage). These parameters directly impact security and agility.

Following a successful vote, a timelock period is a critical security feature. The approved proposal is queued in a Timelock contract (like Compound's Timelock) for a set duration—often 2 days. This delay provides a final window for the community to review the executed code and, if a critical bug or malicious action is discovered, to prepare a veto or cancel transaction. Only after this delay expires can the proposal be executed. This mechanism is a defense against governance attacks and bugs in proposal logic.

Designing this lifecycle requires balancing trade-offs. A short voting period and low quorum enable rapid iteration but increase the risk of low-participation attacks. A long timelock enhances security but slows protocol upgrades. Successful DAOs often iterate on their lifecycle design; for example, Uniswap moved from a simple governance model to a more complex one involving a Governance Guardian and delegated voting to improve security and efficiency. The lifecycle must be tailored to the specific risk profile and needs of the protocol it governs.

A proposal lifecycle process is defined by its governance framework. You must first decide on the core primitives: who can propose (proposer), who can vote (voter), and the voting mechanism itself. Common frameworks include token-weighted voting (e.g., Compound, Uniswap), multi-signature execution (e.g., Safe{Wallet}), or reputation-based systems (e.g., Optimism's Citizen House). The choice dictates the technical implementation, from a simple mapping(address => uint256) votes to complex sybil-resistant identity proofs.

The technical stack is a critical prerequisite. For on-chain governance, you need a smart contract environment like Ethereum, a Layer 2 (Arbitrum, Optimism), or an app-chain (Cosmos SDK). Your contracts must handle proposal submission, voting, timelocks, and execution. For off-chain signaling (like Snapshot), you need to integrate with a compatible wallet provider and define the data source for voter eligibility, often a snapshot of token holdings at a specific block number. Assume you have a development environment (Foundry, Hardhat) and basic knowledge of a smart contract language like Solidity or Vyper.

Define your core assumptions clearly. What is the minimum proposal deposit? What is the voting period duration (e.g., 3-7 days is standard)? What are the quorum and approval thresholds? For example, a common assumption is a 4% quorum and a 50% majority for approval. These parameters are not arbitrary; they balance security against participation. You must also assume the existence of a trusted oracle or price feed if your proposal involves treasury movements or parameter updates based on external data.

Finally, consider the lifecycle stages. A typical flow is: Draft → Active Voting → Timelock → Execution → Completion. Each stage requires smart contract functions and clear user interfaces. The Timelock stage is a security assumption, providing a delay between vote passage and execution to allow for review and emergency cancellation. Your design must account for failed proposals, cancelled proposals, and the handling of proposal deposits, whether they are slashed or returned.

A well-defined proposal lifecycle begins with structured ideation. This phase is not about formal voting, but about fostering open discussion, refining ideas, and building consensus. The goal is to surface high-quality proposals that align with the protocol's goals and have clear community support. Key platforms for this stage include discourse forums, community calls, and dedicated channels on Discord or Telegram. Establishing clear guidelines for these spaces—such as required template formats and discussion timelines—sets expectations and improves the quality of discourse.

The core mechanism of this stage is the temperature check, a non-binding signal vote. Tools like Snapshot are commonly used to gauge sentiment on a proposal's core idea without committing on-chain resources. A successful temperature check should answer specific questions: Is there appetite for this change? Are the proposed parameters reasonable? What are the major objections? This step filters out proposals lacking support and provides critical feedback for iteration. It's crucial to define clear passing thresholds (e.g., a minimum quorum and majority) for these checks to have meaningful outcomes.

Designing an effective process requires concrete rules. Specify a minimum discussion period (e.g., 7 days) on the forum before a temperature check can be initiated. Require proposers to submit a structured template including: Problem Statement, Proposed Solution, Technical Specification (if applicable), and Financial Implications. This ensures all necessary context is available for community evaluation. The process should also define who can move a proposal from ideation to the next stage, typically the proposer or a designated core contributor, once temperature check thresholds are met.

Learn from established protocols. Uniswap's governance process mandates a 7-day forum discussion followed by a 5-day Snapshot temperature check, requiring a 25k UNI quorum and 50k yes-votes to pass. Compound uses a similar model, where a temperature check requires 50k COMP votes in favor. These real-world examples provide a benchmark for quorum and majority settings. Analyzing forums like the Uniswap Governance Forum offers insights into how effective discussion shapes proposals before they reach a formal vote.

The final output of Stage 1 is a refined proposal draft and a verified community signal. This foundation reduces governance fatigue by preventing poorly conceived proposals from advancing to costly on-chain voting. It also builds legitimacy; proposals that undergo rigorous public scrutiny are more likely to succeed. By investing in a robust ideation phase, DAOs and protocol communities can improve decision quality, increase participation, and ensure governance resources are allocated to the most impactful ideas.

A formal proposal is the definitive, on-chain record of a governance action. It moves beyond the conceptual discussion of a temperature check into a binding executable. For most DAOs using platforms like Snapshot or Tally, this involves creating a structured proposal with a clear title, detailed description, and the exact smart contract call that will be executed upon approval. The description must comprehensively outline the proposal's rationale, technical implementation, timeline, budget, and any associated risks. This document becomes the single source of truth for voters.

The core of the proposal is the calldata—the encoded function call to the protocol's governance contract. For example, a proposal to update a Uniswap fee parameter would specify the target contract address (0x...), the function selector (setFeeProtocol), and the arguments (newFeeNumerator). This requires collaboration between proposers and developers to ensure the code is correct and secure. Tools like Tenderly or OpenZeppelin Defender are often used to simulate the transaction before submission to prevent unintended consequences.

Best practices for proposal design include establishing a mandatory review period. Many DAOs require proposals to be published in a forum or dedicated channel (e.g., a Discord #proposal-review channel) for at least 48-72 hours before the on-chain vote begins. This allows for final community scrutiny, technical audits, and legal checks. The submission process itself typically involves paying a proposal deposit (in the DAO's native token) to prevent spam, which is refunded only if the proposal passes a minimum vote threshold.

A well-structured proposal lifecycle process defines clear acceptance criteria for moving from Stage 1 to Stage 2. These criteria might include achieving a minimum level of support in the temperature check (e.g., 50,000 FOR votes), securing commitments from necessary technical teams, and completing a draft of the full specification. Documenting this process in the DAO's governance framework (like a Governance Handbook on GitHub) reduces ambiguity and sets consistent expectations for all contributors, leading to higher-quality submissions and more efficient governance.

The on-chain voting stage is where a governance proposal's fate is decided by the token-holder community. This process is governed by a smart contract that enforces predefined rules for voting power calculation, quorum requirements, and vote aggregation. Unlike informal signaling, an on-chain vote creates a cryptographically verifiable record of community consensus that can trigger automatic execution of the proposed actions, such as a treasury transfer or a parameter change in a protocol.

Designing the voting mechanism involves several key parameters. The voting period (e.g., 3-7 days) must balance speed with sufficient time for deliberation. Vote weighting is typically based on token ownership, often with mechanisms like token-weighted or delegated voting (e.g., Compound, Uniswap). Some systems implement vote-escrow models where locking tokens for longer periods grants greater voting power. It's critical to decide if votes are binary (For/Against) or include options like Abstain or multiple choices.

Quorum is a minimum threshold of total voting power that must participate for a vote to be valid. This prevents a small, unrepresentative group from passing proposals. For example, a DAO with 10M governance tokens might set a quorum of 4M tokens (40%). A proposal must first meet this participation threshold and then achieve a majority (e.g., >50% For) to pass. Setting quorum too high can lead to voter apathy and governance paralysis, while setting it too low risks governance attacks.

Technical implementation often uses a voting contract with functions like propose(), castVote(), and queue(). After a successful vote, there is typically a timelock period before execution. This delay allows users to react to a passed proposal they disagree with, providing a final safety net. The entire lifecycle—from proposal creation to execution—should be transparent and verifiable on-chain, with events emitted at each state change for easy tracking by indexers and frontends.

After a proposal passes its voting period, it enters the execution stage. This is not an automatic process; it requires a final, explicit transaction to be submitted. This transaction is typically called execute() or a similar function in the governance contract. The entity submitting this transaction can be the original proposer, any delegate, or a dedicated executor role, depending on the DAO's configuration. This separation between voting and execution is a critical security feature, preventing malicious proposals from being enacted the moment they pass.

The core security mechanism of this stage is the timelock. A timelock is a smart contract that holds and delays the execution of transactions. When a proposal passes, its encoded actions are not sent directly to their target contracts. Instead, they are queued in the timelock contract for a predefined period. This delay, often 24-72 hours, creates a crucial security window. It allows vigilant token holders and core contributors to analyze the final, executable code of the proposal one last time before any state changes occur on-chain.

During the timelock delay, several defensive actions are possible. If a critical vulnerability or malicious intent is discovered, a cancel transaction can be submitted to the timelock to halt the proposal permanently. Some systems, like OpenZeppelin's Governor, allow proposals to be canceled by the proposer or a guardian address before execution. This window is the last line of defense, enabling the community to prevent the execution of proposals that were approved based on flawed information or that contain hidden exploits.

For developers, integrating with a timelock requires specific patterns. Target contracts must have their privileged functions (e.g., mintTokens, transferTreasuryFunds) owned by the timelock address, not an externally owned account (EOA). Proposals are built by encoding function calls to these target contracts. The governance contract, upon a successful vote, schedules these calls in the timelock. A common implementation uses OpenZeppelin's TimelockController, which manages a queue of operations with a minimum delay.

Here is a simplified view of the execution flow using a pseudocode pattern:

codeCopy
// 1. Proposal passes vote
GovernanceContract.vote(proposalId, support);

// 2. Queue the proposal in the timelock (initiates delay)
TimelockContract.schedule(
    targetAddress,
    value,
    calldataPayload,
    predecessor,
    salt,
    delay
);

// 3. After delay passes, execute the proposal
TimelockContract.execute(
    targetAddress,
    value,
    calldataPayload,
    predecessor,
    salt
);

The calldataPayload contains the encoded function call that will ultimately change state on the targetAddress.

Best practices for this stage include setting a meaningful delay (long enough for review, short enough for agility), publicly monitoring the timelock queue (using tools like Tally or Etherscan), and ensuring a clear process for emergency cancellations. The execution and timelock stage transforms a social consensus into a secure, verifiable on-chain action, making it the cornerstone of accountable decentralized governance.

The Post-Implementation Review is a critical governance stage often overlooked. Its purpose is to close the feedback loop by systematically evaluating a proposal's real-world effects against its initial objectives. This stage transforms a one-off decision into a learning opportunity for the entire DAO. Key activities include gathering on-chain data, analyzing key performance indicators (KPIs), and soliciting qualitative feedback from the community. Without this review, DAOs cannot measure success or learn from failures, leading to repeated mistakes and inefficient resource allocation.

Effective review requires establishing clear success metrics before the proposal passes. These could be quantitative, like a target increase in Total Value Locked (TVL) or a reduction in gas fees, or qualitative, like improved community sentiment. Post-execution, use tools like Dune Analytics or The Graph to query on-chain data and compare results. For example, after a liquidity mining program passes, analyze whether it attracted sustainable liquidity or merely incentivized mercenary capital. This data-driven analysis provides an objective basis for evaluation.

The final step is documentation and process refinement. Publish a transparent Post-Mortem Report summarizing the proposal's goals, execution data, community feedback, and lessons learned. This report should be stored in an accessible repository like the DAO's forum or documentation hub. Use these insights to update the governance framework itself—perhaps adjusting quorum requirements, refining template structures, or creating new guidelines for similar proposals. This continuous improvement cycle, formalized through Governance Process Iteration (GPI), is what separates mature, resilient DAOs from experimental ones.