Voting on a caper is ranked-choice. You submit an ordered list of the proposal's options and the contract scores them Borda-style β with N options, your first pick earns Nβ1 points and your last pick 0 β so a ballot expresses a full preference order rather than a single yes/no.
What is my vote worth? How is vote weight calculated?
Your voting weight is not simply your token balance β it is the product of your stake and your participation. The contract computes w = (t Β· v) / (V Β· T), where t is the governance-token balance you have staked into the caper's ballot box, read at the moment your ballot is cast, v is your locked, non-transferable vote-token balance, V the total vote-token supply, and T the caper tokens in circulation. There is no past-block snapshot and no later re-reading: a staked bag is locked until the ballot it backs is released, so the figure credited is the figure you committed.
Because v is read before this vote mints its token, a member's very first vote counts v = 0 and therefore carries zero weight: influence is earned by showing up, not bought in a single transaction. This participation gate, not a snapshot block, is what makes a caper resistant to flash-loaned voting power, the attack that has drained token-weighted DAOs like Beanstalk.
Each cast vote mints one soulbound vote token into your account β your permanent proof of participation. Vote tokens also drive exit redemption: to leave, you burn vote tokens alongside the caper tokens you redeem and receive a treasury share computed by the same expression that sets your voting power. The same expression, not the same number: a ballot reads t off the stake escrowed in the ballot box and v off your whole vote-token balance, while exit() reads both off the buckets you hand in, so redeeming part of a position redeems that part's share.
A proposal's voting window closes at its expiry. Anyone can then release the ballots and finalize the result β the option with the most total weight wins, but executes only if it reaches a supermajority of 1.5 / N of all weight cast (the contract compares with >=, so a share landing exactly on the bar passes). If it falls short, or if the no-execution option placed first, the proposal closes with nothing happening on-chain. A tally that does clear the bar faces one further gate: the market veto cancels it at finalize if the caper's curve price fell more than 30% between voting close and settlement β a decision made by holders trading, not by anyone voting.
How do I vote, and how do I rank the options?
Voting is two acts, not one. First you stake governance tokens into the caper's ballot box, a component that holds one escrow vault per voter. Then you cast, submitting an ordered list of the proposal's options. A member casts by signing a pre-authorization subintent, which an assembler batches with other members' ballots into shared transactions, so a ballot needs a signature rather than a transaction of its own.
The contract will not accept a partial ballot. Your ranking must cover every option on the proposal, exactly once β a short list, a repeated option, or an index that is not on the ballot all fail. That is what makes the Borda scoring comparable across voters: every ballot spends the same points, and the only thing that varies is the order.
Two conditions gate a cast, and both close gracefully rather than reverting, because an abort would poison every other ballot batched into the same transaction. A cast that arrives outside the proposal's window records nothing and returns false; so does a cast from an account with nothing staked. In both cases the vote fee is deposited into the caper's own treasury exactly as it would be on the accepted path, so a missed ballot fails without leaving anything half-applied, and costs the fee.
Can I sell after I vote?
Not the tokens you voted with. Your ballot's weight term is the stake sitting in the caper's ballot box, and casting refcount-locks that vault: the contract refuses an unstake while any ballot it backs is still unreleased, with an explicit stake locked while a cast ballot awaits release. Tokens you did not stake stay yours to trade throughout, and the stake unlocks by itself when the ballot is released after voting closes.
This is stricter than the rule it replaced, and worth stating plainly because this page described the old one until 16 August 2026. A ballot used to be credited the smaller of the balance held at vote time and the live balance at tally time, and anyone could permissionlessly re-clamp a counted ballot downward during a challenge window after voting closed. The clamp existed because the tokens could still move. Under escrow they cannot, so the apparatus around it went with it: no snapshots, no caps, no clamping, no challenge window. Double voting is now prevented by custody rather than bookkeeping, since one bag cannot back two counted ballots.
The asymmetry the old rule bought is therefore no longer something any member has to enforce. A member who votes and then sells into the result they voted for cannot do it with the voting stake at all, without asking anyone's permission or watching a window. That is the same principle the exit right relies on, applied to the vote itself, and it is why a caper needs no snapshot block to resist borrowed voting power.
Can I change my vote? Can I vote twice? What does it cost to vote?
You get one ballot per proposal, and it is final. You cannot vote twice: the contract refuses a second ballot from the same account outright, so a vote cannot be edited, replaced or withdrawn once it lands. Nothing about it moves afterwards either: the weight was fixed when the ballot was folded into the running tally, and the stake behind it stays locked until release.
Do I need XRD to vote? Yes. Each cast carries the configured vote fee in XRD, and it is deposited into the caper's own treasury rather than paid to the protocol, so the cost of governing a caper accrues to the caper. The fee is a governance-settable lever bounded only to be non-negative, so read the current figure off the caper you are voting on rather than off this page.
What happens if nobody votes? What if no one votes at all?
Nothing happens. Settlement measures the leading option's weight against the total weight cast; with nothing cast that share is zero, no option can reach the 1.5 / N threshold, and the proposal closes with no on-chain effect.
There is a sharper version of the same case, and it is a real property of a new caper rather than an edge case. Vote tokens are minted at release, strictly after the last ballot is cast, and a caper is created with none in existence. On a caper's first proposal every voter therefore reads v = 0, every ballot weighs zero, and the proposal cannot pass however large the holdings behind it. Participation has to accumulate before governance can act.
Can a whale control the outcome? Not by buying in. Weight multiplies holdings by a voting record that only showing up can produce, so a holder who has never voted carries zero weight at any size, and one who has voted carries a record that cost them a ballot each time.
What the circulating supply does, and what it cannot do
Weight is divided by the caper's circulating token supply as well as by the total vote record. That divisor is the same for every member, so it cancels out of the only comparison settlement actually makes: the leading option's weight against all weight cast. Circulation changes how fast the treasury pays out an exit; it cannot move a proposal's outcome.
One caper obtains the figure 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 simply reports no total. The contract substitutes XRD's protocol maximum instead, which is the tightest figure that is always at least the sum of member holdings. Erring high there makes exits conservative and leaves votes untouched, which is the right direction for both.
What the 1.5 / N threshold asks for
The pass mark reads like a sliding bar and is not one. Every ballot spends the same number of Borda points β N(Nβ1)/2 times the voter's weight β so an option's share is measured against the pool of all points cast, and the largest share any option can reach is 2 / N, which happens only when every voter ranks it first. A threshold of 1.5 / N is three-quarters of that ceiling, and it stays three-quarters at every ballot size. Put in members rather than points: where the voters who do not back an option rank it last, it takes 75% of the weight ranking it first to carry β the same 75% whether the ballot has two options or six.
What does change with the option count is what a divided electorate can pass. Because Borda scores standing across the whole field rather than first preferences, from five options upward an option that nobody ranks first but everybody ranks second clears the threshold, provided first preferences are spread across the rest of the field; at four options the same profile falls just short. Splitting one question into many options therefore does not lower the bar for the proposer's own favourite β it widens the opening for a compromise nobody led with. The general property, and how other DAOs meet it, is covered under ranked and alternative ballot methods.
One of the options in N is not the proposer's. Every proposal carries an automatic no-execution option, titled Do nothing, appended last and always present β so a proposal offering a single action is a two-option ballot needing 75% of weight behind it, and every option a proposer adds raises N from a floor of two.
Where the formula lives, and which package runs it
The weight formula is one function, compute_vote_weight, and it is defined in contracts/common/src/lib.rs β the shared arithmetic crate, not in either of the packages that call it. Its own source comment states why: the swappable logic package and the ballot package "fold weights with EXACTLY these functions", so the arithmetic sits in one place both can compile against.
Which package runs it depends on what you are doing. A ballot cast runs the copy inside the ballot package, contracts/ballot/src/lib.rs, which reads your staked balance and your vote-token balance at the moment of the cast and folds the result straight into the tally. The logic package, contracts/logic/src/lib.rs, calls the same function in exactly one place: exit(), to size the treasury share you redeem on the way out. Since the ballot-era upgrade of 16 August 2026, CaperMain::vote computes nothing itself. It forwards to the ballot vault's cast_for and returns whether the cast was accepted.
The split has a consequence worth knowing before you audit anything. caper-common is a source dependency, so every deployed package carries its own compiled copy of the formula. Replacing the logic package through an UPGRADE proposal replaces the copy that sizes exits; it does not touch the ballot vault, which is a separate component the logic tier calls by address. Voting weight and exit weight are the same expression, but they are not the same deployment, and only one of them moves when a caper votes to upgrade itself.