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. Each trade pays a skim, largest while the caper is young, and half of it accrues to you, the founder: 90% of your half in XRD, at one rate read where the trade starts, and 10% 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. 49.5% of the skim goes to your caper's treasury in XRD and 0.5% to the
$CAPERtreasury in tokens; proposal and vote fees also go to 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 of1.5 / option_countof 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_proposalrefuses 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 500 XRD floor of the proposal 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 this skim between the founder, the caper's own treasury and the protocol-wide Commons.
The skim is paid 94.5% in XRD and 5.5% in tokens. 94.5% of the rate is charged in XRD – on every XRD the curve takes from a buy, out of the payment before it funds the curve, and on every XRD it pays out to a sell, out of the payout, at one rate the trade reads: a buy where it starts, a sell at the bottom it would reach if every token handed in retired. The rate only falls, so a trade pays at least what the same trade cut into pieces would (buy_leg and sell_leg, contracts/logic/src/lib.rs). It splits 11:10: 49.5% of the skim to the caper's own treasury and 45% to the founder. 5.5% is a slice of the tokens the trade moves – the mint on a buy, the tokens handed in on a sell – split 10:1: 5% of the skim to the founder and 0.5% 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.
The live logic component stores collateralization_peak as 1, so at the peak the founder takes at most 45% of the curve XRD a trade moves and 5% of the tokens it moves. Before the redeploy of 15 September 2026 the skim ran at a 0.15 peak and on buys alone, at 0.075 from then until the logic upgrade of 18 September 2026, and at 0.05 until the upgrade of 19 September 2026. 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. The buy leg alone still holds the founder under 5% of the tokens ever sold, about 0.165% once the whole supply has sold, but 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.)
The slice is front-loaded: collateralization_rate returns peak × (2% × x + 98% × (1 − s) × x10) for x = 2−s/20%, where s is the fraction of the supply in circulation, so the rate is 100% of a trade at genesis, half that once 1.99% of the supply has sold, 1% by 21.4%, and half of what is left with every further fifth sold, which the founder, the caper's treasury and the Commons take from every trade for the life of the caper. There is no other trade charge: buy_apply and sell_apply deposit the treasury's share into the caper's own treasury on every trade. So a mature caper pays its founder and its treasury a small fraction of what a young one does, and the curve is never quite the trader's only counterparty. This rewards the founder for the risky early bootstrap while keeping the charge on a mature, liquid token small. 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.
What the treasury takes in
Capers charge no trade fee: the skim is the only trade charge. Its peak rate is 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. A caper's treasury takes in:
- Skim share → your treasury. 49.5% of every trade's skim, in XRD, on buys and sells alike, is deposited straight into your caper’s own treasury, alongside the governance fees members pay. The proposal fee is paid once, at creation, and kept whether the proposal passes or fails: 1% of the largest option’s XRD basis, at least 500 XRD – 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. A token amount is priced off that three-day average rather than the spot price, because a dump in the same transaction as the proposal would otherwise set the basis it is charged on. A DEBATE, which has no XRD basis, pays the floor, and so does any slate whose largest option is under 50,000 XRD. Triggering a passed proposal costs nothing; until 6 October 2026 the trigger collected a 10% execution fee on the winning action, which the ballot could waive by voting “treasury pays”. Each ranked ballot costs its voter a further 100 XRD, into the same treasury (see the FAQ).
- No trade fee. Until the redeploy of 25 September 2026 every buy paid a 0.5% trade fee into the caper’s own treasury. Before 18 September a sell paid the same 0.5%, into the treasury of a root
$XRDcaper that pooled every sell, swap and exit fee on the platform. That caper was removed, and the sell-side fee went with it. The redeploy of 25 September 2026 removed the buy-side fee and gave each caper's treasury 49.5% of the skim instead.
The result is a treasury that grows with trading in either direction and pays out in two ways: through a proposal that carried its ballot and that the market then declined to veto, and through an exit, which pays a departing member a share of it set by their vote weight, with no vote at all (Leaving a caper). 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 the treasury's share of the skim every trade pays, 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.