How does governance work?

In two phases, and both of them are on the deployed component. A proposal is legislated by a ranked vote and then ratified by the market: the ballot decides what the caper wants, and the price over the following window decides whether it actually happens. CaperMain's public surface makes the split legible – create_proposal, vote, crystallize_ballots and settle_proposal are phase one; trigger_proposal, resolve_proposal and the six execute_proposal_* paths are phase two – six methods for five executable kinds, because an UPGRADE executes in two legs (below). Alongside them sit the market and membership calls: buy_token, sell_token, swap, migrate, donate_collateral, create_caper, withdraw_founder and exit.

A correction, stated plainly, because this page carried the error. Between 26 and 28 August 2026 the platform ran a logic component with no vote call at all, and this FAQ described it accurately: proposals were resolved on price alone and trading was the only vote. That deployment was replaced on 29 August 2026, which reinstated ranked voting as a legislative phase in front of the optimistic one and kept the window-TWAP resolution. If you are reading older Caper material that says voting was removed, or that the vote fee "went with the ballots", it is describing the intervening deployment. Everything below is read off the live component and the source it was built from.

Why can't I open a proposal?

Most likely because the connected account holds none of that caper's token. create_proposal takes a proof of the caper's own governance token and asserts at least 1, so buying any meaningful amount on the curve clears the gate. The proposal's shape is asserted too: it must carry between 2 and 5 ranked options, at least one of them an answer other than the no-op – an executable action, or a debate position (below), and at least one of them a no-op – the contract rejects a slate without a "Do nothing" option by name, so a rejection is always votable. One further reason is structural rather than about your balance: an UPGRADE option is rejected anywhere but $CAPER. Each of those refusals arrives as a named message from the contract rather than a silent failure, and Why a transaction failed lists them all with what to do about each one.

The affordance itself is not a button called "create proposal". It is the GOVERN step in the lifecycle rail at the top of every page, which takes you to a caper, and the form there submits with SUBMIT PROPOSAL.

One correction, because this page carried the opposite answer for a few hours on 5 September 2026. Until that morning the create-proposal form’s sixth entry – “Debate topic (no execution)” – named a kind the deployed contract refused. The logic component then registered as current_main guarded creation with matches!(action.kind, 0 | 1 | 3 | 4 | 5), so a slate carrying a debate option aborted with “Unknown action kind (VOTE actions are retired)” – a message naming a long-retired feature the proposer never touched. A logic upgrade published at 09:36 UTC on 5 September 2026 closed the gap: the registry then at component_tdx_2_1cqtsx3p… resolved current_main to a component whose guard read matches!(action.kind, 0 | 1 | 3 | 4 | 5 | 6), and a debate option is accepted at creation. If you hit that abort before then, re-submit – nothing about your slate was wrong. What the kind does, and what it deliberately does not, is below.

What happens to the inventory vault when I sell?

Most of your tokens go back into the inventory vault, and your XRD comes out of the curve vault, priced along the same curve. Nothing is burned. The exception is the skim's token leg (below): while the skim is running, a slice of the tokens you sell goes to the founder and the Caper Commons and stays in circulation. The curve pays only for the tokens it takes back, and the skim's XRD leg comes out of that payout, split between the caper's treasury and the founder. Nothing else is charged. Since 15 September 2026 this also means selling can never bring a caper's circulation to zero.

Is there a minimum trade size?

Yes, on the buy side: a buy must be at least 0.001 XRD. There is no upper limit other than the curve's own cap of 100,000,000,000 tokens, which no buy may push past.

Can I withdraw governance tokens to another wallet?

Yes. Governance tokens are normal fungibles, and they are what your wallet trades on the curve. Vote tokens are different: they are soulbound and cannot be transferred between holders. They do two things, both on your own account – they carry half the weight of any ballot you cast, and they are what exit() withdraws and burns when you redeem.

How does a proposal pass?

It has to clear both phases, and either one can stop it.

