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.
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)
The Radix DAO's framework names the same stages: a Request for Comment (RFC) for open discussion on its forum; a Temp Check, a non-binding poll weighted by staked $XRD; and a Request for Proposal (RFP) for the formal proposal. The structure drew 58 votes for and 1 against in a poll on the forum thread that proposed it. radix.wiki tracks the thresholds set for each stage on its card on the framework.
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 (sponsor thresholds, deposits, concurrency caps) that gate the entrance to a vote rather than its outcome. Passing then depends on two further gates:
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.
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)
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:
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). The hosted interface most large DAOs used to drive it was Tally (now Cactus).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.
A caper runs every stage on-chain, in two phases, and puts a market test where other DAOs put a timelock. A holder creates a proposal with two to five options, including a "Do nothing" option. Each option is either an action the treasury will perform – a PAYOUT, an INVEST into another caper's curve, a DIVEST back out of one, a METADATA rewrite of the caper's own token, or, on $CAPER alone, an UPGRADE of the platform's logic – or a DEBATE position that executes nothing. Members rank the options over a fixed voting period, and the leading option passes only if it clears a supermajority of the weight cast and is not "Do nothing".
Anyone can then trigger the winner. The trigger locks the caper's trailing average price as a baseline and opens a market window, and the action executes only if the average price over that window holds at or above the baseline. The window does the job a timelock does in a Governor DAO: members who object sell, and enough selling vetoes the action. A passed action that nobody executes within a fixed deadline lapses. There is no multisig hand-off, and every call after the vote is permissionless. The mechanics are on the linked governance pages, and the comparison with bond-and-challenge designs is on optimistic governance.