You vote on a caper, and then the market gets a veto. A proposal carries between two and five ranked options, holders cast a ranked ballot weighted by (t·v)/(V·T), and a permissionless crank folds and settles them. If the Borda leader clears a 1.5 / option_count supermajority of cast weight and is not the "Do nothing" option, the proposal has passed legislatively – and still cannot execute. Where the winner is an executable action, someone must then trigger it, which locks the caper's trailing average price as a baseline and opens the market window. The action runs only if the average price over that window is at or above the baseline – with one caper inverted, the $XRD caper, which has no curve of its own and is judged against a basket instead. The vote legislates; the market ratifies. Where the winner is a DEBATE option – a ranked position with no action attached, added to the deployed logic on 5 September 2026 – the tally is the whole decision, and execution never begins.

A correction, because this page carried the opposite claim. Between 26 and 28 August 2026 the platform ran a logic component with no vote method at all, and this page described it accurately: there was no ballot, and trading was the only vote. That deployment was replaced on 29 August 2026, which reinstated ranked voting in front of the optimistic phase while keeping the window-TWAP resolution. The history section below sets out all three eras; everything above and below it is read off the live CaperMain and the source it was built from.

How a ballot works

Voting opens the moment a proposal is created and closes when its voting period elapses. To cast, you call vote with a full permutation of the option indices – every option ranked exactly once, which the contract asserts rather than accepting a partial ranking – and a 100 XRD vote fee that is deposited into the caper's own treasury. You must hold at least 1 of the caper's governance token; the contract reads your live balance at the moment of the cast rather than trusting a snapshot you supply.

Every ballot also carries a second question: who pays the execution fee if this proposal is triggered – the proposer, or the treasury. That one settles by plain weight majority, and a tie is a treasury waiver.

Counting takes one or two permissionless cranks, and since 11 September 2026 whoever cranks pays their own network fee – the reimbursement the proposal's fee used to fund was removed outright. crystallize_ballots folds ballots into the tally in chunks, cursor-driven, so a large electorate can be counted by a volley of concurrent transactions that each take a disjoint range. settle_proposal then freezes the verdict, and folds up to 60 ballots the volley has not reached (SINGLE_PASS_MAX_VOTERS) inline in that same call, so a proposal with 60 ballots or fewer needs only the one crank. The threshold it applies is a share of cast weight, not of the electorate: 1.5 / option_count, which is 75% with two options and 30% with five.

One detail decides whether a ballot can be gamed. The crank clamps each ballot's stake to min(held at cast, balance now), so casting and then selling shrinks the weight of your own ballot – you cannot vote a position you no longer hold. What it cannot do is stop you selling instead of voting, which is the second phase's job.

How vote tokens are earned

One surface, one amount. A ranked ballot mints its caster VOTE_MINT = 1 soulbound vote token, banked in the same call that banks the fee and appends the ballot. Nothing else mints any to a member. Buying, selling and swapping all mint zero, and a transfer in mints zero, so a position that arrived without a ballot behind it carries no v at all – and exit aborts without one.

The trade-side mint is recent history rather than ancient: until 11 September 2026 every buy and sell also minted v, at a flat rate the logic component held as vote_rate. The pen-test that preceded the redeploy found the reason it could not stay. Because a buy minted the v in the same transaction that opened the position, one transaction could acquire a stake, mint the record that prices the exit, and redeem on both – the exit right had a purchase price, and it was the trade fee. Removing the trade mint takes vote_rate with it; the field is gone from the source and from the deployed component, where the state now reads trade_fee, vote_fee, proposal_fee, proposal_fee_rate, collateralization_peak and the three windows. One field has been added since, at the redeploy of 15 September 2026: xrd_basket, the reference basket the $XRD caper's market phase is priced against – state rather than a bare constant, so which market judges the platform's fee sink is readable off the gateway.

