A caper is a fundraising vehicle as much as a governance one. Launching one costs a single transaction — and from that moment your project can take in money from anyone, anywhere. There are two sides to the flow of capital:

• Raising. Every buy on your bonding curve moves XRD in and tokens out to the buyer. While the caper is young, a slice of each trade accrues to you, the founder, paid in the curve's own composition — two thirds in XRD off the trade's gross, one third as a slice of the tokens the trade moves. Both land in badge-gated vaults you can withdraw from at any time, so your stake grows with demand instead of being fixed up front. Trade and proposal fees flow into your caper's treasury.
• Deploying. Treasury capital doesn't sit idle. A member opens a proposal to spend it, and spending clears two phases. The first is legislative: holders rank every option on one ballot – up to four answers, each an executable action or a debate position, plus a standing “do nothing” – each ballot weighted w = (t · v) / (V · T), and a Borda fold picks a leader that must clear a supermajority of 1.5 / option_count of the weight actually cast. A pass executes nothing by itself; where the winner is one of the five executable kinds it earns the right to a trigger, which opens the market window and locks the trailing TWAP at that moment as the baseline. Where the winner is a DEBATE position – the sixth option kind, live since 5 September 2026, which carries no execution fields and is asserted empty of them at creation – the proposal is terminal at the tally instead: trigger_proposal refuses a DEBATE winner by kind, so a question put to the members can be ranked, won and recorded without any second phase opening at all, and the flat creation fee is the whole cost of asking. The action goes through only if the window's own TWAP finishes at or above that line, so the vote legislates and the market ratifies: holding is consent, and only selling that holds the price down for a real share of the window vetoes what the ballot decided. PAYOUT sends XRD or tokens to a contributor, vendor, or cause; INVEST buys into another caper's curve and books the position back into your treasury; DIVEST sells that position back into the same curve and books the XRD, so a treasury can unwind a holding by the same route that acquired it.

Because the curve guarantees a market in both directions, there is always someone to raise from and a way for backers to exit. The raise never closes either, which makes a caper an open-end organization rather than a sequence of rounds.

The founder slice

Unlike a fixed founder allocation minted up front, a caper pays its founder out of curve activity. On each buy and each sell the protocol takes a collateralization slice sized by the curve's position, and splits it in the same proportions the curve itself is made of.

A bonding curve whose price rises as the n-th power of supply holds exactly 1/(n+1) of its market value as reserve. Caper's price is a square root of circulation at the origin, so n = ½ and the reserve fraction is two thirds: two thirds of a young caper's worth is XRD in the vault, one third is claim on buyers yet to arrive. The skim follows that line. Two thirds is skimmed in XRD off the gross of the trade – the payment on a buy, before it funds the curve, and the payout on a sell; one third is a slice of the tokens the trade moves – the mint on a buy, the tokens handed in on a sell – tithed 30/31 to the founder and 1/31 to the protocol-wide $CAPER treasury (the "Commons"). Both founder legs sit in badge-gated vaults you can withdraw from at any time. The gate is the founder badge, a single indivisible bearer token minted to you at creation, which founder_take_pair checks by resource address and nothing else (contracts/core/src/caper_dao.rs). It carries no transfer restriction, so the future stream is itself saleable — and losing the badge loses the cut.

Nothing about that ratio was chosen. The peak is: the live logic component stores collateralization_peak as 0.075, so the XRD leg peaks at 5% of a trade's gross and the token leg at 7.5% × ⅓ = 2.5% of the tokens it moves. Before the redeploy of 15 September 2026 the skim ran at twice that peak and on buys alone. The token leg then came only out of new mints, so a founder could never be handed more than 5% of their own coin. That ceiling is gone. A sell's token leg is not minted: it is a slice of the tokens the seller hands in, and it changes hands instead of retiring, so every round trip through a young curve pays the founder on the way in and again on the way out. Whoever churns a young caper pays for it; the founder's share of supply has no fixed cap. (A founder can also buy on the curve like anyone else.)