Phase one, the ballot. From the moment a proposal is created, holders cast a full ranked permutation of its options – every option ranked, none twice – for a 100 XRD vote fee that is banked into the caper's own treasury. A ballot's weight is the same expression the exit uses, (t·v)/(V·T), snapshotted at the moment of the cast. When the voting window closes, anyone may crank crystallize_ballots to fold the ballots in chunks, and then settle_proposal freezes the verdict: the Borda leader passes if and only if its share of cast weight clears 1.5 / option_count and it is not the no-op. Two options therefore need 75% of cast weight, five need 30% — figures that only read correctly against their ceiling. Ballots are full rankings scored Borda-style (apply_borda gives rank i a multiplier of option_count - 1 - i), so the most any single option can take is 2 / option_count of the total weight: 100% on a two-option ballot, 40% on a five-option one. The bar is three quarters of that ceiling at every width, so widening the ballot does not soften it.

Phase two, the market. A legislative pass does not execute anything. Someone must call trigger_proposal – free, and open to any account – which locks a baseline – the time-weighted average price over the trailing baseline window – and opens the market window. After that window closes, resolve_proposal compares the TWAP over the window itself against the baseline locked at the trigger, and the proposal executes if and only if the window's average is at or above it. A pass does not wait indefinitely: the resolve stamps a deadline seven days out, and an execute call after it aborts with “Execution window closed”. All three window lengths are readable straight off the live component, as voting_period_in_seconds, proposal_window_in_seconds and twap_window_in_seconds – but only two of them are drill tuning. The constants’ own comments mark the voting period and the market window as Stokenet tuning that a production deployment retunes by shipping a new logic package; the trailing baseline is a designed constant, set deliberately longer than the market window so that a dump priced in during the vote still reads as a dump against it, and short enough that a trend does not decide the verdict by itself. Read the first two as drill figures. Do not read the third as one.

The consequence is the design: a vote is the caper telling the market what it intends to do, and the window after is the market's chance to price that intention. Doing nothing ratifies; the only way to defeat a proposal that has already won its ballot is to sell enough to hold the window's average below where the token had been trading. That is the optimistic shape applied to a market rather than to a veto window, bolted onto a conventional vote rather than replacing it. The wider design space is set out on quorum and threshold design.

So how do I vote against something?

Two ways now, and they bite at different moments. In phase one you rank the "Do nothing" option first, which is a real vote against rather than an abstention – the no-op can win the Borda count outright, and a leader that is the no-op fails by rule even if it clears the threshold. In phase two you sell, and the window's own TWAP is the tally. Selling after casting does not get you both: the crystallize crank clamps each ballot's stake to min(held at cast, balance now), so a holder who votes and then dumps has already shrunk the weight of their own ballot.

Is there a quorum?

No – and the distinction matters, because there is a threshold. Nothing counts turnout or measures participation against the electorate, so there is no minimum share of holders an attacker can price and go and buy. What the tally applies is a supermajority of cast weight: 1.5 / option_count, which is 75% with two options and 30% with five. A proposal on which one holder votes can clear that. The defence against a proposal nobody noticed is not the ballot – it is the second phase, where the market has the window to price it. Correspondingly, the attack to watch is on the price rather than on the ballot, since a thin, easily-moved curve is cheap to hold above its own trailing average. See DAO security and governance attacks.

What does it cost to open a proposal?

One payment, at creation: 1% of the largest option's XRD-equivalent value, with a floor of 500 XRD, banked irrevocably into the caper's own treasury and kept whether the proposal passes or fails. The largest option prices it because the winner is unknown until the tally, and pricing a smaller one would let a proposer pad a large ask with a cheap decoy, so any slate whose largest option is under 50,000 XRD pays the floor. A PAYOUT in a caper token converts at the issuing caper's trailing time-weighted average price rather than its spot, so a dump in the creating transaction cannot shrink the basis; a DIVEST converts at the target's trailing average, an INVEST is XRD already, and DEBATE, UPGRADE and METADATA name no amount, so they pay the floor. Send more than the fee and the change comes back in the same transaction. Nothing is due later: trigger_proposal takes no payment, for any kind.

Until 11 September 2026 the fee doubled as a settlement-gas allowance the treasury drew on to refund whoever cranked the settle path, up to 5 XRD a call; the pen-test fixes removed that allowance outright (contracts/PENTEST.md, L-2). Every crank is now paid for by whoever sends it, in that transaction's own network fee, and none draws on the treasury. From 29 August to 6 October 2026 the fee also came in two parts: a flat 500 XRD at creation, and a 10% execution fee on the winning action at the trigger, with every ballot voting on whether the proposer or the treasury paid it. It was dropped because neither answer worked: “treasury pays” was the treasury paying itself, “proposer pays” fell on whoever called the permissionless trigger, and a simple majority on the fee could stall an action that had already cleared the supermajority.