What this buys is a bound on v that capital cannot lift. The vote fee is sunk, and a ballot is one per account per proposal, so the record accrues with participation and not with the size of a position. The admin badge keeps one escape hatch, mint_vote_to, restricted to the admin role and used to seed a member the ledger would otherwise strand.

One ordering detail follows. The ballot's snapshot counts its own mint in both the caster's balance and the supply it divides by, which it did not do while trades were a second source. With ballots the only source, a snapshot taken before the mint would score every member's first ballot at zero and no caper's first proposal could ever pass.

Because v is soulbound it cannot ride the transaction worktop like an ordinary token, so vote takes the caster's account address and the contract mints directly into it.

What your vote tokens are worth

v has two jobs, and they are the same arithmetic. It weights any ballot you cast, and it sets your share of the treasury when you leave. The expression is

w = (t · v) / (V · T)

where t is the governance tokens (held, when voting; handed in, when exiting), v the vote tokens, V the caper's whole vote-token supply, and T its circulating token supply. On a ballot, v and V are read at the cast and T is frozen once per proposal at creation, while t is read twice – at the cast, and again when the crank folds the ballot, with the smaller of the two counting (the min-clamp above); on an exit all four are read at that moment. If any of them is zero the weight is zero, so a holder who has never cast a ballot redeems nothing from the treasury, however they came by their tokens – exit aborts without vote tokens – though they can still sell the tokens back to the curve.

Read plainly, the formula prices both what you hold and how much of the caper's activity you were. Two members holding identical bags do not weigh identically if one of them cast the ballots the other skipped. And because the numerator reads the amount you choose to hand in, redeeming part of a position redeems that part's share – there is no all-or-nothing exit.

It is one function, compute_vote_weight, in contracts/common/src/lib.rs, and the logic tier calls it in three places – worth separating, because the call made while you watch is not the one that counts. vote() computes a weight_preview and attaches it to the BallotCast event (vote, in contracts/logic/src/lib.rs): that is the figure the interface shows you at the cast, and no tally reads it. The stored ballot deliberately freezes no weight at all – it keeps t, v, V and T as raw inputs – so the weight that decides the proposal is derived afterwards, by fold_ballot_batch inside the permissionless crystallize crank, from the clamped stake. exit() is the third. A ballot's preview and a ballot's verdict are two separate calls of one function, and only the crank's binds. That is why the source calls it a vote weight, and why a member's standing in a governance decision and their claim on the treasury cannot drift apart – they are the same number.

What the circulating supply does, and what it cannot do

T, the divisor, is the caper's circulating token supply. It changes how fast a treasury pays out – a larger circulation makes each individual exit smaller – and it is the same figure for everyone exiting at that moment. On a ballot it is frozen once, at the proposal's creation, so ordinary trading during the voting window cannot move the denominator under a vote already cast.

One caper obtains it differently. The $XRD caper has no bonding curve and its members hold native XRD, whose total supply cannot be read on-ledger at all: Radix creates XRD at genesis without supply tracking, so the resource reports no total. The contract substitutes XRD's protocol maximum instead, the tightest figure guaranteed to be at least the sum of member holdings. Erring high there makes $XRD exits conservative, which is the right direction to err. The same caper does take proposals, but its optimistic phase cannot read a mark that never moves. Since the redeploy of 15 September 2026 it is priced against a reference basket of other capers' curve prices, each member weighted by its XRD curve reserve and the index normalised to sum to one. That basket is quoted in XRD, so the test inverts: the proposal passes if the window's basket mean is at or below the baseline locked at the trigger. Capital rotating out of capers into XRD pushes the basket down and is consent; dumping XRD into capers pushes it up and is the veto. Membership is a state field the gateway can read rather than a constant – xrd_basket, holding the single entry CAPER when read live on 16 September 2026 – and widening it means swapping the logic tier, exactly like retuning a window.

Three eras, and why the ledger is the authority

Caper's governance surface has been replaced twice in a month, and both replacements reached every caper at once, because a change confined to the logic tier arrives without a per-caper migration. The record matters here more than usual: material written in good faith during any of the three eras describes a real deployment, and only one of them is live.