Crucially the slice is front-loaded, not perpetual: it tapers linearly from its configured peak at genesis down to zero once ~30% of the supply is in circulation. Past that point the skim itself is gone: collateralization_rate returns zero once 30% of the supply is sold, so neither founder leg nor the Commons tithe takes anything from a trade again. The 0.5% trade fee does not taper with it — on a buy, buy_token_raw takes it off the same gross payment the skim is priced on, so neither charge is computed from what the other left, and buy_apply deposits it into the caper's own treasury on every buy for the life of the caper. A sell pays it the same way, off the gross payout. So a mature caper charges no founder tax, but the curve is never quite the trader's only counterparty. This rewards the founder for the risky early bootstrap without imposing a permanent tax on a mature, liquid token. For vampire capers bound to an origin token the founder still earns this same per-trade slice; what differs is that holders of the origin token can migrate into the caper — a free mint that advances circulation without an XRD buy, with the resulting reserve gap backfilled by a fee on subsequent direct buys.

The two fee legs

Capers charge a 0.5% trade fee — a field written into the logic component when the platform is instantiated rather than a constant of the contract, and nothing can rewrite it in place. The deployed CaperMain exposes no fee setter of any kind, so changing the schedule means publishing a fresh logic component and moving the platform onto it through a governed UPGRADE proposal in the $CAPER caper. Both legs carry the same rate; they land in different places, and that is the distinction worth understanding:

• Buy-leg fee → your treasury. The 0.5% taken off each incoming XRD payment is deposited straight into your caper’s own treasury, alongside the governance fees members pay. Those are two-tier: a flat 500 XRD to open a proposal, banked at creation and kept whether it passes or fails, and a 10% execution fee on the winning action’s XRD basis — the amount sent for a PAYOUT, the XRD outlay for an INVEST, the position valued at the target caper’s trailing TWAP for a DIVEST — charged at the trigger rather than at creation, and priced off that three-day average rather than the spot price, because a dump in the same transaction as the trigger would otherwise set the basis it is charged on, and waived entirely when the ballot’s second question returns “treasury pays”. A DEBATE winner pays it in no case at all, having neither an XRD basis nor a trigger to be charged at. Each ranked ballot costs its voter a further 100 XRD, into the same treasury (see the FAQ).
• Sell-leg fee → the base $XRD caper. The 0.5% taken when someone sells back into the curve does not touch your caper — it accrues to the treasury of the protocol’s root $XRD caper (the base caper native-XRD holders migrate into), where its members claim it on the same participation-weighted terms as any other caper: each exit pays the canonical weight (t·v)/(V·T), and exit() withdraws a positive amount of v from the member’s own account alongside the governance tokens. That gate is a voting record and nothing else, and it became one on 11 September 2026. Until that date v was minted on three surfaces — 0.01 per XRD of gross value on the buyer’s outlay, the same on the seller’s gross curve payout, and one per ranked ballot — so anyone who had merely traded held some. The redeploy of that date removed the two trade-side surfaces and took the rate field with them: the deployed logic component’s on-ledger state carries no vote_rate at all, and VOTE_MINT is a flat 1 per ballot regardless of what the ballot cost. The reason is the exit right this very sentence describes — while trading minted v, one transaction could buy a position, mint the record that opens the exit, and redeem on both, which made a claim on the pooled sell-leg fees something a stranger could simply purchase. So what the assertion rules out now is anyone who has never cast a ballot. A share of this pool is bounded by participation rather than by capital, and buying $XRD is no longer a way to reach it. No one takes a flat pro-rata slice. So a caper earns from the buy-side demand it attracts, while sell-side churn flows out to the wider XRD holder base — distinct from the $CAPER commons, which is funded by the 1/31 founder-slice above.

The result is a treasury that grows with genuine buy-side interest, and empties only through a proposal that carried its ballot and that the market then declined to veto. For how the broader industry stewards what it raises — diversification, runway, and custody — see DAO treasury management.

Money that never touches the curve

A caper's treasury is not a vault buried inside the contract. It is a native Radix Account, created in the same launch transaction and owned by the treasury component itself — so no external party, founder included, holds the keys to it. The component around it is a thin gate: depositing is public, while withdrawing, transferring, paying an exit and casting the caper's vote elsewhere are each restricted to a treasury admin badge that never leaves the caper's own custody.