What can a proposal actually do?

Five things – and, since 5 September 2026, it can also decline to do anything at all, on purpose. The contract accepts six option kinds at creation, five of which execute, and every argument is frozen at creation. PAYOUT transfers from the treasury to a named account; INVEST spends treasury XRD buying another caper's token; DIVEST is INVEST run backwards (below); METADATA rewrites the mutable metadata of the caper's own token; and UPGRADE, on $CAPER only, swaps the platform logic for every caper at once. A slate may mix kinds across its options – the ballot picks one, and only the winner is ever executed. The discriminants of the five executable kinds are 0, 1, 3, 4 and 5; 6 is the non-executing sixth, DEBATE (below). The gap at 2 is deliberate: kind 2 was VOTE, which let one caper cast its treasury's ballot inside another. It was retired with the escrow voting system, did not come back with the ballots, and the number was left unused rather than recycled, so a proposal built against the old ABI aborts at creation. The numbering is spelled out in paying someone from a caper.

What is a debate proposal?

A question put to the caper that is settled by the ballot and goes no further. DEBATE (discriminant 6) is ranked alongside the executable options, it can win the Borda count outright, and there the proposal ends. The contract enforces the emptiness rather than trusting the form: creation asserts a debate option carries no currency, amount, recipient, target cashtag, target resource or candidate component – “DEBATE options carry no execution fields” – and trigger_proposal refuses a debate winner by name, “DEBATE options are terminal at the tally – nothing to trigger”, so a passed debate cannot park in a second phase it could never leave.

Two consequences follow, and both are practical. The first is cost: a debate names no amount, so it pays the 500 XRD floor at creation, and that is the whole price of putting a question to the caper. The second is that a passing slate no longer guarantees an action – the contract requires an answer other than “Do nothing”, and a debate position is one, so a slate of positions plus the no-op is valid and can pass without anything happening to the treasury. That is the point: a caper can now hold a vote whose entire output is a recorded verdict, without the optimistic window that exists to let the market veto spending.

What is the Caper Commons?

The protocol-wide treasury, which is $CAPER's own. It takes 0.5% of the skim on every buy and every sell of every caper, paid in that caper's own token, so it builds a small standing position in each of them. It also receives every registration fee. The rest of each skim goes to the traded caper's own treasury and its founder. Its policy is set by $CAPER governance.

How is my exit payout calculated?

When you call exit() you redeem a slice of the caper's treasury equal to (t·v)/(V·T) – t = governance tokens redeemed, v = your vote tokens, V = total vote-token supply, T = tokens in circulation. It is the same expression that weights a ballot. It is not a flat pro-rata claim on tokens alone: the contract requires both a positive governance-token amount and a positive vote-token amount, and aborts the call ("Exit requires vote tokens") rather than paying out zero. Both come from the account the payout goes to: since the redeploy of 21 September 2026 the transaction first calls exit_open, which records that account's vote-token balance, and exit accepts only the vote tokens the balance has lost since, so one account's vote tokens cannot be paired with another's governance tokens.

Where the v comes from. One surface, one amount. Casting a ballot mints you VOTE_MINT = 1 soulbound vote token, banked in the same call that banks the fee and appends the ballot. Nothing else mints any: buying, selling and swapping all mint zero, and so does a transfer in. Until the redeploy of 11 September 2026 trading minted v too, at a rate held on the logic component as vote_rate, and that field is now gone from the component and from the source. The practical consequence is that the exit opens only once you have cast a ballot.

Do I have to have voted to exit?

Yes, since 11 September 2026. exit() asserts a positive vote-token amount and aborts on "Exit requires vote tokens" rather than paying out zero, and casting a ballot is now the only way a member earns one. A holder who has only ever bought, sold, swapped or received a transfer holds none and cannot redeem a treasury share. They can still sell back on the curve, which draws on a different pool and needs no v – what they cannot reach is the treasury.

