The proposal lifecycle is the sequence of stages 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 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, Uniswap, and Compound, which is built on the OpenZeppelin Governor + Timelock contracts.

1. Discussion and temperature check

Most proposals begin as a forum post — typically on a Discourse or 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 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)

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. 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 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.

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, 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)

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 automatically and trustlessly, with no human in the loop. This is the on-chain ideal, and the hosted interface most large DAOs used to drive it was Tally (now Cactus).
• Multisig execution — an off-chain Snapshot vote authorizes a small group of signers to carry out the result from a 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 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 compresses the lifecycle into a single on-chain flow. A member creates a proposal 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 VOTE cast in another caper's proposal. Members then rank the options over a fixed voting window, after which a mandatory execution-delay window opens before anyone can execute 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 — a worked example of the full temp-check → draft → vote → timelock flow.
• OpenZeppelin, Governance (Governor + Timelock) — the on-chain proposal-lifecycle contracts most DAOs use.
• a16z crypto, DAO governance FAQ — on thresholds, quorum, and why the stages exist.
• Tally, On-chain vs off-chain voting.