A caper pays someone from its treasury by passing a PAYOUT proposal: a motion naming a recipient, a currency and an amount, which members rank on a ballot and which the market can still block by selling before the money moves. A caper is a group of people who raise a treasury together on a bonding curve and govern it on Radix. No multisig signs the payment and no treasurer holds the keys. This page answers what paying someone involves, in the order people ask it.
A DAO pays a contributor in one of three ways: its token holders pass a proposal that carries the transfer and a contract executes it; the signers of a multisig send it; or a stream releases it by the second. Each ends with the treasury moving tokens to the contributor's address, and a DAO can use more than one.
A caper pays only the first way. A PAYOUT proposal names the contributor's account, the currency and the amount; members pass it on a ballot; and the market gets a window to block it by selling before the money moves. No multisig can sign for a caper's treasury and Caper has no streams, so recurring pay is a fresh proposal each time. The sections below take each step in turn, and contributor compensation in DAOs covers salaries, bounties, grants and peer allocation across the industry.
By passing a PAYOUT proposal, the only kind of proposal that sends value to a person.
You cannot pay someone without passing one. There is no admin withdrawal, no founder key over the treasury and no operations wallet outside governance. Only the platform's own logic can reach the treasury, and it releases funds on a short, fixed list of paths: an executed payout, an executed investment or divestment, and a member using the exit right. Everything else is a proposal or it does not happen.
The token holders, collectively, and nobody individually.
Can whoever set the caper up drain the treasury? No. The founder holds no key over it and has no withdrawal method of their own to call. The founder earns from a share of the skim, the small charge on every buy and every sell, which falls as more of the supply is sold. That share is no claim on the treasury and gives the founder no say over what the treasury spends. A founder who wants treasury money raises a proposal like anyone else, pays the same fee and faces the same market window.
Any holder of the caper’s own token. The contract checks the holding when the proposal is created and aborts without it. There is no proposer threshold, no council seat, no whitelist and no founder veto over what reaches the ballot.
The proposer pays a proposal fee once, at creation, in $XRD. It goes into the caper’s own treasury, is kept whether the proposal passes or fails, and anything sent above it comes straight back. It is priced off the largest option on the slate, because the winner is unknown until the count and a large payout must not hide behind a cheap decoy. Opening the market window after a pass costs nothing, for anyone.
Each ballot pays its own vote fee into the same treasury and earns its voter vote tokens, which carry vote weight and the right to exit. Casting ballots is the only way to earn them; buying earns none.
None of these charges is a lever. They are set when the shared logic is installed, and nothing on its public surface changes them; see proposals for how the logic itself is replaced.
Somebody who holds the caper's token raises a proposal naming your account address and your amount. If members pass it and the token's average price across the market window holds at or above where it stood when the window opened, the money is sent to you. You do not have to join the caper, hold its token or use a wallet it recognises. Ask for the proposal, not an invoice: the proposal is what pays.
Any Radix account. The recipient is stored on the option as an account, and nothing requires it to belong to a member, a 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 app this is the “Pay external address” choice.
Any resource the treasury holds. The option carries a currency alongside the amount, so a caper that has invested in other capers' tokens can pay in those. The transfer rounds down to what the currency can divide into, and the event it emits reports the amount that moved, so the receipt never overstates the payment.
It decides half of it. Members legislate on a ranked ballot, then the market gets a window to object to what they passed. Neither phase alone moves the money.
Phase one, the ballot. A proposal carries a short slate of options, one of which is always “Do nothing”. Holders rank every option, and each ballot counts with its voter's earned vote weight. Once voting closes, anyone can send the count. The leading option passes only if it clears a supermajority of the weight cast, a bar that is higher when there are fewer options, and a leading “Do nothing” passes nothing. There is no turnout quorum: the bar is a share of what was cast, not of what exists. Voting has the detail.
Phase two, the window. A pass on the ballot executes nothing. Anyone can then open the market window, which records the token's recent average price as the baseline. During the window holders trade or do not; selling pushes the price down, buying pushes it up.
After the window closes, anyone can resolve it. If the average price across the window is at or above the baseline, the proposal has passed; below, it has failed. The test uses the whole window rather than the price at the moment someone resolves, so moving the verdict means holding the price down or up for a real share of the window, and a buy and sell wrapped around the resolving call achieves nothing.
A proposal needs an active supermajority of the weight cast to get anywhere, so silence on the ballot kills it. Once it has that, silence in the window is assent: the only people who can block a spend they lost the vote on are those willing to sell over it, who are also the people who bear the cost if the spend is bad.
The design buys three things a ballot alone cannot. Buying the second phase means buying the token itself and holding it through the window, which is expensive. 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 before it executes. This is the trade-off covered in optimistic governance, with a market in place of a bonded challenger as the veto.
A voting period, then the market window, then a short chain of open calls. Both periods are set when the shared logic is installed. The current deployment runs on Stokenet, Radix's test network, with periods set for testing; a production deployment sets its own by installing new logic. Once a proposal's window is open it carries its own end date, so you can read the deadline off the proposal.
The window runs from when someone opens it after a pass, not from creation, so a proposal that has passed its ballot but not been opened has not started its window. Resolving records the verdict on-chain, once. Executing is a separate call, and it has a deadline of its own, set at resolution: a passed payout that nobody executes in time lapses rather than staying armed. Whoever makes each call pays its network fee; the treasury pays none of it.
Anyone. Both resolve_proposal and execute_proposal_payout are open calls, with no badge, no proof of membership and no privileged caller. If a payment survives its window, any passer-by can make it happen, and the people it inconveniences cannot stop it by declining to sign.
That is safe because the caller controls nothing about the payment. The recipient, the currency and the amount were fixed when the proposal was created, and execution reads them from the ledger, not from the transaction. Whoever executes a payout cannot redirect it, cannot round it up and cannot execute a proposal that failed. Execution also happens once: the contract marks the proposal executed before it moves anything, so a payout cannot be replayed.
Nothing moves, and it can fail at either phase. A ballot whose leader misses the supermajority, or whose leader is “Do nothing”, never gets a window. A proposal that passed its ballot and then lost its window is resolved as failed, and every execution path checks that verdict, so it can never be executed.
There is no retry and no second window. The count and the resolution each happen once, so getting the payment through means raising a fresh proposal and paying the proposal fee again. The first fee stays with the caper either way, so a proposal that fails costs its author what one that passes does.
Paying is one of five kinds of action a proposal can execute, all raised the same way and settled by the same two tests, and a sixth kind executes nothing:
INVEST and DIVEST give “what can a caper spend money on” a second answer: a treasury can take a position in another caper rather than only spending down. Proposals covers every kind in full.