---
title: "The DAO proposal lifecycle"
url: "https://caper.network/wiki/dao-governance/concepts/voting/proposal-lifecycle"
updated: 2026-08-31
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# The DAO proposal lifecycle

|  |  |
| --- | --- |
| **Topic** | How an idea becomes a binding on-chain decision in a DAO |
| **Stages** | Discussion → Temperature check → Formal proposal → Voting period → Timelock → Execution |
| **Venues** | Forum (Discourse / [Commonwealth](/wiki/dao-governance/tooling/voting/commonwealth)) · [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) (off-chain) · Governor contract (on-chain) |
| **Key gates** | Proposal threshold · Quorum · Approval threshold · Timelock delay |
| **Related** | [What is a DAO?](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao), [Governance models](/wiki/dao-governance/concepts/fundamentals/dao-governance-models), [Governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) |

The **proposal lifecycle** is the sequence of stages a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) puts an idea through before it becomes a binding, executed decision. A mature DAO rarely jumps straight to an on-chain vote: an idea is discussed, informally polled, drafted into a formal proposal that must clear participation and approval thresholds, voted on for a fixed window, and — if it passes — held in a **[timelock](/wiki/dao-governance/concepts/voting/governance-timelocks)** before it executes. Each stage is a filter that trades a little speed for legitimacy and safety. This page walks the canonical flow used by large protocol DAOs such as [ENS](https://docs.ens.domains/dao/governance/process/), Uniswap, and [Compound](/wiki/daos/lending/compound-dao), which is built on the [OpenZeppelin Governor + Timelock](https://docs.openzeppelin.com/contracts/5.x/governance) contracts.

## 1. Discussion and temperature check

Most proposals begin as a forum post — typically on a [Discourse](https://www.discourse.org/) or [Commonwealth](/wiki/dao-governance/tooling/voting/commonwealth) forum — where the idea is debated, refined, and stress-tested by delegates and the wider community. Once a rough consensus forms, the author runs a **temperature check**: a low-stakes, gasless [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) poll that signals whether the idea has enough support to justify a formal vote. The temp check is non-binding, but it weeds out proposals that would fail and gives the author a mandate to invest in a formal draft. ENS formalizes this as an explicit stage before any executable proposal reaches its governor. ([a16z governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/))

## 2. The formal proposal and its thresholds

A formal proposal is a concrete, executable specification — for on-chain proposals, the exact contract calls to run. Submitting one is gated by a **proposal threshold**: a minimum amount of voting power the author must hold or have delegated to them, which stops the ballot from being spammed — one of a family of [proposal throttles and rate limits](/wiki/dao-governance/concepts/voting/proposal-throttles-and-rate-limits) (sponsor thresholds, deposits, concurrency caps) that gate the entrance to a vote rather than its outcome. Passing then depends on two further gates:

- **Quorum** — a minimum amount of voting power that must participate for the vote to count at all. ENS, for example, requires roughly 1% of the supply to turn out. Quorum stops a tiny, unrepresentative minority from pushing through a decision on a quiet day.
- **Approval threshold** — the share of participating votes that must be in favour, whether a simple majority or a higher super-majority for sensitive actions.

These parameters are the DAO's [governance model](/wiki/dao-governance/concepts/fundamentals/dao-governance-models) made concrete, and picking them is a balancing act: set quorum too high and nothing passes; too low and the DAO is easy to [capture](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks).

## 3. Voting period

Once active, the proposal is open for votes for a fixed window — commonly several days to a week (ENS runs a seven-day on-chain period). Votes may be cast off-chain on [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), where signed messages are tallied for free, or on-chain through a Governor contract, where each vote is a transaction counted against a voter's balance _snapshotted at the block the proposal was created_ — a deliberate defence that neutralizes tokens borrowed or bought after voting opens. Voting power itself is set by the governance model: one-token-one-vote, quadratic, conviction, or a delegated variant. ([Tally: on-chain vs off-chain voting](https://docs.tally.xyz/user-guides/governance-concepts/onchain-vs-offchain-voting/))

## 4. Timelock and execution

Passing the vote is not the same as executing. On-chain DAOs route a passed proposal through a **timelock** — a mandatory delay (ENS uses two days) between approval and execution. The delay is a safety valve: it gives members who disagree, or who spot a malicious payload, a window to react — to exit, to sound the alarm, or for a guardian to veto — before irreversible code runs. When the delay elapses, execution happens one of two ways:

- **Self-executing** — the Governor + Timelock contracts carry out the encoded calls trustlessly, with no discretion in the loop: nobody can alter or veto the payload at this point. Somebody must still send the transaction, though, and pay for it. `execute` is permissionless and caller-paid in both the OpenZeppelin and Compound designs, which makes the last step of the lifecycle a real cost assigned to nobody (see [who pays to execute a passed proposal](/wiki/dao-governance/concepts/analysis/proposal-execution-costs)). The hosted interface most large DAOs used to drive it was [Tally](/wiki/dao-governance/tooling/voting/tally) (now Cactus).
- **Multisig execution** — an off-chain Snapshot vote authorizes a small group of signers to carry out the result from a [Safe](/wiki/dao-governance/tooling/treasury/safe). Cheaper and more flexible, but it reintroduces trusted humans between the vote and the action.

## Why the stages exist

Every filter in the lifecycle defends against a specific failure mode: the temp check saves gas and attention; the proposal threshold blocks spam; quorum blocks decisions by an unrepresentative few; the block-height snapshot blocks flash-loan and rented-vote attacks; and the timelock blocks silent, instant execution of a malicious payload. Skipping stages is exactly how [governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) succeed — the Beanstalk exploit worked because a proposal could be flash-loaned into passing _and_ executed in a single transaction, with no snapshot and no timelock to break the chain.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) compresses the lifecycle into a single on-chain flow. A member creates a [proposal](/wiki/governance/proposals) with a title, a description, and at least two ranked options; an _executive_ proposal can carry real actions — a **PAYOUT** of treasury funds, an **INVEST** into another caper's curve, or a **METADATA** rewrite of the caper's own token metadata. Members then rank the options over a fixed [voting window](/wiki/governance/voting), after which a mandatory execution-delay window opens before anyone can [execute](/wiki/governance/execution) the winner — a timelock written into the contract rather than bolted on as a separate module. An option only becomes executable if it clears a built-in super-majority of the vote weight cast (a threshold of 1.5 divided by the number of options). There is no separate multisig hand-off: discussion can happen wherever the community likes, but the proposal, the vote, and the execution are one auditable object. The specifics live on the linked governance pages.

## References

- ENS Docs, [Governance Process](https://docs.ens.domains/dao/governance/process/) — a worked example of the full temp-check → draft → vote → timelock flow.
- OpenZeppelin, [Governance (Governor + Timelock)](https://docs.openzeppelin.com/contracts/5.x/governance) — the on-chain proposal-lifecycle contracts most DAOs use.
- a16z crypto, [DAO governance FAQ](https://a16zcrypto.com/posts/article/governance-faq/) — on thresholds, quorum, and why the stages exist.
- Tally, [On-chain vs off-chain voting](https://docs.tally.xyz/user-guides/governance-concepts/onchain-vs-offchain-voting/).