This answer was No on every earlier deployment, and a good deal of third-party writing about Caper still says so. The change closed a hole rather than adding a hurdle: while trades minted v, a single transaction could buy the position, mint the vote token off that same buy, and redeem on both – so the exit right was purchasable, and the trade fee was its price. Making the ballot the sole source prices it in participation instead. The fee is sunk, it is one ballot per account per proposal, and v is soulbound, so nobody can buy anybody else's.

When do vote tokens appear – at the cast, or after the count?

At the cast. vote() makes one fused call into the immortal state tier, and that call banks the fee, appends the ballot blob and mints the vote tokens in a single transaction – so the weight and the exit right are yours the moment the ballot is accepted, not when crystallize_ballots folds it or settle_proposal freezes the verdict. A pending ballot confers its exit right immediately. One ordering detail follows from it: vote() counts its own mint in both your balance and the supply it divides by, so a first ballot already weighs something. That ordering changed with the ballot becoming the sole source of v, and the code states the reason: if the snapshot were taken before the mint, every member's first ballot would score zero and no caper's first proposal could pass at all.

Does exit pay me anything besides XRD?

Yes, and it is worth checking before you confirm, because the vote burn is irreversible. The treasury share is paid in every resource the call names: XRD and the caper's own token always, plus any additional resources passed with it. The app fills that list with the caper tokens the treasury actually holds – positions an INVEST proposal bought in other capers, and on $CAPER the Caper Commons tithe collected from every caper on the platform (above) – so you leave with your percentage of those holdings too, not only the XRD. Two limits are disclosed in the exit dialog rather than hidden: the sweep is capped at 20 holdings, ranked by what each is worth if sold back on its own curve, and the dialog names how many of the smallest were left out – value you forfeit by exiting now.

What are the protocol fees?

Two, and each is paid at the point of use: the 100 XRD vote fee, charged per ballot and deposited into the caper's treasury at the moment of the cast; and the proposal fee above – 1% of the largest option at creation, at least 500 XRD. Both are deposited into the caper's own treasury. A trade pays no fee. The redeploy of 25 September 2026 removed the 0.5% trade fee, and a trade now pays only the skim (below), 49.5% of which goes to the traded caper's own treasury. That holds for the sell inside an exit and for both legs of a swap: the sell leg pays the sold caper's skim and the buy leg the bought caper's. See trading for how each one moves the vaults.

None of them has a setter. An earlier logic component exposed an update_fees call that let the protocol admin badge retune the levers in place; the deployed one does not expose it, or any other setter. vote_fee (100), collateralization_peak (1), proposal_fee (500) and proposal_fee_rate (0.01) are written once when the component is instantiated and are then fixed for its lifetime. They are still readable off the component, and reading them yourself is still the right way to check this page.

Can the windows change?

Only the same way the fees can: by deploying a new logic component and moving the registry's current_main onto it. The voting period, the market window and the trailing baseline window all sit on that component beside the fee fields with no setters of their own, so the admin badge cannot shorten a window that is already open. One caveat: the voting period and the market window on this Stokenet deployment are drill tuning – the constants' own comments say so – so do not read either live figure as the intended production one. The upgrade path is open to the protocol admin badge and to a settled $CAPER UPGRADE proposal, and carries no delay of its own on this deployment because the registry's upgrade_delay_seconds reads 0. That figure is fixed for the registry's life: since 11 September 2026 it is a constructor argument with no setter. Read any of these numbers yourself the way you would read the fees: resolve current_main on the registry, then read the fields off the component it names.

Is the collateralization skim a fee?

No. It is the one charge on a trade, and it is a rate on what the trade moves rather than a flat share. Since 15 September 2026 every trade is skimmed, buys and sells alike, and since 25 September 2026 nothing else is charged on a trade. Each trade reads one rate: a buy the rate where it starts, a sell the rate at the bottom it would reach if every token handed in retired. The rate only falls as the curve fills, so a trade pays at least what the same trade cut into pieces would, and never less than the rate's integral along the curve; from 18 September 2026 to 30 September 2026 the contract integrated that itself, so a trade cut into pieces paid exactly what it paid whole. It divides three ways: 49.5% to the traded caper's own treasury, in XRD; 50% to the founder, 90% of that in XRD and 10% in the caper's own token; and 0.5% to the Caper Commons (above), in tokens. So 94.5% of the skim is a share of the curve XRD the trade moves and 5.5% is a slice of the tokens it moves. At the peak of 1, on an empty curve, that is 94.5% of the curve XRD the trade moves and 5.5% of the tokens, of which the founder's part is 45% of the XRD and 5% of the tokens. Its rate, set by the bonding curve's collateralization schedule, is front-loaded: it starts at the peak when circulation is zero, is half the peak once 1.99% of the curve cap has sold and 1% of a trade by 21.4%, and halves again with every further fifth of the supply sold, so every trade is skimmed for the life of the caper. The rate falling does not mean the amount falls with it – a smaller share of much larger trades can still be more money. Before that redeploy only buys were skimmed, at a peak of 0.15. Raising funds works through it.

