---
title: "Proposals"
url: "https://caper.network/wiki/governance/proposals"
updated: 2026-08-28
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Proposals

|  |  |
| --- | --- |
| **Type** | Optimistic proposal — one action, no ballot |
| **Executive action kinds** | PAYOUT · INVEST · DIVEST · METADATA · UPGRADE ($CAPER only) |
| **Who may propose** | Any holder of at least 1 of the caper’s own tokens |
| **Cost** | The greater of 500 XRD and 10% of the action’s XRD value, paid into the caper’s own treasury |
| **Window** | 48 hours from creation |
| **Passes if** | The live curve price is at or above the 7-day TWAP baseline locked at creation |
| **Related** | [Execution](/wiki/governance/execution), [Optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance), [Proposal lifecycle](/wiki/dao-governance/concepts/voting/proposal-lifecycle) |

A **proposal** is a single on-chain action a caper's treasury will perform unless its own market objects. Nobody casts a ballot. When the proposal is raised the contract freezes the action and locks a price baseline; forty-eight hours later anyone can settle it, and it passes if the caper's live token price is at or above that baseline. Holding is consent, and selling is the only way to object – which makes a caper a working instance of [optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance), with the veto priced by a market rather than raised by a council.

This replaced a ranked-ballot system in August 2026. Pages elsewhere on this wiki may still describe the older mechanism; the deployed contract is the authority, and its public surface no longer carries a vote entry point at all.

## One action, not a ballot

A proposal carries exactly one action, chosen from five kinds and typed at creation. There are no options to rank, no “do nothing” entry, and no supermajority arithmetic: the alternative to a proposal passing is simply that it does not pass, and nothing happens. 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](/wiki/dao-governance/concepts/voting/typed-vs-arbitrary-execution).

- **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](/wiki/markets/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 `CaperMain` component before it will store it.

Every action 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 action 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](/wiki/governance/execution).

## The window, and what settles it

Creation locks a **baseline**: the time-weighted average price of the caper's token over the trailing seven days, computed from the curve's own sampled circulation history and converted into price space. That number is written into the proposal and never recomputed.

The proposal is then open for **48 hours**, during which nothing governance-specific happens. Members trade, or do not. When the window closes, any account – member or not – can call the resolve entry point once. It reads the live spot price off the [bonding curve](/wiki/markets/bonding-curve) and compares it with the stored baseline:

- **Spot at or above the baseline → the proposal passes.** The market was told what would happen and did not sell.
- **Spot below the baseline → it fails.** Enough holders sold, during a window in which the proposed action was public, to push the price under where it had been trading. That is the veto.

Settlement is once-only and irreversible, and execution is a separate call that anyone can likewise make. Both are permissionless public goods, so the caper's own treasury reimburses whoever performs them: 5 XRD per call, against a per-proposal allowance of 500 XRD that no repeat call can bleed, because the once-only flag flips in the same substate write that draws the gas. The floor on the proposal fee exists to cover exactly that allowance – a proposal can never cost a treasury more to settle than it paid to raise.

Two consequences are worth stating plainly. First, an apathetic caper passes proposals: silence resolves as consent, which is the deliberate inverse of a quorum and the standard objection to every optimistic system. Second, the 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](/wiki/dao-governance/concepts/voting/quorum-and-threshold-design), and the exit itself in [leaving a caper](/wiki/foundations/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**, which is the greater of a **500 XRD floor** and **10% of the action's XRD-equivalent value**. A PAYOUT in a non-XRD currency and a DIVEST are converted at the issuing caper's live curve price; an INVEST is denominated in XRD already; METADATA and UPGRADE move no value and pay the floor. Send more than is due and the remainder comes back in the same transaction.

The 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. Its percentage leg is what prices scale – a proposal to move a large fraction of a treasury costs proportionally more to raise than one to pay a small invoice, which is a spam control that does not fall on small proposers. See the [FAQ](/wiki/help/faq) on protocol fees.

None of these figures is a constant of the protocol, and none is an admin toggle either. The fee floor, the fee rate, the 48-hour window and the seven-day TWAP 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 market test as everything else.

One caper cannot carry proposals at all: **$XRD**, which holds native XRD and has no bonding curve. Baseline and spot would both read zero, every proposal would pass 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. From [optimistic governance](/wiki/dao-governance/concepts/voting/optimistic-governance) – Aragon's optimistic plugins, UMA's oSnap – comes the shape: a proposal is assumed to pass and the work is in objecting. What those systems leave open is _who_ may object and at what cost, which is usually a named guardian council or a bonded challenger. Caper answers it with the second family, the market-decides tradition that [futarchy](/wiki/dao-governance/concepts/voting/futarchy) belongs to and that [MetaDAO](/wiki/daos/infrastructure/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.

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: is the token still worth what it was worth before this was proposed? 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 good proposal, and a proposal too small to move the price passes on indifference rather than on assent.

The 48-hour window plays the role a [governance timelock](/wiki/dao-governance/concepts/voting/governance-timelocks) 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](/wiki/dao-governance/concepts/voting/proposal-lifecycle).

## The proposal lifecycle

A proposal moves through three phases — propose, window, resolve — and carries exactly one of five on-chain actions. Nobody votes: the proposal passes if the caper’s live price is at or above the seven-day TWAP baseline locked when it was raised.

CAPER PROTOCOLThe proposal lifecycle3 PHASES · 5 ACTIONSPROPOSE → WINDOW → RESOLVE1PROPOSEHold 1 token, pay the fee. Theaction and a 7-day TWAP baselineare frozen.248-HOUR WINDOWThe market trades. Holding isconsent; selling is the only wayto object.3RESOLVEAnyone settles it, then executesit. The treasury pays the gas.WHAT A PASSED PROPOSAL CAN DOPAYOUTPay a recipient from the treasury— a grant, a salary, a bill.INVESTBuy another caper’s token straightinto your treasury.DIVESTSell a token the treasury holdsback down its own curve.METADATARewrite this caper’s own tokendescription, icon or link.UPGRADESwap the shared logic. $CAPERproposals only.It passes if the live price is at or above the baseline locked at creation. Nobody votes.How a caper turns a decision into an on-chain action — priced by its own market.caper.networkPropose → 48-hour window → resolve · PAYOUT / INVEST / DIVEST / METADATA / UPGRADE.