How do you pay a contributor from a DAO treasury? 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 vote that executes. On a DAO built with OpenZeppelin Governor (/wiki/dao-governance/tooling/voting/openzeppelin-governor) , the proposal holds the payment call itself. When it passes and the DAO runs a timelock, the timelock executes it, so OpenZeppelin's guide (https://docs.openzeppelin.com/contracts/5.x/governance) has the timelock, not the Governor, hold the funds. - A multisig. A Safe (/wiki/dao-governance/tooling/treasury/safe) keeps a list of owners and a threshold, and a transaction executes (https://docs.safe.global/advanced/smart-account-concepts) once that many owners have confirmed it. A vote can set a budget and leave each payment to the signers. - A stream. Superfluid (/wiki/dao-governance/tooling/treasury/superfluid) moves tokens at a per-second rate (https://docs.superfluid.org/docs/concepts/overview/money-streaming) until the sender or receiver cancels the stream, and Sablier (/wiki/dao-governance/tooling/treasury/sablier) offers Flow for recurring payments and grants (https://docs.sablier.com/concepts/what-is-sablier) . 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 (/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) covers salaries, bounties, grants and peer allocation across the industry.

Mechanic PAYOUT proposal (action kind 0) Contract method execute_prop…c/lib.rs) Who can propose Anyone holding at least 1er of thate caper’s governanceown tokens Who can receive Any Radix ac… the treasury holds, not only $XRD How it is decided Two phases. A: a ranked ballot must clear a supermajority of 1.5 / option_count of the weight cast;, then the market then gets a window to vetoobject by selling Window The market window, opened by the trigger (not at creation); when it closes anyone can resolve Proposal fee 1% of the payout’s XRD value (of the largest option, on a slate), at least 500 XRD – paid at creationCost A proposal fee at creation, into the caper’s own treasury and kept whether ithe proposal passes or fails Ballot fee 100 XRD per ranked ballot, into the caper’s own treasury; mints 1 soulbound v Who executes Anyone. Tally, trigger; each ballot pays its own vote fee Who executes Anyone. Counting, opening the window, resolutionving and executiong are all permissionless callopen calls Deadline A passed payout nobody executes in time lapses

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 ispays someone from its treasury by passing a PAYOUT proposal: a motion that namesnaming a recipient, a currency and an amount, is ranked bywhich members rank 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 itselfwhich 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 ithe payment and no treasurer holds the keys. This page answers what thatpaying someone involves, in the order people ask it.

How do I pay someone from a ca… 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 y, the only kind of proposal that sends value to a person. You cannot do is pay someone without passing on… 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 itselfOnly the platform's own logic can reach the treasury, and it releases funds along a short and, fixed list of paths: an execu…t or divestment, and a member exerciusing the exit right (/wiki/foundations/leaving-a-caper) . 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: half 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 (/wiki/foundations/what-a-founder-can-take) , athe small sliccharge ofn every buy and every sell on the bonding curve, exits included, at a rate that shrinks as more of the supply is sold and that the contract derives rather than an administrator sets. Nearly all the other half goes to the caper’s own treasury. It, which falls as more of the supply is sold. That share is not a claim on the treasury and it confgives the founders no sauthority over what the treasury spends afterwards. A founder who wants to move treasury money has to raises a proposal like anyone else, pays the same fee, and survivefaces the same window of anyone being able to sell against itmarket window.

How do I propose a payment, an…o? Any holder of the caper’s governanceown token. The contract’s check is deliberately low: it takes a proof of your holdingss the holding when the proposal is created and asseborts you have at least one tokenwithout it. There is no proposer thresho…er veto over what reaches the treasury. The fee is paid once, at creation, by the proposer: 1% of the largest option’s XRD-equivalent value, at least 500 XRD (PROPOSAL_FEE_RATE and PROPOSAL_FEE, contracts/logic/src/lib.rs). It is paid in XRD, banked by the caper rather than burned andballot. 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 you sendt above it is handedcomes straight back. A payout under 50,000 XRD pays the 500 XRD floor, and a 100,000 XRD payout pays 1,000 XRD. TIt is priced off the largest option prices iton the slate, because the winner is unknown at creation, sountil the count and a large payout canmust not hide behind a cheap decoy on the same slate. A payout in a caper token converts at the issuing curve’s trailing time-weighted average price (TWAP) rather than at spot, so a trade in the same transaction cannot move the basis. Triggering a passed proposal is free, for anyone. Until 6 October 2026 the percentage was a separate, later charge: 10% of the winning action’s value, due at the trigger, and every ballot voted on whether the proposer or the treasury paid it. “Treasury pays” was the treasury paying itself, and “proposer pays” fell on whoever called the trigger, so the redeploy of that day replaced both with the single fee above. 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. 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 a member earns v; trading mints none. The 500 XRD floor exists for one reason: because it is kept either way, it prices the act of putting the treasury on tto earn them; buying earns none. None of these charges is a lever. They 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 proposalre set when the shared logic is installed, and nothing on its public surface changes them; see proposals (/wiki/governance/proposals) for how the logic itself is replaced.

