Anyone deciding whether to put money into a caper asks the same question first, in one wording or another: can the founder run away with the money? This page answers it from the contracts rather than from a promise. It goes through what a founder can take, what they cannot reach, and, at the end, what none of this protects you from.

Can a founder rug a caper?

A rug pull has a specific shape. The team holds a large allocation or a mint key, waits for buyers to arrive, then sells into them or issues themselves more supply until the price collapses and the pool is drained. It needs two things: supply the team can create or hold back, and a pot of buyer money the team can reach.

A caper is built so that neither exists. The token supply is minted once and can never grow. The money buyers pay is held in a reserve vault that no method can withdraw from except a sale back along the curve. What stops the founder is not a vesting schedule or a multisig convention. It is that the code contains no function that would do it.

Where does the money go when someone buys?

A buy splits four ways, and the split is performed in one call so no leg can be skipped (buy_apply in contracts/core/src/caper_dao.rs).

• The trade fee is taken off the gross payment and deposited into the caper's own treasury – the pot its members vote on. It does not go to the founder.
• The founder's XRD slice is taken off the same gross payment as the fee, alongside it rather than after it, and put into a separate founder_vault, with the amount recorded in founder_balance.
• Everything left goes into the curve vault. That is the reserve that pays out when somebody sells.
• The tokens come out of an inventory vault that already holds the entire supply. A slice goes to the founder's token vault, a smaller slice to the Commons, and the rest to the buyer.

A sell mirrors this (sell_apply, same file). The fee and the founder’s XRD slice both come off the gross payout, and the token slice comes out of the tokens the seller hands in. Those tokens change hands rather than retiring.

Who holds the funds, then, is a question with three answers: the reserve holds the bulk, the treasury holds the fee, and the founder's two vaults hold the skim. They are separate vaults with separate access rules, and that separation is what the rest of this page rests on.

Can the founder mint more tokens?

No. The full supply – 100 billion, the same for every caper (CURVE_CAP, contracts/common/src/lib.rs:22) – is minted once at creation into the inventory vault, and the resource is built with no mint role and no burn role at all (the ResourceBuilder in CaperDao::new, contracts/core/src/caper_dao.rs). The comment in the source states the reason plainly: it is the load-bearing guarantee, and it holds even against a future version of the protocol's own logic.

The same construction closes two adjacent doors. The resource is created with OwnerRole::None, and the builder sets no freeze role and no recall role, so there is no owner who could add either later. Nobody can freeze your tokens in your account, and nobody can claw them back out of it.

What is the founder's cut, and what caps it?

The founder is paid a collateralization fee on every trade, buys and sells alike. It is split in the curve's own composition: two thirds in XRD, taken off the trade's gross, and one third as a slice of the tokens the trade moves (the mint on a buy, the tokens handed in on a sell). The token slice is tithed 30:1 between the founder and the Commons (RESERVE_NUM, TITHE_NUM and collateralization_rate in contracts/logic/src/lib.rs).

Two properties bound it. The rate tapers to zero: it is at its peak when circulation is zero and falls linearly to nothing at 30% of the supply sold, after which the founder is paid nothing on any further trade (collateralization_rate against COLLATERALIZATION_TAPER_END, contracts/logic/src/lib.rs). And the peak is not a per-caper setting at all: collateralization_peak is written as 0.075 when the shared logic component is instantiated and there is no method that rewrites it (it was 0.15, charged on buys only, until the 15 September 2026 redeploy). At that peak the founder takes at most 5% of a trade’s gross in XRD (peak × 2/3) and at most peak × 1/3 × 30/31 of the tokens it moves, just under 2.5%. Those rates are the live values and the ceilings at once. No later call can raise them.

They cap the rate, though, not the total. Since the skim is charged on sells too, and a sell’s token slice moves existing tokens instead of retiring them, tokens that trade back and forth on a young curve pay the founder each time they move. No fixed share of the supply bounds what a founder can accumulate. The taper is what ends it.

Note what the taper does to the incentive. A founder earns most where a caper is smallest and nothing once it is established, which is the reverse of the schedule that makes founder dumping worth doing.

Can the founder sell their tokens?

Yes, and this is deliberate. The founder's slice is ordinary supply, the same token everyone else holds, taken off other people's trades, so it can be sold back along the same curve on the same terms as anybody else's. There is no privileged exit and no privileged price.

What the founder cannot do is take more than has accrued. Withdrawal runs through withdraw_founder (contracts/logic/src/lib.rs), which requires the caper's own founder badge and asserts the requested amount against the recorded balance on each leg (founder_take and founder_take_tokens, contracts/core/src/caper_dao.rs). Those two vaults are the founder's entire reach. There is no method anywhere on the component that moves XRD out of the curve reserve to a founder.

Who can spend the treasury? Can the team steal it?

The treasury's movement methods – treasury_withdraw, treasury_exit and the transfer inside execute_payout – are all restricted to the admin role (the roles block at the top of contracts/core/src/caper_dao.rs). The badge that satisfies that role is not held by the founder or by any member. It lives with the registry, which vends a transient proof only when the protocol's logic component calls authorize, and the proof is dropped at the end of the call.

