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, exit and the two address reads.

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. The $XRD caper, which refused every proposal until 11 September 2026, now takes them: with no curve its baseline and window averages are both zero, the tie passes, so its second phase is a formality and the ballot alone decides, weighed in native XRD (contracts/PENTEST.md, I-1). 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?

Your tokens go back into the inventory vault and your XRD comes out of the curve vault, priced along the same curve. The protocol does not burn anything on sell.

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, which prices the execution fee, 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?

Two payments, at two different moments. At creation, a flat 500 XRD proposal fee, banked irrevocably into the caper's own treasury and kept whether the proposal passes or fails – it is the spam gate, and since 11 September 2026 that is all it is. Until then it 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.

Then, at the trigger, an execution fee of 10% of the winning action's XRD-equivalent value, priced off the curve's trailing time-weighted average rather than its spot – the same read that locks the pass baseline, so a dump in the triggering transaction cannot shrink it: a PAYOUT in a caper token converts at the issuing caper's trailing average, an INVEST is XRD already, a DIVEST is priced at the target's trailing average, and UPGRADE and METADATA name no amount, so their basis is zero and the trigger is free either way. Who pays it is the ballot's second question: every ballot also votes proposer-pays or treasury-pays, settled by plain weight majority, and a tie is a treasury waiver. Treasury-pays nets to nothing, because the fee's sink is the caper's own treasury, so a treasury-pays trigger costs the caller nothing and stays fully permissionless.

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 never reaches a trigger, so it never incurs the 10% execution fee, and the flat 500 XRD creation fee 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 that holds 1/31 of the token leg of every caper's per-buy skim – a small standing position in every caper on the platform. 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, withdraws both from the account the payout goes to, and aborts the call ("Exit requires vote tokens") rather than paying out zero. Taking both from one account is also new on 11 September 2026: the earlier call accepted two buckets, which let one account's vote tokens 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?

Three, and each is paid at the point of use. The 0.5% trade fee on every buy and sell; the 100 XRD vote fee, charged per ballot and deposited into the caper's treasury at the moment of the cast; and the proposal fees above – 500 XRD flat at creation and 10% of the winning action at the trigger. Where they land differs by leg: the proposal fee, the vote fee and the buy leg of the trade fee are deposited into the caper's own treasury, while the sell leg is not – it accrues to the root $XRD caper, which collects every sell, swap and exit fee on the platform. 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. trade_fee (0.005), vote_fee (100), collateralization_peak (0.15), proposal_fee (500) and proposal_fee_rate (0.1) 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, and it is worth separating. Every buy is also skimmed for the caper's founder and the Caper Commons (above) in a 30:1 split, taken partly in XRD off the payment and partly as a slice of the tokens the buy mints. It never touches the caper's treasury, so it is not a protocol fee – it is the founder's compensation. Its rate, set by the bonding curve's collateralization schedule, is front-loaded: it starts at the peak when circulation is zero and tapers linearly to zero at 30% of the curve cap, after which buys are not skimmed at all. The rate falling does not mean the amount falls with it – a smaller share of much larger buys can still be more money. 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. The one token this cannot reach is $XRD, which has no curve of its own.

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. 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.