How do I get paid by a caper? From the receiving end: sSomebody who holds the caper's …ccount address and your amount, it sits out the market window,. If members pass it and if the token's average price over thaacross the market window holds at or above twhe baseline locked at the triggerre it stood when the window opened, the money is sent to you. You…join the caper, hold its token, or holduse a wallet it recognises. What you should aAsk for is the proposal, not an invoice –: the proposal is the thing twhat pays.

Who can be paid, and in what? …ount. The recipient is stored as an account reference on the optionon the option as an account, and nothing requires it to belong to a member, a token holder, or a wallet that has ever tou…e of its own founders. In the interfaceapp this is the "“Pay external address" path” choice. Any resource the treasury h…so a caper that has invested its XRD inton other capers' tokens can pay in those. The transfer floors torounds down to what the currency's can divisibilityde into, and the emitted eventvent it emits 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: mMembers legislate on a ranked ballot, andthen the market then gets a window to veobject to what they passed. Neither phase alone can moves the money. Phase one, the ballot. A proposal carries between two and fivea short slate of options, one of which must be ais always “Do nothing”. Holders cast a full ranking of every option – a permutation, no ties and no abstentionrank every option, and each ballot counts within it – weighted by each holds voter’'s earned vote weight. A permissionlessOnce voting closes, anyone 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, a bar that is higher when there are fewer options. 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 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 (/wiki/dao-governance/concepts/voting/ranked-and-alternative-ballot-methods) ). 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-weightedvoting) 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, locks it as the baseline, and opens the market window. During the window nothing is collected. What holders can do is trade:. During the window holders trade or do not; 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 abov it. If the average price across the window is at or above the baseline, the proposal has passed. B; below, it has failed. Integrating rather than sampling is what makes the verdict expensive to fake: a displacement has to be heldThe 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, so and atomic buy→resolve→sell round trip buys nothing. The consequence is worth stating plainly, because it is unusual in either direction. 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 ion phase onethe ballot kills it. But oOnce it has that, silence in phase twothe window is assent: the only people wh…d they lost the vote on are the peoplose 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 beover it, who are also the people who bear the cost if the spend is bad. Thate design buys three things a ballot alone cannot. There is nothing to bribe cheaply, because bBuying the second phase means b… holding it through the window. The signal is continuous rather than a snapshot: t, which is expensive. The window reflects everything …ncluding anything the proposal’'s author did not disclose. And…e stopped if the facts change in the window before it executes. This is th…voting/optimistic-governance) – the same family as the delay-and-veto model UMA’s oSnap popularised, with a market rather thanin place of a bonded disputchallenger as the veto.

How long does it take? A voti…window, then a short chain of opermissionless 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 productionn calls. Both periods are set when the shared logic is installed. The current 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 threeon Stokenet, Radix's test network, with periods set for testing; a production deployment sets its configurable at runtime; all are compiled in, and retuning them means a new logic component and a governed swap. The proposalown by installing new logic. Once a proposal's window is open it 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: t. The window runs from twhe triggern someone opens it after a pass, 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 2026has 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.

Who actually presses go? Anyone. Both reso…proposal_payout are open calls –, with no badge, no proof of membership, and no privileged caller. If a pa…ople 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 executionstop it by declining to sign. That is safe because the caller co…currency and the amount were frozen into the actionixed when the proposal was created, and execution binds the stored action: it reads the recipient out of chain state, not out ofreads them from the ledger, not from the transaction. The person whoWhoever 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 anhappens once: the contract marks the proposal executed flag before it moves anything, so a payout cannot be replayed for a second helping.

What if the proposal fails? N…ail 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 computwhose 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 bindchecks that flag, so a proposal resolved false cannot be executed, then or eververdict, so it can never be executed. There is no retry and no second window – both the tally. The count and the resolution are once-only, so a proposal that failed is finished, andeach happen once, so getting the payment through means raising a fresh oneproposal and paying the proposal fee again.The proposalfirst fee stays with the caper either way. It is banked irrevocably at creation, and nothing further is charged at the trigger, so a proposal that fails costs its author exactly what one that passes does.

