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. A slice of each buy accrues to you, the founder, paid in the curve's own composition — two thirds in XRD off the payment, one third as a slice of the tokens that buy mints. 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 governance fees flow into your caper's treasury.
• Deploying. Treasury capital doesn't sit idle. Holders pass proposals to spend it — 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 vote 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 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 payment before it funds the curve; one third is a slice of the tokens that buy mints, 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.

Nothing about that ratio was chosen, and the founder's ceiling falls out of it. The token leg peaks at 15% × ⅓ = 5% of each mint, and because the slice is a fixed fraction of every mint, the founder's share of the coin is just the average of that fraction across the curve travelled — which cannot exceed its own peak. So the skim never grants a founder more than 5% of their own coin, on any path, with no vesting schedule or cliff enforcing it. The realised share starts just under 5% and decays as the caper grows: about 4% at a tenth of supply sold, under 1% near the top of the curve. (That bounds what the skim hands over, not what a founder may hold — they can 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 buy again. The 0.5% trade fee does not taper with it — buy_token_raw takes it off the gross payment before the skim is computed and independently of it, and buy_apply deposits it into the caper's own treasury on every buy for the life of the caper. So a mature caper charges no founder tax, but the curve is never quite the buyer'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-buy 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 – the configured rate rather than a constant of the contract, rewritable within [0, 10%] by the same update_fees call that sets the two governance fees below – but the two legs land in different places — a 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 proposal fee and vote fee members pay to create proposals and vote. Those two are configured fields rather than protocol constants — they start at 500 XRD and 100 XRD, and an admin rewrites them alongside the trade fee in a single update_fees call, so treat the figures as the current schedule (see the FAQ).
• Sell-leg fee → the base $XRD caper. The 0.5% taken when someone sells back into the curve doesn't 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 vote weight (t·v)/(V·T), and exit() asserts a non-empty bucket of vote tokens alongside the governance tokens, so a holder who never voted has no exit to take rather than a zero-valued one. 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 governance activity, deployed only by vote. 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.