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. 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.
A ballot is the ranking and nothing else. Until 6 October 2026 it also answered a second question – whether the proposer or the treasury paid a 10% execution fee at the trigger – and that question went with the fee: the proposer now pays one fee at creation, and the trigger is free (proposals).
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 vote_fee, proposal_fee, proposal_fee_rate, collateralization_peak and the three windows.
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.
Since the redeploy of 21 September 2026 the vote tokens handed in must be the leaving member's own. An exit transaction first calls exit_open, which records the member's vote-token balance, and exit() then requires the vote tokens it receives to equal the fall in that balance, aborting with Vote tokens must all come from the recipient otherwise. Several accounts signing one transaction can no longer pool their v into a single exit. The governance tokens are not bound the same way: they transfer freely, so co-signers can still route them to the member holding the most v, a limit the contract source records as accepted.
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.
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.
- 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 / Nsupermajority, 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. - 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.
vwas 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. - 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.
vaccrued 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. The deployment itself is not: the registry moves current_main for a settled $CAPER UPGRADE, and separately for the protocol admin badge, which needs no ballot at all. Proposals sets out both routes and where each one is gated.
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.