What else can a proposal do? Paying is one of five executable action kindskinds of action a proposal can execute, all raised the same way and all settled by the same pricetwo test –s, and there is a sixth that is settled by neither, because ita sixth kind executes nothing: - PAYOUT (kind 0) – transfer– send a treasury asset to an account. - INVEST (kind 1) – withdraw– spend treasury $XRD and buyon another caper's token with it,and 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 oncegoes from the treasury into the trade without passing through anyone's hands. - 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 presentdescription, icon or information keyslink onf this caper's own token. The identity keys –Its name, symbol, and cashtag – are locked at mintlaunch 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; with no amount, it pays the 500 XRD floor at creation. Added to the deployed logic on 5 September 2026. The discriminants skip 2. Kind 2 was VOTE, which let one caper casUPGRADE – swap the platform's shared logic. Only the $CAPER caper can raise one, because one upgrade changes the rules for every caper at once. - DEBATE – executes nothing. It 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 reusa position in an argument, ranked with the others and able to wing 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. count, after which the proposal ends without a market window. INVEST and DIVEST are why "give “what can a caper spend money on" has” a second answer: a treasury c…ther than only spending down. Those funding edges are readable on each cap Proposals (/wiki/governance/proposals) cover's ledgerevery kind in full.

Related - What is a caper (/…ions/what-is-a-caper) – the objectrganization this treasury belongs to - …the wider industry pays people

How does the vote decide it? …tions within it – weighted by w = (t·v)/(V·T)each holder’s earned vote weight. A permissionless crank folds…ly cast clears a supermajority of 1.5 / option_count: 75% on a two-option ballot, 30% on a five-, a bar that is higher when there are fewer option ones. Those figures fall with the …a bonded disputer as the veto.

How does the vote decide it? …lot, 30% on a five-option one.Those figures fall with the ba…a bonded disputer as the veto.