So the question becomes: which of logic's methods spends the treasury on somebody's instruction? One does. execute_proposal_payout calls execute_payout, which binds the frozen action of a settled proposal, asserts that it is a payout, and transfers to the recipient, currency and amount stored when the proposal was created. It is once-only. The caller cannot substitute a recipient or an amount, because neither is a parameter – both are read from the settled proposal, which is why the source calls the transfer target "the STORED, proposed recipient".

The practical answer is that treasury money moves only when a proposal has settled as passed, and not otherwise. Settlement is two-phase, and a proposal has to clear both halves. The legislative half comes first: ballots are cast over the voting window and folded by Borda count, and the leading option has to take at least 1.5 divided by the number of options of the weight actually cast, without being the "do nothing" option. Then the optimistic half: a tallied proposal is triggered, which locks the trailing TWAP as a baseline at that moment – at the trigger, not at creation – and opens the market window, and the proposal passes only if the TWAP measured over that window itself comes in at or above the baseline (SettlementV4, contracts/common/src/lib.rs). The vote legislates and the market ratifies; neither alone moves the money. See proposals, execution and paying someone from a caper's treasury.

Can the founder change the fees or the rules?

No – and the reason is stronger than a permission check. Nobody can change them, founder or protocol admin. The deployed CaperMain exposes twenty-two public methods alongside its instantiation function – the trade paths, the proposal paths, exit, withdraw_founder and two address reads – and not one of them is a setter. The trade fee (0.005), the collateralization peak (0.075), the flat proposal fee (500 XRD) and the separate execution-fee rate (0.10), the vote fee (100 XRD) and all three governance windows are written into the component when it is instantiated and never assigned again. There is no vote-accrual rate among them: since the 11 September 2026 redeployment each ballot mints a fixed 1 v, a constant compiled into the logic rather than a field. The component this replaced did have a setter, update_fees, restricted to the protocol admin; it did not survive the August 2026 redeployment, and neither did the bounds it asserted, because there is no longer anything to bound.

Changing any of them therefore means publishing a fresh logic component and moving the whole platform onto it through an UPGRADE proposal in the $CAPER caper – a governed, visible, all-capers-at-once event, not a lever an admin pulls. The state tier that holds the vaults and the fixed supply is a separate, immutable package underneath it, which is why even that upgrade cannot reach the mint role that does not exist.

Can a caper be shut down?

No. Across the logic package's public surface there is no dissolve, delete or wind-up method, and none of the executive proposal kinds does it either. A caper has no off switch, so there is no version of this where a founder closes the thing and everyone else discovers the door is locked.

The way out is the exit right: any member who has cast a ranked ballot can hand back their vote tokens and governance tokens and take their weighted share of the treasury plus their sell-back along the curve, without a proposal and without anyone's approval. (exit requires a positive amount of v, withdrawn from the member's own account, and since the redeploy of 11 September 2026 the only member-facing source of v is a cast ballot – trading mints none, so having bought is no longer enough. Until that date it was.) The founder holds that right on exactly the same terms as everybody else, and cannot revoke anybody's – which now also means a founder who never votes has no exit either.

What happens if the founder leaves?

Nothing stops. The curve keeps quoting both sides, the treasury keeps paying out what proposals decide, and the exit right keeps working, because none of those paths passes through the founder. A founder who walks away takes whatever has accrued in their two vaults. What becomes of the future fee depends on what they do with the badge: abandoning it forfeits the stream, but the badge is a single, freely transferable bearer token, so they can instead sell it and be paid up front for the rest of the taper. Its ResourceBuilder in CaperDao::new sets no withdraw or deposit restriction, unlike the vote token a few lines below it, and founder_take_pair authorises on presentation of the badge alone (contracts/core/src/caper_dao.rs). Either way the caper carries on without them.

This is the structural difference from a project where the team is a dependency. There is nothing here that a founder has to keep doing for the mechanism to keep working.

What this does not protect you from

The guarantees above are narrow on purpose, and it is worth being exact about their edges.

• They say nothing about price. The curve will always quote a sell, but what it quotes depends on where circulation stands. You can exit at a loss.
• They say nothing about judgement. A treasury spent badly by a proposal nobody vetoed is spent as thoroughly as one taken. Governance protects you from theft, not from a decision going through because too few people were watching.
• They say nothing about what the caper is for. Whether the group does anything worth backing is a question about the people, and no contract answers it.
• They say nothing about who the founder is. The founder badge is a bearer instrument, and founder_take_pair authorises anyone presenting it, so the cut can change hands on a third-party venue with no proposal and no event on the platform. Nothing a holder owns is diluted by that sale – the skim is unchanged in size and in source – but the party collecting it need not be the person who launched the caper.
• They are guarantees of this logic component. The fee schedule cannot be edited, but the platform can be moved to a new logic component by an UPGRADE proposal in the $CAPER caper. What is immutable underneath any such move is the state tier: the fixed supply, the absent mint role and the vaults.

What the contracts do settle is the narrower thing: the founder cannot create supply, cannot reach the reserve, cannot spend the treasury without a settled proposal, and cannot stop you leaving. Everything else is ordinary risk, and it stays yours.

Related

• Buying into a caper – what you get, how the price is set, how to sell.
• Leaving a caper: the exit right – the full mechanic and its preconditions.
• Starting a personal caper – the same questions from the founder's side.
• Bonding curve – the reserve and the pricing function.
• Principal–agent problem – the general form of the problem this page is about.
• Token unlocks and vesting schedules – how the rest of the industry addresses it.