A caper raises a treasury on a bonding curve and governs it on-chain. Sooner or later somebody has to be paid out of it – a contributor, a supplier, a grantee, the founder. In Caper that is a PAYOUT proposal: a motion that names a recipient, a currency and an amount, is ranked by members on a ballot, and – if the ballot passes it – then sits out a window in which the market can still veto it by selling, before it moves the money itself. No multisig signs it and no treasurer holds the keys. This page answers what that involves, in the order people ask it.

How do I pay someone from a caper's treasury?

By passing a PAYOUT proposal. It is the first of the five things a proposal can execute, and it is the only one that sends value to a person: the contract discriminates execution on the action's kind field, and kind 0 means treasury.transfer(recipient, currency, amount).

What you cannot do is pay someone without passing one. There is no admin withdrawal, no founder key over the treasury vault, and no "operations wallet" that sits outside governance. The treasury vault is only reachable through a badge the contract holds itself, and it releases funds along a short and fixed list of paths: an executed payout, an executed investment or divestment, and a member exercising the exit right. There was a fourth until 11 September 2026 – a contingent reimbursement of the gas spent resolving or executing a proposal, capped at the 500 XRD that proposal had banked – and the redeploy removed it. Everything else is a proposal or it does not happen.

Who controls the treasury?

The token holders, collectively, through the market – and nobody individually. This is the question worth settling before any of the mechanics below, because it is where most DAO treasuries actually differ from what their documentation claims.

Can the treasury be drained by whoever set the caper up? No. The founder holds no key over the vault and no privileged withdrawal method exists for them to call. Their advantage is taken somewhere else entirely: a bounded slice of each purchase on the bonding curve, taken as the money comes in, and capped by a ceiling the contract derives rather than an administrator sets. It is not a claim on the treasury and it confers no authority over what the treasury spends afterwards. A founder who wants to move treasury money has to raise a proposal like anyone else, pay the same fee, and survive the same window of anyone being able to sell against it.

How do I propose a payment, and who is allowed to?

Any holder of the caper’s governance token. The contract’s check is deliberately low: it takes a proof of your holdings and asserts you have at least one token. There is no proposer threshold, no council seat, no whitelist and no founder veto over what reaches the treasury.

The fee model is two-tier, and conflating the tiers is the commonest mistake. At creation you pay a flat 500 XRD (PROPOSAL_FEE, contracts/logic/src/lib.rs), in XRD, banked by the caper rather than burned and kept whether the proposal passes or fails; anything you send above it is handed straight back. That figure does not scale with the amount at stake. The percentage leg is a separate, later charge: 10% of the winning action’s XRD-equivalent value (PROPOSAL_FEE_RATE), due only when someone triggers the optimistic window, and priced at the relevant curve’s trailing time-weighted average price (TWAP) at that moment rather than at creation, so a trade in the same transaction cannot move it.

Who pays that second leg is itself on the ballot. Every ranked ballot carries a second question – proposer pays, or treasury pays – and a “treasury pays” verdict nets to a waiver, because the fee’s sink is the caper’s own treasury. So a proposal the members want carried can be triggered by any passer-by for nothing, while a proposal the members want the author to stand behind costs that author a tenth of what it moves.

Each ranked ballot also costs its voter 100 XRD (VOTE_FEE), likewise into the caper’s own treasury, and mints exactly 1 soulbound v in return (VOTE_MINT, a fixed amount per ballot rather than a rate on the fee). Since the redeploy of 11 September 2026 a ballot is the only way a member earns v; trading mints none.

The flat 500 XRD now exists for one reason: because it is kept either way, it prices the act of putting the treasury on the agenda at all. It had a second until 11 September 2026, when the figure was pinned to the per-proposal settlement-gas allowance so that a proposal could never draw more out of the treasury in settlement costs than it put in. That allowance is gone – the redeploy removed treasury-funded settlement outright – so the fee is no longer a ceiling on anything but itself.

None of the three figures is a lever. All are constants compiled into the platform’s logic package, and the deployed CaperMain exposes no setter for any of them. Changing one means publishing a fresh logic component and moving the registry’s current_main to it through a governed UPGRADE proposal.

How do I get paid by a caper?

From the receiving end: somebody who holds the caper's token raises a proposal naming your account address and your amount, it sits out the market window, and if the token's average price over that window holds at or above the baseline locked at the trigger the money is sent to you. You do not have to join the caper, hold its token, or hold a wallet it recognises. What you should ask for is the proposal, not an invoice – the proposal is the thing that pays.