1. The ballot era, to 26 August 2026. Members staked governance tokens into a per-caper ballot box, cast an ordered list, and the contract scored them Borda-style behind a 1.5 / N supermajority, with a late market veto able to cancel the result. Vote tokens were minted one per ballot at release, which meant a member's first ballot always weighed zero.
2. The price-only interregnum, 26–28 August 2026. The whole ballot apparatus was removed. A proposal named one action, locked a seven-day baseline, and passed if the price at resolution was at or above it. v was minted by trading alone. This is the model the wiki described for three days, and the model a good deal of third-party writing about Caper still describes.
3. Two-phase, from 29 August 2026. Ranked voting was reinstated as the legislative phase, in front of the optimistic one; the market's role narrowed from "the only vote" to a ratification window, and its test tightened from the spot price at the crank-second to the TWAP over the window itself. v accrued on both surfaces, trades and ballots, until the redeploy of 11 September 2026 removed the trade mint. The staking ballot box did not come back: tokens stay liquid while you vote, and the min-clamp is what makes moving them after casting unprofitable.

What survived all three is the exit and the expression that prices it. What the second era gave up – the ability to ask members to choose between five options rather than only whether to stop one – is what the third bought back. The wider trade, and where other DAOs land on it, is in optimistic governance and voting mechanisms.

The practical instruction is the one this wiki gives everywhere: read the numbers off the ledger. Resolve current_main on the CaperRegistry, then read vote_fee, proposal_fee, proposal_fee_rate, voting_period_in_seconds, proposal_window_in_seconds and twap_window_in_seconds off the component it names. None of them has a setter, so on any given deployment they are fixed – but the deployment itself can be swapped by a $CAPER UPGRADE, which is exactly how this page came to need rewriting twice.

How your exit share works

Your exit share multiplies what you hand in by the vote tokens you have earned – and since 11 September 2026 a ranked ballot is the only thing that earns them, one per ballot cast. A bag that has never voted redeems nothing from the treasury, however much it traded.

The same weight moderates a caper’s Trollbox

Every caper has a Trollbox, a chat room on its profile, and a separate room under each of its proposals and each page of its company wiki. Anyone holding the caper’s token, its vote token or its founder badge can post in all of them. The founder is the rooms’ one human moderator. Since September 2026 members can also collapse a line themselves, and a flag is weighted by the same w = (t·v)/(V·T) that decides a ballot and prices an exit.

A flag with no weight is refused rather than counted, so flagging needs v, and v comes only from casting a ballot. A holder who has never voted can post but not flag. Each member flags a line once and cannot withdraw the flag, the same shape as a ballot. A line collapses only when two tests pass together: at least three members have flagged it, and their combined weight clears a bar that the author’s own weight raises, up to double. No single holder can take a line down however large their position, and a poster with real weight in the caper is harder to silence than a newcomer, though the cap on that shield means nobody is impossible to silence.

Both sides are re-read against live stake when the flags are counted. A flag is credited with the smaller of the stake its author held when they flagged and the stake they hold now, the same clamp settlement applies to a ballot, so stake that has since been sold cannot moderate. The author’s shield takes the smaller of their weight when they posted and their weight now, so they cannot buy protection once flags start arriving or keep it after selling.

A collapsed line reads hidden by the room with its flag count. The text is withheld on the server rather than hidden by styling, and holders can ask to see it. An author with three lines collapsed in the same caper within 24 hours is muted in that caper until the count drops back under three. The founder can restore a collapsed line, and the restore is final: further flags are refused, and the line stops counting towards the author’s mute. The founder can also remove any line in the caper’s rooms, and an author can remove their own.

None of this is on-chain. It is how the application runs the rooms, and it reads the caper’s on-chain balances and supplies to do it. The weight a whole room carries is far smaller than the formula’s ceiling of 1, because most of a curve’s float sits with accounts that have never voted, which is why the three-flagger floor, not the weight, is usually the test that binds.