What happened to voting?

It was removed. The logic component this platform runs today has no vote call, no ballots, no tally and no veto window: the whole ranked-ballot system was replaced by optimistic, price-resolved proposals, in which trading is the vote. Read the deployed blueprint yourself and the absence is the first thing you see – CaperMain's public surface is buy_token, sell_token, swap, migrate, create_caper, create_proposal, resolve_proposal, the five execute_proposal_* paths, exit, withdraw_founder and the two address reads.

The component this replaced is still on the ledger and still readable, so the change is something you can diff rather than take on trust: the previous CaperMain exposes vote, claim_vote_mint, finalize_proposal, release_ballots, veto_params, update_veto and update_fees, and not one of them survives into the deployed one. If you are reading older Caper material that describes ranked ballots, a Borda count, a vote fee or a ten-minute voting window, it is describing that component. The mechanics below are the live ones.

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. Two other reasons are structural rather than about your balance: the $XRD caper cannot take proposals at all (it has no bonding curve, so there is no price signal to resolve against), and an UPGRADE proposal is rejected anywhere but $CAPER.

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 – labelled Propose an action — the market decides by trading – which takes you to a caper, and the form there submits with SUBMIT PROPOSAL.

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. Vote tokens are soulbound and cannot be transferred between holders, only withdrawn to your own worktop to feed exit() – see the exit question below, which is the only thing they now do.

How does a proposal pass, if nobody votes?

On price. When a proposal is created the contract locks a baseline: the time-weighted average price over the trailing seven days of the caper's sampled circulation, converted into price space. The proposal then sits open for a fixed 48-hour window. After the window closes, anyone may call resolve_proposal, and the rule is one comparison – the proposal passes if and only if the live spot price is at or above that baseline. Both windows are read straight off the live component as proposal_window_in_seconds = 172800 and twap_window_in_seconds = 604800.

The consequence is the design: holding is consent. Doing nothing passes a proposal, and the only way to defeat one is to sell enough of the caper's token to push the price below where it has been trading. That is the optimistic shape applied to a market rather than to a veto window: no turnout to organise, no quorum to price, and a dissenter's cost is the position they give up. What it trades away is protection against a proposal nobody notices – silence is a yes here, where in a quorum system silence is a no. The wider design space is set out on quorum and threshold design.

So how do I vote against something?

You sell. There is no other lever, and that is deliberate – the same act that expresses disapproval also removes the disapproving holder's exposure to the outcome. A caper's trade feed during an open proposal window is therefore the tally, and the price at the moment of resolution is the result.

Is there a quorum?

No, and there is no turnout at all – the concept does not apply. Nothing counts participants, so there is no minimum share of the electorate an attacker can price and go and buy. The corresponding attack here is on the price rather than on the ballot: an attacker who can hold the spot above a caper's own trailing average for 48 hours can pass a proposal, which makes a thin, easily-moved curve the risk to watch. See DAO security and governance attacks.

What does it cost to open a proposal?

max(500 XRD, 10% of the action's XRD-equivalent value), paid into the caper's own treasury. The rate applies to what the action actually moves: a PAYOUT is converted at the issuing caper's spot, an INVEST is XRD already, a DIVEST is priced at the target's spot. UPGRADE and METADATA name no amount, so they pay the 500 XRD floor. That floor is not arbitrary – it is the per-proposal settlement-gas budget, the allowance the caper's own treasury draws on to pay the network fee when a stranger calls resolve_proposal or execute_proposal_*, up to 5 XRD per call. A proposal funds its own settlement out of what it banked and cannot bleed the treasury past that, which is how a proposal still gets resolved and executed when nobody is paid to care.

What can a proposal actually do?

Five things, and the kind is frozen at creation along with every argument. 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 sixth kind – VOTE, which let one caper cast a ballot inside another – was retired with the voting system and the contract now rejects it by name.

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 not a flat pro-rata claim on tokens alone: the contract requires both a non-empty governance-token bucket and a non-empty vote-token bucket, and aborts the call ("Exit requires vote tokens") rather than paying out zero.

One caveat, and it is a live one. Vote tokens used to be minted to you when a ballot you cast was released – that was the only mint path, and it died with the voting system. The primitive that mints them survives on the immortal state tier, admin-gated, and the contract source records it as currently uncalled with the replacement distribution a pending redesign. So on this deployment there is at present no way to acquire the v that exit() requires. This is documented here because it is what the deployed code does, not because it is the intended end state.

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, not three – the 100 XRD vote fee went with the ballots. What remains is the 0.5% trade fee on every buy and sell, and the proposal fee above. Where they land differs by leg: the proposal 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.

The other change is that the schedule no longer has a setter. The previous logic component exposed an update_fees call that let the protocol admin badge retune all four levers in place; the deployed one does not expose it, or any other setter. trade_fee (0.005), collateralization_peak (0.15), proposal_fee_min (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 proposal window change?

Only the same way the fees can: by deploying a new logic component and moving the registry's current_main onto it. The 48-hour proposal window and the seven-day TWAP window sit on that component beside the fee fields, with no setter of their own, so the admin badge cannot shorten the window a proposal sits open for. That upgrade path is open to the protocol admin badge and to a settled $CAPER UPGRADE proposal, and carries no delay of its own today because the registry's upgrade_delay_seconds reads 0. 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, one call swaps the platform logic for every caper at once. 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. 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 this page is evidence of it: one upgrade retired every caper's voting system at once.

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.