Who can be paid, and in what?

Any Radix account. The recipient is stored as an account reference on the option, and nothing requires it to belong to a member, a token holder, or a wallet that has ever touched the caper. A caper can pay an outside contractor as easily as one of its own founders. In the interface this is the "Pay external address" path.

Any resource the treasury holds. The option carries a currency alongside the amount, so a caper that has invested its XRD into other capers' tokens can pay in those. The transfer floors to the currency's divisibility and the emitted event reports the amount that actually moved, so the receipt never overstates the payment.

How does the vote decide it?

It decides half of it. A caper settles proposals in two phases: members legislate on a ranked ballot, and the market then gets a window to veto what they passed. Neither phase alone can move the money.

Phase one, the ballot. A proposal carries between two and five options, one of which must be a “Do nothing”. Holders cast a full ranking of every option – a permutation, no ties and no abstentions within it – weighted by w = (t·v)/(V·T). A permissionless crank folds the ballots into a Borda tally, and the leading option passes only if its share of the weight actually cast clears a supermajority of 1.5 / option_count: 75% on a two-option ballot, 30% on a five-option one. Those figures fall with the ballot width and the bar does not: they are shares of the Borda pool, which caps any single option at 2 / option_count, so the threshold is three-quarters of unanimity at every width (derivation). If the leader is the “Do nothing”, nothing passes. There is no quorum on turnout – the threshold is a share of what was cast, not of what exists.

Phase two, the window. A legislative pass does not execute; it makes the proposal triggerable. trigger_proposal reads the caper’s trailing time-weighted average price, locks it as the baseline, and opens the market window. (One caper, $XRD, is measured differently; see the end of this section.) During the window nothing is collected. What holders can do is trade: selling pushes the price down the curve, buying pushes it up.

After the window closes, anyone can call resolve_proposal. It integrates the price over the window itself – anchored at the window’s end date, not at the moment of the call – and compares that TWAP with the baseline. At or above, the proposal has passed. Below, it has failed. Integrating rather than sampling is what makes the verdict expensive to fake: a displacement has to be held for a real share of the window, so an atomic buy→resolve→sell round trip buys nothing.

The consequence is worth stating plainly, because it is unusual in either direction. A proposal needs an active majority of the weight cast to get anywhere – silence in phase one kills it. But once it has that, silence in phase two is assent: the only people who can block a spend they lost the vote on are the people willing to sell their position over it, which is the same set who bear the cost if the spend is bad. Objecting late is not free, and it is not meant to be.

That design buys three things a ballot alone cannot. There is nothing to bribe cheaply, because buying the second phase means buying the token itself and holding it through the window. The signal is continuous rather than a snapshot: the window reflects everything the market learned after the vote, including anything the proposal’s author did not disclose. And a decision that was right when it was taken can still be stopped if the facts change in the window before it executes. This is the trade-off covered in optimistic governance – the same family as the delay-and-veto model UMA’s oSnap popularised, with a market rather than a bonded disputer as the veto.

One caper runs phase two differently. The $XRD caper has no curve, because its token is native XRD, so it has no price of its own for a window to move. It takes proposals all the same. Its window reads a reference basket instead: the reserve-weighted price of other capers’ curves, quoted in XRD (XRD_BASKET, basket_baseline_and_anchor and resolve_proposal in contracts/logic/src/lib.rs). The basket is priced in XRD, so the test is inverted: the proposal passes if the basket’s mean over the window is at or below the baseline. Moving capital out of capers into XRD counts as consent. Pushing XRD into capers is the veto. On the deployment live since the 15 September 2026 redeploy, the basket has one member, $CAPER, the one caper the registry guarantees exists. That was the component’s xrd_basket field when read on 16 September 2026. Widening the basket takes a new logic package.

How long does it take?

A voting period, then the market window, then a short chain of permissionless calls.

The voting period is VOTING_PERIOD_SECONDS – on the deployed logic that is drill tuning for the Stokenet deployment, not a production figure, and a production deployment retunes it by shipping a new logic package. Once it closes, anyone cranks the tally. The market window is PROPOSAL_WINDOW_SECONDS, drill tuning on the same terms, and the baseline is integrated over the trailing TWAP_WINDOW_SECONDS, a logic constant. None of the three is configurable at runtime; all are compiled in, and retuning them means a new logic component and a governed swap. The proposal carries its own window end date once triggered, so you can read the exact deadline off the proposal rather than computing it.