A caper I hold owns tokens in another caper. Can it sell them?

Yes, through a DIVEST proposal – an INVEST run backwards. A passing DIVEST withdraws a proposed amount of the target caper's token from this treasury, sells it into that caper's own bonding curve, and deposits the XRD proceeds straight back into this treasury.

Two details matter in practice. The amount is frozen at creation, so if the treasury's holding of that token has fallen below the proposed figure by the time someone executes, the call aborts rather than quietly selling less – executing a smaller trade than the one that passed would break the frozen-action rule the whole execution step rests on. And the sale is emitted as an ordinary sell on the target caper's trade feed, at the ordinary price convention, so a treasury divesting looks the same to the market as any other seller. It pays like one too: the sale pays the target caper's skim, so part of the payout goes to the target's treasury and founder, and part of the tokens to the target's founder and the Caper Commons.

Can a proposal change how the platform itself works?

Only on $CAPER. An UPGRADE action names a candidate logic component, and if it passes, two calls swap the platform logic for every caper at once: execute_proposal_upgrade proposes the candidate to the registry, and execute_proposal_upgrade_activate activates it. They are separate methods so that a network running a real upgrade timelock can hold the second leg back until the delay has run; on this deployment the registry’s upgrade_delay_seconds reads 0, so both legs fit in a single transaction and the split is invisible from outside. The contract enforces that restriction rather than leaving it to convention: an UPGRADE is rejected unless the caper putting it up is $CAPER itself, and rejected again unless the named candidate is a globalized component whose blueprint is called CaperMain. Since 11 September 2026 the second leg also activates only the candidate its own proposal voted for, and only if governance put it in the registry's pending slot: the slot records which path proposed it, and neither the admin badge nor a proposal may activate the other's. Since the redeploy of 6 October 2026 the second leg has a deadline of its own: it must run within seven days of the moment the candidate first becomes activatable (EXECUTION_WINDOW_SECONDS), or it aborts with “Activation window closed”. Before then only the first leg was bound by the proposal’s execution deadline, and a proposed candidate could sit in the pending slot indefinitely; the fix (contracts/PENTEST.md, H-4) entered the source on 1 October and reached the ledger with that redeploy. Why a transaction failed lists that message with the leg’s other two refusals. Individual capers govern their own treasuries; they do not each run their own version of the protocol.

The upside of that arrangement is reach. A change confined to the logic tier arrives at every caper that already exists, with no per-caper migration and nothing for a founder to opt into. The cost is the mirror image, and the history at the top of this page is the evidence: one deployment retired every caper's voting system at once, and the next reinstated it, and neither asked a single caper to migrate. Whatever the logic component says today is what every caper does today – which is why this page tells you to read it off the ledger rather than to trust the copy.

How do I know a page on this wiki is accurate?

By checking it, which is the point of the format. Every article is held to five published standards, and each one is itself a page you can read and hold an editor to: verifiability (the test for including a claim is whether a reader can check it against a source, not whether an editor believes it), no original research (reading a value off the ledger is description and is encouraged; extrapolating a prediction from it is not), neutral point of view, notability (what earns a standalone article rather than a mention inside a broader one), and freshness – an article that has gone 180 days without a re-verification renders a may be out of date notice at the top of itself until somebody checks its facts again.

Neutrality is the one worth stating plainly rather than assuming. This wiki is published by Caper and covers organisations that compete with Caper, which is a conflict of interest at the level of the whole wiki and not just a page. The answer to it is citation rather than a claim of disinterest: articles about other organisations describe them on their own terms and cite their own sources, and where one is compared to a caper the comparison is marked as such and the Caper mechanic links to the page that documents it, so the claim can be checked against the contract instead of the copy.