That asymmetry is the part worth planning around. Anyone can pay a caper directly. A freshly created account accepts deposits by default, so the treasury address takes XRD or any other token from a customer, a grant programme, a partner protocol, another caper's PAYOUT, or a plain wallet transfer — none of it routed through the bonding curve, none of it needing a proposal, and none of it minting a single token. Curve buys and fee legs are the inflows that arrive on their own; they are not the only ones a project can raise on. Revenue, donations and off-chain-negotiated funding all land the same way an ordinary payment does.

Because the vessel is a real account rather than a bespoke escrow, its address drops into ordinary Radix tooling without adaptation — it is what a payer's wallet sends to, what a locker stores to, and what an executive proposal's recipient field takes. And because every outbound path is badge-gated, money leaves a treasury in exactly two ways: an executed proposal, or a member exit.

Paying someone whose account can refuse

A PAYOUT does not deposit into its recipient. The treasury withdraws the voted amount and hands it to an account locker, asking it to try the direct deposit first. The distinction matters because on Radix an account can carry deposit rules that reject resources it has not opted into, and a plain deposit into such an account aborts the whole transaction. A DAO that pays grants, invoices or salaries to accounts it does not control would otherwise be one recipient's privacy setting away from an execution that cannot be completed.

Radix's own documentation frames the locker as the fire-and-forget pattern — "we'll try to send the package to your house, but if we can't, you'll have to come pick it up" — and it is the right shape for treasury spending precisely because it needs no prior coordination with the payee: no authorised-depositor badge, no allow-listing, no round trip before the vote. The payout lands straight in when the recipient accepts it, and waits in the locker to be claimed when they do not. Exits are paid through the same locker, so a departing member's claim cannot be blocked by their own deposit settings either.

What a public front door costs

A permissionless deposit is also a permissionless way to put junk in someone's treasury, and the contract pays for that openness in two explicit places. Both are worth knowing generally: they are the failure modes any treasury contract inherits the moment it lets strangers deposit and then loops over what it holds.

Nothing on-chain iterates the holdings. The treasury emits a one-off registration event the first time each new resource arrives, and indexers rebuild the balance sheet from that event stream plus the Gateway's view of the account. Redemption walks only the resource list its caller supplies — floored at XRD plus the caper's own token, then extended with the exiting member's own discovered holdings. The source states the reason plainly: iterating an on-chain registry would let anyone grow the per-exit loop without bound, and on the order of a hundred junk resources would push every exit past the cost-unit ceiling and brick redemption permanently. Bounded-by-caller loses nothing, because the off-chain manifest already supplies the live set.

Every exit leg rounds down to the resource's divisibility. A fractional amount of an indivisible token makes the withdrawal panic, and one panic aborts the entire exit — for every holder, not just the one who triggered it. An attacker arms that by depositing a single unit of a divisibility-zero token. Rounding each slice down means indivisible dust is skipped rather than fatal, which is a deliberate trade: a member's claim on odd dust is forfeited so that redemption itself cannot be turned off. For how the wider industry thinks about what a treasury ends up holding and who can put things there, see DAO treasury management.

The one caper whose denominator is a constant

Every caper divides an exiting member's claim by its own circulating supply. The root $XRD caper is the exception, and the reason is a property of XRD rather than a design choice: genesis creates XRD with track_total_supply: false, so its on-ledger total_supply() returns nothing on any network. There is no float to divide by.

So effective_circulation substitutes a fixed 24,000,000,000 — XRD's maximum supply, being the 12bn minted at genesis plus roughly 12bn released as network emissions over about 40 years. The invariant that matters is that the denominator must be at least the sum of every member's holdings, because that is what keeps the sum of all exit shares inside the treasury. The 24bn cap is the tightest constant that always satisfies it, since no set of members can ever hold more.

Erring high has two consequences worth knowing if you hold $XRD. Claims on the pooled sell-leg fees are conservative — divided by the cap rather than by the live float, so an exit pays less than a float-based split would and the treasury cannot be over-drawn. And the constant cannot distort governance: the denominator cancels out of the settle path's top_weight / total_weight ratio, so it moves how fast the treasury pays out and never which option wins. Both properties are read off effective_circulation and exit in contracts/logic/src/lib.rs.

Launching a caper

One transaction mints the token, treasury, and bonding curve and hands the founder a badge. The only cost is a registration fee that scales with how short — how rare — the ticker is, and it can start fresh or migrate an existing token.