Note where the clock starts: the window runs from the trigger, not from creation, so a proposal that sits un-triggered after a legislative pass has not started its window at all. Once it has closed, resolve_proposal records the verdict on-chain – the frozen baseline, the window TWAP it computed, and the pass flag – and emits it. Resolution is once-only: the contract asserts the proposal is not already settled. Execution is a separate call after that, and both callers now pay their own network fee: the single settlement-gas allowance the two used to draw from the treasury was removed in the redeploy of 11 September 2026.

Who actually presses go?

Anyone. Both resolve_proposal and execute_proposal_payout are open calls – no badge, no proof of membership, no privileged caller. If a payment survives its window, any passer-by can make it happen, and the people it inconveniences cannot make it not happen by declining to sign.

Both callers pay their own way, and that is a change. Until 11 September 2026 the treasury reimbursed each path contingently, up to 5 XRD a call against a 500 XRD per-proposal budget. A pen-test found the subsidy was wider than it looked: the Radix engine consumes locked fees in reverse lock order, so the treasury's lock was drawn before the caller's and paid the first 5 XRD of any transaction containing a single settle-path call – including a one-ballot crank – whatever else that transaction was doing. The redeploy removed settlement gas outright rather than repricing it, so cranking a proposal is now a public good somebody pays for out of their own pocket.

Permissionless execution is safe because the caller controls nothing about the payment. The recipient, the currency and the amount were frozen into the action when the proposal was created, and execution binds the stored action: it reads the recipient out of chain state, not out of the transaction. The person who executes a payout cannot redirect it, cannot round it up, and cannot execute a proposal that failed.

Execution is also once-only. The contract flips an executed flag before it moves anything, so a payout cannot be replayed for a second helping.

What if the proposal fails?

Nothing moves, and it can fail at either phase. A ballot that never reaches the 1.5 / option_count supermajority, or whose leading option is the “Do nothing”, is simply never triggerable – there is no window to open. A proposal that passed its ballot and then lost its window is resolved false: resolution writes a pass flag alongside the frozen baseline and the window TWAP it computed, and every execution path binds that flag, so a proposal resolved false cannot be executed, then or ever.

There is no retry and no second window – both the tally and the resolution are once-only, so a proposal that failed is finished, and getting the payment through means raising a fresh one and paying the 500 XRD again.

The legislative fee stays with the caper either way. It is banked irrevocably at creation, and it paid for the settlement pass, which had to run regardless of the answer. The 10% execution fee is different: it is charged at the trigger, so a proposal that never passed its ballot never incurs it at all.

What else can a proposal do?

Paying is one of five executable action kinds, all raised the same way and all settled by the same price test – and there is a sixth that is settled by neither, because it executes nothing:

• PAYOUT (kind 0) – transfer a treasury asset to an account.
• INVEST (kind 1) – withdraw treasury XRD and buy another caper's token with it, holding the result in the treasury. The XRD never touches the worktop, so nothing can be skimmed in transit.
• UPGRADE (kind 3) – swap the platform's logic contract. Restricted to the $CAPER caper, because one upgrade changes the rules for every caper at once.
• DIVEST (kind 4) – the reverse of INVEST: sell a held token back into its own curve and bring the XRD home.
• METADATA (kind 5) – rewrite the mutable presentation keys on this caper's own token. The identity keys – name, symbol, cashtag – are locked at mint and no proposal can reach them.
• DEBATE (kind 6) – executes nothing. A position in an argument, ranked with the others and able to win the tally, after which the proposal ends. The contract asserts it carries no recipient, currency, amount or target, and refuses to trigger it if it wins, so it never opens a market window and never pays an execution fee. Added to the deployed logic on 5 September 2026.

The discriminants skip 2. Kind 2 was VOTE, which let one caper cast its treasury's ballot in another caper's governance; it died with the ballot itself, and the contract now rejects it by name rather than reusing the number. The enumeration has since widened rather than narrowed: kind 6 was added on 5 September 2026 by publishing a new logic package and moving the registry's current_main onto it, which is the only way any of these numbers can change. INVEST and DIVEST are why "what can a caper spend money on" has a second answer: a treasury can take a position in another caper rather than only spending down. Those funding edges are readable on each caper's ledger.

Related

• What is a caper – the object this treasury belongs to
• Getting started – starting one, and what it costs
• Leaving a caper – the other way value leaves a treasury
• Querying a caper from an AI agent – reading a caper's proposals and payouts programmatically
• Optimistic governance – the wider family this settlement model belongs to
• DAO contributor compensation – how the wider industry pays people