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 decided by a ranked vote, and then 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 do, and it is the only one that sends value to a person: the contract discriminates execution on an option'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 exactly four paths: an executed proposal, an executed investment or divestment, and a member exercising the exit right. Everything else is a proposal or it does not happen.

Who controls the treasury?

The token holders, collectively, through the ballot — 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 put it on the ballot like anyone else, and win the same vote.

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 ballot.

The cost is a flat proposal fee, paid in XRD at the moment of creation and banked by the caper rather than burned. It exists for a specific reason: the fee has to cover the gas budget of the settlement pass that the proposal will later force somebody to run, so that a proposal can never draw more out of the treasury in settlement costs than it put in. The contract asserts that floor whenever the fee is changed. The fee is a governance-settable lever, so this page does not quote a figure — read the live value from the caper itself.

How do I get paid by a caper?

From the receiving end: somebody who holds the caper's token puts your account address and your amount on a ballot, the members vote, and if it clears the bar 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?

Every proposal is a ranked ballot, not a yes/no switch. You put between 2 and 12 options on it, voters rank them, and the contract scores them by Borda count: on a ballot of m options, a voter's first choice receives m−1 times their vote weight, their second m−2, and so on down to zero for the last. Options are usually a real spend and a "no" option, but nothing stops you from putting three different amounts on the ballot and letting the members pick one.

The option with the most points wins if its share of the total weight cast clears 1.5 ÷ the number of options. That bar moves with the shape of the ballot, and it is worth understanding before you write one:

• 2 options → the winner needs 75% of the weight
• 3 options → 50%
• 4 options → 37.5%

So a straight spend-or-don't motion is the hardest thing to pass in a caper, and adding genuine alternatives lowers the bar rather than raising it. There is no separate turnout quorum: the threshold is a share of the weight actually cast, not of the weight that exists. A proposal whose leading option is the "no" option never passes, whatever its score.

Vote weight is the same figure that decides your treasury share on exit — see how voting works for the formula. One detail matters here: at settlement each ballot's stake term is re-read and clamped down to the smaller of what you held when you voted and what you hold now. Selling after you vote shrinks your own ballot. It cannot grow it.

How long does it take?

Two windows, in order. First the voting window, which runs from creation to a fixed end date; then an execution delay, after which the proposal can be settled and, if it passed, executed. Both lengths are configured on the platform contract rather than fixed in the protocol, so this page does not quote them — read the dates off the proposal, which carries its own start, voting-end and execution-end timestamps.

Settlement is a distinct step from voting, and it is where the tally is frozen: the contract folds every ballot, records the option weights and the pass flag on-chain, and emits them. Large proposals can have their ballots folded in chunks beforehand, so no single transaction ever has to iterate an unbounded voter list.

Who actually presses go?

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

That is safe because the caller controls nothing about the payment. The recipient, the currency and the amount were frozen into the option when the proposal was created, and execution binds the stored winning option: 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 losing option.

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. A settled proposal that did not clear its bar has no winner recorded, and every execution path aborts on that: there is no option to bind. The same is true when the "no" option is the one that wins — the contract refuses to execute a no-op.

The proposal fee stays with the caper either way. It paid for the settlement pass, which had to run regardless of the answer.

What else can a proposal do?

Paying is one of five option kinds, all decided by the same ranked ballot and the same threshold:

• PAYOUT — transfer a treasury asset to an account.
• INVEST — 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.
• DIVEST — the reverse: sell a held token back into its own curve and bring the XRD home.
• VOTE — cast this caper's ranked ballot on another caper's proposal. Capers that hold each other's tokens can govern each other.
• UPGRADE — swap the platform's logic contract. Restricted to the $CAPER caper, because one upgrade changes the rules for every caper at once.

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
• DAO contributor compensation — how the wider industry pays people