The proposal lifecycle is the …ed on for a fixed window, and —– if it passes —– held in a timelock (/wiki/da…oposals begin as a forum post —– typically on a Discourse (ht…g/voting/commonwealth) forum —– where the idea is debated, re…ete, executable specification —– for on-chain proposals, the e…the ballot from being spammed —– one of a family of proposal … two further gates: - Quorum —– a minimum amount of voting po…et day. - Approval threshold —– the share of participating vo… for votes for a fixed window —– commonly several days to a we…lock the proposal was created —– a deliberate defence that neu…d proposal through a timelock —– a mandatory delay (ENS uses t…us payload, a window to react —– to exit, to sound the alarm, or for a guardian to veto —– before irreversible code runs…f two ways: - Self-executing —– the Governor + Timelock contr…actus). - Multisig execution —– an off-chain Snapshot vote au…-governance-attacks) succeed —– the Beanstalk exploit worked …ins/dao/governance/process/) —– a worked example of the full …om/contracts/5.x/governance) —– the on-chain proposal-lifecyc…sts/article/governance-faq/) —– on thresholds, quorum, and wh…onchain-vs-offchain-voting/) .

The proposal lifecycle is the … cast and is not "Do nothing".Anyone can then trigger the wi…onchain-vs-offchain-voting/) .

The proposal lifecycle is the …s/article/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 (https://radixtalk.com/t/proposed-initial-governance-structure-for-the-radixdlt-dao-duna-rdd/2127) . radix.wiki tracks the thresholds set for each stage on its card on the framework (https://radix.wiki/ideas/dao-proposal-voting-framework) . 2. The formal proposal and its…onchain-vs-offchain-voting/) .

The proposal lifecycle is the …foundations/what-is-a-caper) compresses the lifecycle into a single on-chain flow. A membruns every stage on-chain, in two phases, and puts a market test where other DAOs put a timelock. A holder creates a proposal (/wiki/governance/proposals) with a title, a descritwo to five options, and at least two ranked options; an executive proposal can carry real actions — a PAYOUT of treasury fundsincluding a "Do nothing" option. Each option is either an action the treasury will perform – a PAYOUT, an INVEST into another caper's curve, ora DIVEST back out of one, a METADATA rewrite of the caper's own token metadata, or, on $CAPER alone, an UPGRADE of the platform's logic – or a DEBATE position that executes nothing. Members then rank the options over a fixed voting windowperiod (/wiki/governance/voting) , after which a mandatory execution-delay window opens before anyone cand 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 (/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 voonly 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 weight cast (a threshold of 1.5 divided by the number of options)ithin a fixed deadline lapses. 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, 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 (/wiki/dao-governance/concepts/voting/optimistic-governance) . References - ENS Docs, Go…onchain-vs-offchain-voting/) .

The proposal lifecycle is the …o another caper's curve, or a VOTE cast in anoMETADATA rewrite of ther caper's proposalown token metadata. Members then rank the option…onchain-vs-offchain-voting/) .

The proposal lifecycle is the … 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 …onchain-vs-offchain-voting/) .

The proposal lifecycle is the …s carry out the encoded calls automatically and trustlessly, with no human in the loop. This is the on-chain ideal, and ttrustlessly, 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…onchain-vs-offchain-voting/) .

Topic How an idea becomes a bi…ion Venues Forum (Discourse / Commonwealth (/wiki/dao-governance/tooling/voting/commonwealth) ) · Snapshot (/wiki/dao-gover…curity-and-governance-attacks)

The proposal lifecycle is the …ap, and Compound (/wiki/daos/organizations/lending/compound-dao) , which …tps://www.discourse.org/) or Commonwealth (/wiki/dao-governance/tooling/voting/commonwealth) forum — where the idea is deba…onchain-vs-offchain-voting/) .

Topic How an idea becomes a bi…wealth) · Snapshot (/wiki/daos-governance/tooling/voting/snapshot) (of…ted What is a DAO? (/wiki/daos-governance/concepts/fundamentals/what-is… Governance models (/wiki/daos-governance/concepts/fundamentals/dao-gov… Governance attacks (/wiki/daos-governance/concepts/analysis/dao-security-and-governance-attacks)

The proposal lifecycle is the …ce of stages a DAO (/wiki/daos-governance/concepts/fundamentals/what-is…nd — if it passes — held in a timelock (/wiki/dao-governance/concepts/voting/governance-timelocks) before it executes. Each stage…, gasless Snapshot (/wiki/daos-governance/tooling/voting/snapshot) pol…s governance model (/wiki/daos-governance/concepts/fundamentals/dao-gov…is easy to capture (/wiki/daos-governance/concepts/analysis/dao-securit…-chain on Snapshot (/wiki/daos-governance/tooling/voting/snapshot) , wh…drive it was Tally (/wiki/daos-governance/tooling/voting/tally) (now C…result from a Safe (/wiki/daos-governance/tooling/treasury/safe) . Chea… governance attacks (/wiki/daos-governance/concepts/analysis/dao-securit…onchain-vs-offchain-voting/) .

Topic How an idea becomes a bi…wealth) · Snapshot (/wiki/daos/tooling/voting/snapshot) (off-chain) · Gover…ted What is a DAO? (/wiki/daos/concepts/fundamentals/what-is-a-dao) , Governance models (/wiki/daos/concepts/fundamentals/dao-governance-models) , Governance attacks (/wiki/daos/concepts/analysis/dao-security-and-governance-attacks)

The proposal lifecycle is the …ce of stages a DAO (/wiki/daos/concepts/fundamentals/what-is-a-dao) puts an idea t…swap, and Compound (/wiki/dao/ecosystems/organizations/lending/compound-dao) , which is buil…, gasless Snapshot (/wiki/daos/tooling/voting/snapshot) poll that signals w…s governance model (/wiki/daos/concepts/fundamentals/dao-governance-models) made c…is easy to capture (/wiki/daos/concepts/analysis/dao-security-and-governance-at…-chain on Snapshot (/wiki/daos/tooling/voting/snapshot) , where signed messa…drive it was Tally (/wiki/daos/tooling/voting/tally) (now Cactus). - Multi…result from a Safe (/wiki/daos/tooling/treasury/safe) . Cheaper and more flexi… governance attacks (/wiki/daos/concepts/analysis/dao-security-and-governance-at…onchain-vs-offchain-voting/) .

The proposal lifecycle is the …ance/process/) , Uniswap, and Compound (/wiki/dao/ecosystem/compound-dao) , which is built on the OpenZ…onchain-vs-offchain-voting/) .

The proposal lifecycle is the …op. This is the on-chain ideal, and the hosted interface most large DAOs used to drive it was Tally (/wiki/dao/tooling/tally) (now Cactus). - Multisig execution — an o…onchain-vs-offchain-voting/) .

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) · Snapshot (/wiki/dao/tooling/snapshot) (off-chain) · Governor contract (on-chain) Key gates Proposal threshold · Quorum · Approval threshold · Timelock delay Related What is a DAO? (/wiki/dao/concepts/what-is-a-dao) , Governance models (/wiki/dao/concepts/dao-governance-models) , Governance attacks (/wiki/dao/concepts/dao-security-and-governance-attacks)

The proposal lifecycle is the sequence of stages a DAO (/wiki/dao/concepts/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 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, 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 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/tooling/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. 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/concepts/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/concepts/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/tooling/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 automatically and trustlessly, with no human in the loop. This is the on-chain ideal. - Multisig execution — an off-chain Snapshot vote authorizes a small group of signers to carry out the result from a Safe (/wiki/dao/tooling/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/concepts/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 VOTE cast in another caper's proposal. 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/) .