The DAO proposal lifecycle is the procedural backbone of decentralized governance, shaping how governance token voting rights are exercised in practice — the structured process through which ideas become community decisions and community decisions become on-chain execution. A well-designed proposal lifecycle balances accessibility with rigor, ensuring that any community member can propose governance changes while subjecting proposals to sufficient deliberation, review, and consensus-building before they affect protocol operations. The quality of the proposal lifecycle determines the quality of governance outcomes.
Anatomy of the Proposal Lifecycle
Phase 1: Informal Discussion
Every governance proposal begins as an idea shared within the community. The informal discussion phase occurs on governance forums (Discourse, Commonwealth), Discord channels, Twitter/X, and community calls. This phase serves to introduce the concept and gauge initial community reaction, identify potential supporters and opponents, surface technical, economic, or governance considerations that the proposer may not have considered, and refine the proposal based on community feedback before formal submission.
The governance significance of informal discussion cannot be overstated. Proposals that bypass community discussion and proceed directly to formal submission typically generate controversy, opposition, and lower-quality outcomes. The discussion phase provides the community intelligence that shapes proposals into forms that can achieve consensus.
Best Practice: Leading protocols like Aave and Uniswap have structured their governance forums with specific categories for initial discussion posts, enabling organized community deliberation. Clear formatting templates help proposers structure their ideas and provide the information the community needs for meaningful discussion.
Phase 2: Temperature Check / Signal Vote
After informal discussion, many protocols conduct a temperature check or signal vote to formally gauge community sentiment before investing the effort and resources required for a formal on-chain proposal. Temperature checks typically use Snapshot — an off-chain voting platform that uses token balance snapshots to weight votes without requiring gas fees.
Snapshot voting provides a low-cost mechanism for testing proposal viability. If a proposal fails to achieve support in the temperature check, the proposer can revise the proposal or abandon it without consuming on-chain governance resources.
Governance Design Considerations:
The temperature check serves as a governance filter — proposals that cannot achieve community support are filtered out before reaching the more resource-intensive formal governance stage. Key design parameters include the voting period duration (typically 3-7 days), the approval threshold for proceeding to formal proposal (varies by protocol), whether the temperature check is binding or advisory, and the minimum participation requirement for a valid temperature check.
Phase 3: Formal Proposal Drafting
Proposals that pass the temperature check enter formal drafting, where the proposer prepares a detailed governance proposal with specific implementation details. A well-structured formal proposal includes:
Summary: A concise description of what the proposal does and why it matters.
Motivation: The problem or opportunity that the proposal addresses, with supporting evidence, data, or analysis.
Specification: Exact technical details of the proposed change, including smart contract function calls, parameter values, asset amounts, and any code changes.
Risk Assessment: Analysis of the risks associated with the proposal, including potential adverse outcomes and mitigation measures.
Implementation Timeline: If the proposal involves multi-step implementation, the timeline and milestones for each step.
Audit/Review Status: For proposals involving smart contract changes, the status of security review and audit.
Phase 4: On-Chain Proposal Submission
Formal proposals are submitted on-chain through the protocol’s governance contracts. Submission typically requires a minimum token holding threshold — 25,000 UNI for Uniswap (~$200,000+ at typical prices), 65,000 COMP for Compound, or equivalent thresholds for other protocols. This threshold prevents spam proposals while creating a governance barrier that must be navigated.
The submission threshold creates governance dynamics — only significant token holders can submit proposals directly, requiring smaller holders to coordinate with larger holders or delegates to sponsor their proposals. Some protocols address this through delegation (delegates who have received delegation above the threshold can submit proposals) or through explicit proposal sponsorship mechanisms.
Technical Execution:
On-chain proposals specify exact smart contract calls that will be executed if the proposal passes. For Compound-style governance, the proposal includes arrays of target addresses, values (ETH to send), function signatures, and calldata. This specificity ensures that the community knows exactly what will be executed and can verify that the proposal’s code matches its stated intent.
Phase 5: Voting Period
Once submitted on-chain, the proposal enters a voting period during which token holders and delegates cast their votes. Voting typically offers three options: For, Against, and Abstain. Key voting parameters include:
Voting Delay: A period between proposal submission and the start of voting (typically 1-2 days) that gives the community time to review the proposal before voting begins. The voting delay also establishes the snapshot block — the block at which token balances are recorded for voting weight calculation.
Voting Period: The duration during which votes can be cast, typically 3-7 days. Longer voting periods provide more time for deliberation but delay governance execution.
Quorum Requirement: The minimum number of votes (typically measured in tokens rather than unique voters) required for the vote to be valid. Quorum prevents proposals from passing with minimal participation.
Approval Threshold: The percentage of votes in favor required for approval, typically 50% (simple majority) but sometimes higher for consequential decisions.
Phase 6: Timelock and Execution
Proposals that pass the voting phase enter a timelock period — a mandatory delay between approval and execution. The timelock serves critical governance functions: it gives the community time to review approved proposals before they take effect, provides a window for identifying errors, unintended consequences, or malicious elements, allows users who disagree with the change to exit the protocol before it takes effect, and creates an opportunity for governance to intervene if new information emerges.
Standard timelock periods range from 24 hours for minor changes to 48 hours for Compound and Uniswap, to 7+ days for some critical governance decisions. After the timelock expires, any address can trigger execution of the approved proposal.
Phase 7: Post-Execution Monitoring
The proposal lifecycle does not end at execution. Post-execution monitoring ensures that the implemented change functions as intended, identifies any adverse effects that require remediation, and informs future governance decisions through retrospective analysis.
Governance should establish monitoring frameworks for different proposal types — parameter changes should be monitored for their effects on protocol metrics, treasury allocations should be tracked against stated objectives, and code changes should be monitored for bugs or unexpected behavior.
Governance Process Optimization
Reducing Governance Friction
High governance friction — complex processes, long timelines, high participation thresholds — can prevent the DAO from responding to rapidly changing conditions. Optimization strategies include tiered governance paths that apply proportionate process to proposals based on their impact, delegated authority through Sub-DAO governance architectures that allows specialized committees to act within defined mandates without full governance votes, and emergency governance procedures for time-sensitive security or market events.
Improving Proposal Quality
Low proposal quality wastes governance attention and can result in harmful decisions. Quality improvement mechanisms include proposal templates that ensure consistent, comprehensive proposal documentation, proposal review processes where qualified community members provide technical, economic, or legal feedback before proposals proceed to vote, proposal simulation tools that allow the community to preview the effects of proposed parameter changes before voting, and governance facilitators who help proposers navigate the governance process and improve proposal quality.
Increasing Participation
Low governance participation undermines the legitimacy and quality of governance decisions. Participation improvement strategies include governance incentive programs that compensate participation, user-friendly governance interfaces that reduce the friction of voting, governance education programs that help token holders understand proposals and the governance process, governance summaries and analysis from delegates, community members, or dedicated governance services, and mobile-friendly voting interfaces that enable participation from any device.
Cross-Protocol Lifecycle Comparison
Aave Governance Process
Aave’s governance lifecycle demonstrates a structured approach with multiple governance stages. Aave Request for Comment (ARC) on the governance forum initiates discussion. Snapshot vote provides off-chain temperature check. Aave Improvement Proposal (AIP) formal submission follows with specific technical details. On-chain vote with tiered quorum requirements based on proposal type. And timelock execution with different delay periods for different governance levels.
Aave’s tiered governance system distinguishes between short timelock executor proposals (parameter adjustments with 24-hour delay) and long timelock executor proposals (protocol changes with 7-day delay), applying proportionate governance rigor to different decision types.
Uniswap Governance Process
Uniswap’s governance process follows a phased approach. Temperature Check on Snapshot requires 25,000 UNI delegation for posting. Consensus Check requires 50,000 UNI minimum and Snapshot voting. Governance Proposal requires on-chain submission with 25,000 UNI threshold, 7-day voting period, 40 million UNI quorum, and simple majority. Timelock execution follows with a 2-day delay.
Uniswap’s high quorum requirement (40 million UNI, approximately 4% of total supply) ensures that only proposals with broad support can pass, but it also means that governance participation must be actively mobilized for every proposal.
Conclusion
The DAO proposal lifecycle is the governance infrastructure through which decentralized organizations make decisions. Well-designed lifecycles balance accessibility with rigor, enable broad participation while maintaining decision quality, and provide appropriate safeguards at each stage. The progression from informal discussion through temperature check, formal proposal, on-chain vote, timelock, and execution creates a structured process that filters proposals through increasing levels of scrutiny and commitment. Protocols that invest in lifecycle optimization — improving proposal quality, reducing unnecessary friction, increasing participation, and adapting governance processes to different decision types — achieve governance outcomes that are more informed, more legitimate, and more effective. Platforms like Snapshot for off-chain voting and Tally for on-chain proposal management provide the infrastructure that supports modern proposal lifecycles.
Related Analysis: What Is a Governance Proposal | On-Chain vs. Off-Chain Governance | DAO Governance Attack Vectors | Quorum Threshold Design | DAO Governance Tracker Dashboard | DeFi Protocol Governance Mechanisms