A proposal is a slate of options a caper votes on, exactly one of which its treasury will then perform – unless its own market objects first. It has to survive two independent tests. The ballot decides what the caper wants: holders rank the options, a permissionless crank folds the tally, and the leading option passes only if it clears a 1.5 / option_count supermajority of cast weight and is not the "Do nothing" entry. Then the market decides whether it happens: someone triggers the winner, which locks the caper's trailing average price as a baseline and opens the market window, and the action executes only if the average price over that window is at or above the baseline. Holding through the window is consent; selling is the objection.
This page has described three different mechanisms in a month, so the dates matter. Until 26 August 2026 a caper decided by ranked ballot alone. From 26 to 28 August 2026 the ballots were removed entirely and a proposal named one action that passed on price – the model this page described, accurately, for those three days. On 29 August 2026 voting was reinstated in front of the optimistic phase, and the price test was tightened from the spot price at the moment of the crank to the TWAP over the window itself. On 7 September 2026 that deployment was replaced by one with the same two phases and a different measurement underneath the second: an exact price-time integral in place of a ring of per-trade samples, and a shorter trailing baseline. Everything below describes that fourth deployment, read off the live CaperMain. Where any Caper material disagrees, the deployed contract is the authority.
A slate of options, not a single action
A proposal carries between two and five options, and the contract asserts the shape rather than trusting the app: at least one must be a no-op – the "Do nothing" entry – and at least one must be an answer other than the no-op, so a rejection is always on the ballot and something always stands against it. Voters submit a full permutation: every option ranked exactly once. On the wider taxonomy of why a governance system offers a fixed menu of actions rather than arbitrary calldata, see typed vs arbitrary proposal execution, and on ranked methods generally, ranked and alternative ballot methods.
Each option that executes is typed at creation as one of five kinds, and a sixth kind executes nothing at all. A single slate may mix them – the ballot picks one, and only the winner is ever executed.
- PAYOUT – transfers a chosen currency and amount from the treasury to a named recipient account. The recipient is stored at creation and dereferenced at execution, so the proposal cannot be redirected after the fact.
- INVEST – withdraws XRD from this treasury, buys a target caper's token on its bonding curve, and deposits the tokens straight back into this treasury. The XRD never reaches the worktop, so no part of it can be skimmed in transit.
- DIVEST – the same trade run backwards: withdraws an amount of a target caper's token this treasury already holds, sells it into that caper's curve, and banks the XRD. It stores the identical fields to INVEST and differs only in direction.
- METADATA – rewrites the mutable metadata of this caper's own token: description, icon, or information URL. At least one field must be set, and the contract pins the target to this caper's token address, so an admin badge shared with sibling resources cannot be aimed at one of them.
- UPGRADE – nominates a candidate logic component and, in a second step, activates it. Reserved to the $CAPER caper, because one activation changes the logic every caper on the platform runs; the contract rejects an UPGRADE raised anywhere else, and checks that the candidate is genuinely a
CaperMaincomponent before it will store it. - DEBATE – executes nothing, and is the one kind that is not an action. A position in an argument: ranked with the rest, able to win the count outright, and terminal there. The contract asserts that a debate option carries no execution fields at all, and refuses to trigger one if it wins, so it never opens a market window and never incurs an execution fee. Added to the deployed logic on 5 September 2026; a slate of debate positions plus the no-op is valid, which means a passing proposal no longer guarantees that anything happens.
The discriminants are 0 PAYOUT, 1 INVEST, 3 UPGRADE, 4 DIVEST, 5 METADATA and 6 DEBATE, and the gap at 2 is the point rather than an accident. Kind 2 was VOTE, which let one caper cast its treasury's ballot inside another; it belonged to the pre-August escrow system and did not return with the ballots. The number was retired rather than recycled, so the whitelist that guards creation accepts 0 | 1 | 3 | 4 | 5 | 6 and names VOTE in its abort message – a proposal built against the old ABI fails at creation instead of storing an option nothing can execute. The per-kind numbering is set out in paying someone from a caper.
Every executable option is validated at creation against what execution will later require — a PAYOUT needs a recipient, an INVEST needs a resolvable target and an amount above the curve's own buy minimum, a DIVEST needs a positive amount, a METADATA payload must decode and set something. The fee is banked irrevocably and the options frozen, so an unchecked field would not produce a failed proposal but a poisoned one: it would settle as passed and then abort on every execution attempt, forever, with the treasury's fee already spent. Each guard is spelled out step by step in Execution.
The two phases, and what settles each
Phase one: the tally. Voting opens at creation and closes when the voting period elapses. Each ballot is weighted (t·v)/(V·T), with T – the circulating supply – frozen once at creation so ordinary trading cannot move the denominator under a vote already cast, and each ballot's stake clamped to min(held at cast, balance now) so a voter cannot cast and then sell out from under their own weight. Once the period closes, anyone can crank crystallize_ballots to fold the ballots in chunks, and settle_proposal to freeze the verdict. The threshold is a share of cast weight, not of the electorate: 1.5 / option_count, so two options need 75% and five need 30%. A leading option that is the no-op fails by rule even if it clears the bar. Details in Voting.
Phase two: the window. A legislative pass executes nothing on its own. Someone must call the trigger, which prices the execution fee off the winning action at that moment's spot, locks a baseline – the time-weighted average price of the caper's token over the trailing baseline window, read from the state tier's own price-time integral – and opens the market window. Nothing governance-specific happens during it. Members trade, or do not. When it closes, any account – member or not – can call resolve once:
- Window TWAP at or above the baseline → the proposal executes. The market was told what the caper had decided to do and did not sell.
- Window TWAP below the baseline → it fails. Enough holders sold, across a window in which the winning action was public, to hold the average under where the token had been trading. That is the veto.
The comparison is against the average over the window itself, not the price at the instant somebody happens to crank the resolve. That is deliberate: a spot test rewards whoever times the call, and a single wash trade in the resolving block could carry it. Anchoring on the window's own integral means every second of the window counts, and a late crank reads the same verdict an instant one does.
Settlement is once-only and irreversible, and execution is a separate call anyone can likewise make. Both are permissionless work, and since 11 September 2026 whoever does it pays their own network fee: the treasury subsidy that used to cover up to 5 XRD a call was removed outright, because it met the first 5 XRD of the caller's whole transaction rather than of the crank itself (who pays to settle). Execution also carries a clock now – a passed action must be performed within seven days of its resolution or it lapses.
Two consequences are worth stating plainly. First, an apathetic market ratifies: silence in phase two resolves as consent, which is the deliberate inverse of a quorum and the standard objection to every optimistic system – what the reinstated ballot adds is that silence in phase one is not enough, because a proposal on which nobody votes has no cast weight to clear the threshold with. Second, the market's objection costs the objector real money at a real price rather than a signature, and it is the same act as leaving, so a member who would have exited over a proposal blocks it on the way out. The comparison with quorum-based designs is set out in quorum and threshold design, and the exit itself in leaving a caper.
What it costs, and who may propose
Caper has no supply-percentage proposal threshold. Two conditions gate a proposal:
- Hold at least one governance token of the caper you are proposing to. The contract checks a proof for an amount of at least 1 and aborts the whole transaction if it fails, so any member can propose regardless of the size of their position.
- Pay the proposal fee: a flat 500 XRD at creation. Send more and the remainder comes back in the same transaction.
That fee is deposited into that caper's own treasury rather than burned or escrowed. It is a fee, not a refundable bond: it does not come back if the proposal fails, which is what makes it a spam gate. Until 11 September 2026 it doubled as a settlement-gas allowance the treasury drew on to reimburse whoever cranked the settle path; that subsidy is gone, and the fee is now purely the spam gate.
The percentage leg moved. It is no longer part of the cost of raising a proposal – it is an execution fee of 10% of the winning action's XRD-equivalent value, due at the trigger and priced at the relevant curve's trailing time-weighted average rather than at spot – the same read that locks the pass baseline, so a dump inside the triggering transaction cannot set the basis it is charged on. A PAYOUT in a non-XRD currency converts at the issuing caper's trailing average, a DIVEST at the target's, an INVEST is XRD already, and METADATA and UPGRADE move no value, so their basis is zero and the trigger is free. A DEBATE winner is never triggered at all, so it never reaches this fee: the flat creation fee is the entire cost of putting a question to the caper. Who pays it is decided by the ballot's second question – proposer or treasury, settled by plain weight majority, a tie going to the treasury. Treasury-pays nets to a waiver, because the fee's sink is that same treasury, so a treasury-pays trigger costs the caller nothing and stays fully permissionless. The practical effect is unchanged in spirit and different in incidence: a proposal to move a large fraction of a treasury still costs proportionally more, but it costs that only if it wins, and only if the electorate votes to charge its proposer. See the FAQ on protocol fees.
None of these figures is a constant of the protocol, and none is an admin toggle either. The flat fee, the execution rate, the vote fee, the voting period, the market window and the trailing baseline window are all fields set when the shared logic component is initialised, with no setter on its public surface. Changing any of them means swapping the logic tier — which is an UPGRADE proposal on $CAPER, settled by the same two tests as everything else.
One caper cannot carry proposals at all: $XRD, which holds native XRD and has no bonding curve. Baseline and window TWAP would both read zero, every legislative pass would execute unconditionally, and governance would be an open drain on the treasury. The contract rejects the proposal outright rather than pretending to price it.
Where this sits in the wider pattern
Two families of DAO governance meet here, and since August 2026 a caper is a hybrid of them rather than a pure instance of either. From optimistic governance comes the second phase's shape: a decision is assumed to stand and the work is in objecting. What those systems leave open is what objecting costs, and it is rarely money. Aragon's Optimistic Token Voting plugin permissions who may propose and leaves the veto with token holders, carried free of charge once objections reach minVetoRatio of supply; UMA's oSnap put it behind a challenger's bond instead, and UMA retired oSnap on 15 December 2025, so that route executes nothing today. Caper answers it with the market-decides tradition that futarchy belongs to and that MetaDAO runs in production: the objection is a trade, so the right to object is exactly the right to hold, and its cost is the price. What phase one restores is the conventional half – token-weighted ranked voting behind a supermajority, which is what most DAOs run and all a caper ran before August.
The differences are worth being precise about. Futarchy asks a conditional question – what would this token be worth if the proposal passed, against if it failed – and needs two conditional markets to answer it. A caper asks a simpler and cheaper one against a single spot market: after the electorate has said what it wants, is the token still worth what it was worth before? That buys a mechanism with no extra markets to bootstrap and no liquidity to fragment, at the cost of a coarser signal – a price that fell for unrelated reasons during the window blocks a decided proposal, and a proposal too small to move the price is ratified on indifference rather than on assent. Running the ballot first narrows how often that coarseness matters, because the market is only ever asked about one concrete winner.
The market window plays the role a governance timelock plays elsewhere, with one difference: a timelock gives holders time to leave after a decision is final, whereas here leaving during the window is what makes it final or not. For the shape this all takes in a conventional DAO – forum thread, temperature check, formal vote, timelock, execution – see the DAO proposal lifecycle.
The proposal lifecycle
A proposal moves through two phases and six steps. First the vote legislates: 2–5 ranked options, ranked ballots weighted (t·v)/(V·T), and a Borda leader that must clear 1.5/N of cast weight. Then the market ratifies: the trigger locks a seven-day TWAP baseline and opens a market window, and the action runs only if the average price over that window is at or above the baseline.