Mechanic PAYOUT proposal (acti…it closes anyone can resolve Legislative fee 500 XRD flat, bankeProposal fee 1% of the payout’s XRD value (of the largest option, on a slate), at least 500 XRD – paid at creation and kept whether…reasury; mints 1 soulbound v Execution fee 10% of the payout’s XRD value, due at the trigger – and 0 when the ballot chose “treasury pays” Who executes Anyone. Tally, tr…n are all permissionless calls

How do I propose a payment, an…eaches the treasury. The fee model is two-tier, and conflating the tiers is the commonest mistake. At creation you pay a flais paid once, at creation, by the proposer: 1% of the largest option’s XRD-equivalent value, at least 500 XRD (PROPOSAL_FEE_RATE and PROPOSAL_FEE, contracts/logic/src/lib.rs),. It is paid in XRD, banked by the caper r…e it is handed straight back. That figure does not scale with the amA payout under 50,000 XRD pays the 500 XRD floor, and a 100,000 XRD payount 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 somepays 1,000 XRD. The largest option prices it because the winner is unknown at creation, so a large payout cannot hide behind a cheap decoy one triggers the optimistic window, and priced at the relevanthe same slate. A payout in a caper token converts at the issuing curve’s trailing time-weighted average price (TWAP) at that moment rather than at creationspot, so a trade in the same transaction cannot move it. Who pays that second leg is itself on the ballot. Every ranked ballotthe basis. Triggering a passed proposal is free, for anyone. Until 6 October 2026 the percentage was a separate, later charries 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 mge: 10% of the winning action’s value, due at the trigger, and every ballot voted on whether the proposer or the treasury paid it. “Treasury pays” was the treasury paying itself, and “proposer pays” fell on whoever called the trigger, so the redeploy of that day replaced both with the single fee aboves. Each ranked ballot also cos…s v; trading mints none. The flat 500 XRD nowfloor exists for one reason: becaus…h a governed UPGRADE proposal.

What if the proposal fails? N…ng a fresh one and paying the 500 XRDproposal fee again. The legislativeproposal fee stays with the caper eith… irrevocably at creation, and it paid for the settlement pass, which had to run regardless of the answer. The 10% execution fee is different: itnothing further is charged at the trigger, so a proposal that never passed its ballofails costs its author exactly what onever incurs it at all that passes does.

What else can a proposal do? …it never opens a market window and never pays an execution fee; with no amount, it pays the 500 XRD floor at creation. Added to the deployed logic …adable on each caper's ledger.

Who controls the treasury? Th…aken 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 half of the skim (/wiki/foundations/what-a-founder-can-take) , a small slice of every buy and every sell on the bonding curve, exits included, at a rate that shrinks as more of the supply is sold and that the contract derives rather than an administrator sets. Nearly all the other half goes to the caper’s own treasury. It is not a claim on the tre…being able to sell against it.

How does the vote decide it? …, and opens the market window. (One caper, $XRD, is measured differently; see the end of this section.) During the window nothing is …a bonded disputer as the veto.

How does the vote decide it? …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 does the vote decide it? …, and opens the market window. (One caper, $XRD, is measured differently; see the end of this section.) During the window nothing is …ed disputer as the veto. One structural exclusion follows from all of it: the $CAPER caper itself has no curve to price, so it cannocaper 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 through this path. create_proposal rejects the $XRD cashtag outright, because a baseline and a price that both read zero would wave every proposal through unconditionallyall 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 do I propose a payment, an…riced at the relevant curve’s spot at that moment rather than at creationtrailing 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…actly 1 soulbound v in return – the 0.01 v-per-XRD(VOTE_MINT, a fixed amount per ballot rateher that trading pays, applied to the fen 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 exist…h a governed UPGRADE proposal.

How do I pay someone from a ca…uted investment or divestment, and a member exercising the exit…/foundations/leaving-a-caper) , and. There was a fourth until 11 September 2026 – a contingent reimbursement of…olving or executing a proposal –, capped at the 500 XRD perthat proposal, which is exactly the flat fee that proposal already banked had banked – and the redeploy removed it. Everything else is a proposal or it does not happen.

How do I propose a payment, an…to the fee. The flat 500 XRD now exists for twoone reasons. It has to cover the settlement gas: 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 will later force somebody to spend, sosettlement-gas allowance so that a proposal canould never draw more out of the tr…ettlement costs than it put in – the per-proposal gas allowance is deliberately the same 500 XRD. And because it is kept either way, it prices the act of putting the treasury on the agenda at all. 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 i…h a governed UPGRADE proposal.

How long does it take? A voti…separate call after that, and resolve plus execution together draw a single settlement-gas allowance from the treasury, so the whole settle path is funded by the fee that proposal banked and by no otherboth 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? Anyo…happen by declining to sign. Neither caller is out of pocket for doing it. Both paths are treated as public goods and both areBoth callers pay their own way, and that is a change. Until 11 September 2026 the treasury reimbursed each path contingently by the treasury, up to 5 XRD pera call against a 500 XRD per-proposal budget. Contingent is the operative word:A pen-test found the subsidy was wider than it looked: the Radix engine consumes locked fees in reverse lock order, so the treimbursement rides the transaction's own fee allowance, so a caller who aborts pays their own way and cannot drain the allowance by failing repeatedlyasury'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…replayed for a second helping.

Mechanic PAYOUT proposal (acti… cast; the market then gets a 48-hour window to veto by selling Window 48 hours fromThe market window, opened by the trigger (not fromat creation), then; when it closes anyone can resolve Legislati…n are all permissionless calls

A caper raises a treasury on a…ballot passes it – then sits open for 48 hoursut a window in whilech the market can still veto it …s, in the order people ask it.

Who controls the treasury? Th…ame fee, and survive the same 48 hourswindow of anyone being able to sell against it.

How do I get paid by a caper? …ess and your amount, it sits open for 48 hoursut the market window, and if the token's price is still holding when the window closesaverage price over that window holds at or above the baseline locked at the trigger the money is sent to you. You…oposal is the thing that pays.

How does the vote decide it? …al reads the caper’s trailing 7-day time-weighted average price, freezelocks it as the baseline, and starts a 48-hour clock. During those 48 hoursopens the market window. During the window nothing is collected. What ho…he verdict expensive to fake: manipulation costs displacement multiplied by durationa displacement has to be held for a real share of the window, so an atomic buy→resolve→sel…ed if the facts change in the two dayswindow before it executes. This is t…posal through unconditionally.

How long does it take? A voting period, then 48 hoursthe market window, then a short chain of permis…eriod is VOTING_PERIOD_SECONDS, currently 600 seconds i – on the deployed logic – that is drill tuning for the … anyone cranks the tally. The optimisticmarket window is fixed at PROPOSAL_WINDOW_SECONDS = 172,800 – 48 hours – and the baseline is sampled over TWAP_WINDOW_SECONDS = 604,800, seven days, 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 configu…e where the clock starts: the 48 hourswindow runs from the trigger, not from cr…oposal banked and by no other.

How does the vote decide it? …lot, 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 (/wiki/dao-governance/concepts/voting/ranked-and-alternative-ballot-methods) ). If the leader is the “Do noth…posal through unconditionally.

How do I pay someone from a ca…he five things a proposal can doexecute, and it is the only one that …roposal or it does not happen.

What else can a proposal do? Paying is one of five executable action kinds, all raised the s…settled by the same price test – and there is a sixth that is settled by neither, because it executes nothing: - PAYOUT (kind 0) – transfe…d no proposal can reach them. 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- 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 "w…adable on each caper's ledger.

How do I pay someone from a ca…oposal, which is exactly the fee floorlat fee that proposal already banked.…roposal or it does not happen.

How do I propose a payment, an…ays, applied to the fee. The flat 500 XRD floor exists for two reasons. It has…h a governed UPGRADE proposal.

Mechanic PAYOUT proposal (acti…lding at least 1 of that caper'’s governance tokens Who can r…t only XRD How it is decided No ballot. The market: it passes iff spot price at resolution is at or above the 7-day TWAP locked at creationTwo phases. A ranked ballot must clear a supermajority of 1.5 / option_count of the weight cast; the market then gets a 48-hour window to veto by selling Window 48 hours from the trigger (not from creation), then anyone can resolve Fee max(500 XRD, Legislative fee 500 XRD flat, banked at creation and kept whether it passes or fails Ballot fee 100 XRD per ranked ballot, into the caper’s own treasury; mints 1 soulbound v Execution fee 10% of the payout'’s XRD value), banked at creationdue at the trigger – and kept0 when ther it passes or fails ballot chose “treasury pays” Who executes Anyone. RTally, trigger, resolution and execution are all permissionless calls

A caper raises a treasury on a…ent, a currency and an amount, is ranked by members on a ballot, and – if the ballot passes it – then sits open for 48 hours while the market can object still veto it by selling, and thenbefore it moves the money itself. No mu…s, in the order people ask it.

How do I propose a payment, an…d to? Any holder of the caper'’s governance token. The contract'’s check is deliberately low: i…eaches the treasury. The fee is max(500 XRD, 10% of the action's XRD-equivalent amount), paid in XRD at creation and banked by the caper rather than burned. The percentage leg is the part people miss: a payout of 50,000 XRD costs 5,000 XRD to propose, not 500. Non-XRD amounts are converted at the relevant curve's spot price when the proposal is raised. Whatever you send above the fee is handed straight back. The feemodel 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 spot at that moment rather than at creation. 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 – the 0.01 v-per-XRD rate that trading pays, applied to the fee. The 500 XRD floor exists for two reasons. It ha…r force somebody to spend, so that a proposal can never draw more…ettlement costs than it put in – the per-proposal gas allowance is deliberately the same 500 XRD. And because it is kept wheither the proposal passes or failsway, it prices the act of putting the treasury at risk – which under an optimistic model, where nobody has to show up to approve anything, is the only cost a bad proposal carries up front. Neitheron the agenda at all. None of the three figures is a lever. BothAll are constants compiled into the platform'’s logic package (PROPOSAL_FEE_MIN and PROPOSAL_FEE_RATE), and the deployed CaperMain exposes no setter for any of them. Changing eitherone means publishing a fresh logi…ponent and moving the registry'’s current_main to it through a governed UPGRADE proposal.

How does the vote decide it? It doesn't – there is no voteecides half of it. A caper settles proposals against itsin two phases: members legislate own market, and the procedure has three moving parts. At creaa 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, the contract reads the trailing 7-day time-weighted average price of the caper's token and freezes itone 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 onf the proposal as a baseline. It also stamps a window that closes 48 hours later. During the window, nothing is collected. Holdweight actually cast clears a supermajority of 1.5 / option_count: 75% on a two-option ballot, 30% on a five-option one. 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 are not asked for anythtrailing 7-day time-weighted average price, freezes it as the baselinge, and no ballot exists to submitstarts a 48-hour clock. During those 48 hours nothing is collected. What holders can do is trade. S: selling pushes the spot price down the curve;, buying pushes it up. After t…can call resolve_proposal. It reads the live spot price once and compares it to the frozenintegrates 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. Spot aAt or above baseline, and, the proposal has passed. Below, and it has failed. The consequence is worth stating Integrating rather than samplainly, because it inverts the assumption almost every DAO document carries: silence is assent. A proposal that nobody notices passes. A proposal that everybody privately dislikes passes too, unless enough of them sell to move the price under the baseline before the window shuts. Objecting is not free, and it is not meant to be –g is what makes the verdict expensive to fake: manipulation costs displacement multiplied by duration, 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 give upsell their position over it, which is the same set of people who bear the cost if the spend is bad. That design buys three things a ballot cannot. There is no quorum to fail, so a caper with a distracted membership still functions 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 there is no ballot to buy – a would-be vote-buyer has tobuying the second phase means buying the token itself, at which point they are exposed to the outcome. And tnd holding it through the window. The signal is continuous rather than a snapshot: the price at resolutionwindow reflects everything the market learned during the windowafter the vote, including anything the proposal'’s author did not disclose. What it costs is symmetrical. A holder who wants to stop a payout must sell, and selling is precisely what a holder who believes in the caper does not want to do. Small, uncontroversial proposals therefore pass almost automatically, and that is the intended behaviour rather than a gap. The check on a large one is that a large one moves the price by itself once the market prices the spend And a decision that was right when it was taken can still be stopped if the facts change in the two days before it executes. This is the trade-off covere…voting/optimistic-governance) , and it is – the same family as the delay-and-veto model UMA'’s oSnap popularised –, with a market rather than a b…, so it cannot take proposals at all through this path. create_prop…ght, because a baseline and a spotprice that both read zero would passwave every proposal through unconditionally.

How long does it take? 48 hours, then two permissionless calls. TheA voting period, then 48 hours, then a short chain of permissionless calls. The voting period is VOTING_PERIOD_SECONDS, currently 600 seconds in 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 optimistic window is fixed at PROPOSAL_WINDOW_SECONDS = 172,800 in the logic package,– 48 hours – and the baseline is sampled o… TWAP_WINDOW_SECONDS = 604,800 –, seven days. Neitherone of the three is configurable at runtime; bothall are compiled in, and retuning… The proposal carries its own creation timestamp and window end date once triggered, so you can read the exact de…al rather than computing it. Once the windowNote where the clock starts: the 48 hours run 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 …in – the frozen baseline, the spot price it reawindow TWAP it computed, and the pass flag – and emi…separate call after that, and the tworesolve plus execution together draw a single settle…oposal banked and by no other.

What if the proposal fails? Nothing moves. Resolution writes a pass flag onto the proposal, 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 spot price it reawindow 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 isare once-only, so a proposal that…ng a fresh one and paying the fee500 XRD again. The proposallegislative fee stays with the caper eith… 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.

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.

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

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.

Related - What is a caper (/wiki/foundations/what-is-a-caper) — the object this treasury belongs to - Getting started (/wiki/foundations/getting-started) — starting one, and what it costs - Leaving a caper (/wiki/foundations/leaving-a-caper) — the other way value leaves a treasury - Querying a caper from an AI agent (/wiki/foundations/querying-a-caper-from-an-ai-agent) — reading a caper's proposals and payouts programmatically - DAO contributor compensation (/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) — how the wider industry pays people

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, sits open for 48 hours while the market can object to it by selling, 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.

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 48 hours of anyone being able to sell against it.

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 open for 48 hours, and if the token's price is still holding when the window closes 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.

What if the proposal fails? Nothing moves. Resolution writes a pass flag onto the proposal alongside the baseline and the spot price it read, and every execution path binds that flag: a proposal resolved false cannot be executed, then or ever. There is no retry and no second window – resolution is once-only, so a proposal that failed is finished, and getting the payment through means raising a fresh one and paying the fee again. The proposal 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.

Related - What is a caper (/wiki/foundations/what-is-a-caper) – the object this treasury belongs to - Getting started (/wiki/foundations/getting-started) – starting one, and what it costs - Leaving a caper (/wiki/foundations/leaving-a-caper) – the other way value leaves a treasury - Querying a caper from an AI agent (/wiki/foundations/querying-a-caper-from-an-ai-agent) – reading a caper's proposals and payouts programmatically - Optimistic governance (/wiki/dao-governance/concepts/voting/optimistic-governance) – the wider family this settlement model belongs to - DAO contributor compensation (/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) – how the wider industry pays people

Mechanic PAYOUT proposal (option kind 0) Contract method execute_proposal_payout (contracts/logic/src/lib.rs) Who can propose Anyone holding at least 1 of that caper's governance tokens Who can receive Any Radix account — membership not required What can be paid Any resource the treasury holds, not only XRD Ballot Ranked, Borda-counted, 2 to 12 options Bar to pass 1.5 ÷ number of options, as a share of the weight cast Who executes Anyone. Settlement and execution are permissionless calls

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 (/wiki/foundations/leaving-a-caper) . Everything else is a proposal or it does not happen.

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 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. The raw figure falls as the ballot grows, and that is the part people misread: - 2 options → the winner needs 75% of the weight - 3 options → 50% - 4 options → 37.5% It does not get easier. Every ballot has to rank every option, so adding options spreads the same points over a bigger pool, and the most any single option can take of that pool is 2 ÷ N – reached only when every voter ranks it first. The 1.5 ÷ N bar is three-quarters of that ceiling at every ballot size. Put in members rather than points: where the voters who do not back your option rank it last, it takes 75% of the weight ranking it first to carry, whether the ballot has two options or six. What extra options change is the field rather than the bar – they open room for a compromise option nobody led with, which is derived on how voting works (/wiki/governance/voting) . 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 (/wiki/governance/voting) 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 finalize_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 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.

Mechanic PAYOUT proposal (action kind 0) Contract method execute_proposal_payout (contracts/logic/src/lib.rs) Who can propose Anyone holding at least 1 of that caper's governance tokens Who can receive Any Radix account – membership not required What can be paid Any resource the treasury holds, not only XRD How it is decided No ballot. The market: it passes iff spot price at resolution is at or above the 7-day TWAP locked at creation Window 48 hours from creation, then anyone can resolve Fee max(500 XRD, 10% of the payout's XRD value), banked at creation and kept whether it passes or fails Who executes Anyone. Resolution and execution are permissionless calls

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 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, a member exercising the exit right (/wiki/foundations/leaving-a-caper) , and a contingent reimbursement of the gas spent resolving or executing a proposal – capped at 500 XRD per proposal, which is exactly the fee floor that proposal already banked. Everything else is a proposal or it does not happen.

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 is max(500 XRD, 10% of the action's XRD-equivalent amount), paid in XRD at creation and banked by the caper rather than burned. The percentage leg is the part people miss: a payout of 50,000 XRD costs 5,000 XRD to propose, not 500. Non-XRD amounts are converted at the relevant curve's spot price when the proposal is raised. Whatever you send above the fee is handed straight back. The fee exists for two reasons. It has to cover the settlement gas the proposal will later force somebody to spend, so that a proposal can never draw more out of the treasury in settlement costs than it put in. And because it is kept whether the proposal passes or fails, it prices the act of putting the treasury at risk – which under an optimistic model, where nobody has to show up to approve anything, is the only cost a bad proposal carries up front. Neither figure is a lever. Both are constants compiled into the platform's logic package (PROPOSAL_FEE_MIN and PROPOSAL_FEE_RATE), and the deployed CaperMain exposes no setter for them. Changing either means publishing a fresh logic component and moving the registry's current_main to it through a governed UPGRADE proposal.

How does the vote decide it? It doesn't – there is no vote. A caper settles proposals against its own market, and the procedure has three moving parts. At creation, the contract reads the trailing 7-day time-weighted average price of the caper's token and freezes it on the proposal as a baseline. It also stamps a window that closes 48 hours later. During the window, nothing is collected. Holders are not asked for anything, and no ballot exists to submit. What holders can do is trade. Selling pushes the spot price down the curve; buying pushes it up. After the window closes, anyone can call resolve_proposal. It reads the live spot price once and compares it to the frozen baseline. Spot at or above baseline, and the proposal has passed. Below, and it has failed. The consequence is worth stating plainly, because it inverts the assumption almost every DAO document carries: silence is assent. A proposal that nobody notices passes. A proposal that everybody privately dislikes passes too, unless enough of them sell to move the price under the baseline before the window shuts. Objecting is not free, and it is not meant to be – the only people who can block a spend are the people willing to give up their position over it, which is the same set of people who bear the cost if the spend is bad. That design buys three things a ballot cannot. There is no quorum to fail, so a caper with a distracted membership still functions. There is nothing to bribe, because there is no ballot to buy – a would-be vote-buyer has to buy the token itself, at which point they are exposed to the outcome. And the signal is continuous rather than a snapshot: the price at resolution reflects everything the market learned during the window, including anything the proposal's author did not disclose. What it costs is symmetrical. A holder who wants to stop a payout must sell, and selling is precisely what a holder who believes in the caper does not want to do. Small, uncontroversial proposals therefore pass almost automatically, and that is the intended behaviour rather than a gap. The check on a large one is that a large one moves the price by itself once the market prices the spend. This is the trade-off covered in optimistic governance (/wiki/dao-governance/concepts/voting/optimistic-governance) , and it is 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 structural exclusion follows from all of it: the $CAPER caper itself has no curve to price, so it cannot take proposals at all through this path. create_proposal rejects the $XRD cashtag outright, because a baseline and a spot that both read zero would pass every proposal unconditionally.

How long does it take? 48 hours, then two permissionless calls. The window is fixed at PROPOSAL_WINDOW_SECONDS = 172,800 in the logic package, and the baseline is sampled over TWAP_WINDOW_SECONDS = 604,800 – seven days. Neither is configurable at runtime; both are compiled in, and retuning them means a new logic component and a governed swap. The proposal carries its own creation timestamp and window end date, so you can read the exact deadline off the proposal rather than computing it. Once the window has closed, resolve_proposal records the verdict on-chain – the frozen baseline, the spot price it read, 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 the two together draw a single settlement-gas allowance from the treasury, so the whole settle path is funded by the fee that proposal banked and by no other.

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. Neither caller is out of pocket for doing it. Both paths are treated as public goods and both are reimbursed contingently by the treasury, up to 5 XRD per call against a 500 XRD per-proposal budget. Contingent is the operative word: the reimbursement rides the transaction's own fee allowance, so a caller who aborts pays their own way and cannot drain the allowance by failing repeatedly. 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 else can a proposal do? Paying is one of five action kinds, all raised the same way and all settled by the same price test: - 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. 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. 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.

Who actually presses go? Anyone. Both settlfinalize_proposal and execute_proposa…replayed for a second helping.

How does the vote decide it? ….5 ÷ the number of options. That bar moves with the shape ofe raw figure falls as the ballot grows, and ithat is worth understanding before you write onethe part people misread: - 2 options → the winner ne…s → 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 lowIt does not get easier. Every ballot has to rank every option, so adding options spreads the same points over a bigger pool, and the most any single option can take of that pool is 2 ÷ N – reached only when every voter ranks it first. The 1.5 ÷ N bar is three-quarters of that ceiling at every ballot size. Put in members rather than points: where the voters who do not back your option rank it last, it takes 75% of the weight ranking it first to carry, whethers the bar rather than raising itllot has two options or six. What extra options change is the field rather than the bar – they open room for a compromise option nobody led with, which is derived on how voting works (/wiki/governance/voting) . There is no separate turnout…own ballot. It cannot grow it.

Mechanic PAYOUT proposal (option kind 0) Contract method execute_proposal_payout (contracts/logic/src/lib.rs) Who can propose Anyone holding at least 1 of that caper's governance tokens Who can receive Any Radix account — membership not required What can be paid Any resource the treasury holds, not only XRD Ballot Ranked, Borda-counted, 2 to 12 options Bar to pass 1.5 ÷ number of options, as a share of the weight cast Who executes Anyone. Settlement and execution are permissionless calls

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.

Can I pay someone from a caper's treasury? Yes, 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 (/wiki/foundations/leaving-a-caper) . Everything else is a proposal or it does not happen.

Who is allowed to propose a payment? 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.

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 (/wiki/governance/voting) 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 (/wiki/foundations/what-is-a-caper) — the object this treasury belongs to - Getting started (/wiki/foundations/getting-started) — starting one, and what it costs - Leaving a caper (/wiki/foundations/leaving-a-caper) — the other way value leaves a treasury - Querying a caper from an AI agent (/wiki/foundations/querying-a-caper-from-an-ai-agent) — reading a caper's proposals and payouts programmatically - DAO contributor compensation (/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) — how the wider industry pays people

Mechanic PAYOUT proposal (option kind 0) Contract method execute_proposal_payout (contracts/logic/src/lib.rs) Who can propose Anyone holding at least 1 of that caper's governance tokens Who can receive Any Radix account — membership not required What can be paid Any resource the treasury holds, not only XRD Ballot Ranked, Borda-counted, 2 to 12 options Bar to pass 1.5 ÷ number of options, as a share of the weight cast Who executes Anyone. Settlement and execution are permissionless calls

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 (/wiki/foundations/leaving-a-caper) . 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 (/wiki/governance/voting) 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 (/wiki/foundations/what-is-a-caper) — the object this treasury belongs to - Getting started (/wiki/foundations/getting-started) — starting one, and what it costs - Leaving a caper (/wiki/foundations/leaving-a-caper) — the other way value leaves a treasury - Querying a caper from an AI agent (/wiki/foundations/querying-a-caper-from-an-ai-agent) — reading a caper's proposals and payouts programmatically - DAO contributor compensation (/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) — how the wider industry pays people

Mechanic PAYOUT proposal (option kind 0) Contract method execute_proposal_payout (contracts/logic/src/lib.rs) Who can propose Anyone holding at least 1 of that caper's governance tokens Who can receive Any Radix account — membership not required What can be paid Any resource the treasury holds, not only XRD Ballot Ranked, Borda-counted, 2 to 12 options Bar to pass 1.5 ÷ number of options, as a share of the weight cast Who executes Anyone. Settlement and execution are permissionless calls

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.

Can I pay someone from a caper's treasury? Yes, 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 (/wiki/foundations/leaving-a-caper) . Everything else is a proposal or it does not happen.

Who is allowed to propose a payment? 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.

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 (/wiki/governance/voting) 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 (/wiki/foundations/what-is-a-caper) — the object this treasury belongs to - Getting started (/wiki/foundations/getting-started) — starting one, and what it costs - Leaving a caper (/wiki/foundations/leaving-a-caper) — the other way value leaves a treasury - Querying a caper from an AI agent (/wiki/foundations/querying-a-caper-from-an-ai-agent) — reading a caper's proposals and payouts programmatically - DAO contributor compensation (/wiki/dao-governance/concepts/treasury/dao-contributor-compensation) — how the wider industry pays people