Kusama governance weights KSM votes through balance and conviction

2026 October 7 · updated

Kusama governance gives KSM votes their weight through the committed balance and the selected conviction multiplier. OpenGov uses that weighted tally to measure approval, while support measures unweighted backing relative to eligible token supply. Longer commitments can increase influence over approval without increasing the KSM counted toward support. A proposal also needs the authority, thresholds, and timing that its track requires. Direct voting and delegation apply different rules when participation ends, so removing a vote or ending a delegation does not always release KSM. Following the Asset Hub migration, token-holder voting takes place on Kusama Asset Hub. These relationships determine both how a referendum can pass and when committed KSM becomes transferable.

Bottom line: Higher conviction increases the weight of an aye or nay vote, while insufficient unweighted support can still prevent a Kusama referendum from passing.

Direct votes and delegated-track restrictions

A direct vote records an account's choice, selected KSM balance, and conviction on an ongoing referendum. An active delegation prevents that account from voting directly on the same track. Ending the delegation removes this restriction, although its resulting conviction lock can remain. Other tracks can remain under direct control or use different delegates, so an unavailable direct-voting option need not affect every referendum.

Governance records moved to Kusama Asset Hub with the migration completed on October 7, 2025. An old relay-chain connection therefore provides the wrong context for token-holder voting. The account's balance and the referendum belong to the Asset Hub governance environment. Holding KSM elsewhere in the ecosystem does not automatically make that balance available for an Asset Hub vote.

How does conviction change a KSM vote?

Conviction multiplies the KSM assigned to a standard vote, with higher multipliers tied to longer locking commitments. The selected amount defines the vote's capital; the multiplier defines its approval weight. Both aye and nay standard votes can carry conviction. A longer commitment can therefore strengthen opposition as well as votes for enactment. Applying a multiplier does not create additional KSM.

The lock factor counts multiples of the runtime's base vote-locking period. It does not specify a universal number of days. Intermediate conviction levels also exchange greater approval weight for longer commitments. The applicable runtime configuration determines the base period, which an upgrade can change. The commitment concerns the amount used for voting, while other balances can have their own restrictions.

Aye, nay, and abstain affect different tallies

Aye contributes to approval and support, nay opposes approval, and abstention contributes to support without taking either side in approval.

Standard votes

A standard vote assigns its selected balance entirely to aye or nay. Its conviction-adjusted weight enters the corresponding approval tally. An aye vote also supplies its unweighted balance to support. A nay vote supplies no support capital, even when it carries a large conviction multiplier.

View full-size image

Split voting and abstention

Split voting allocates balances between aye and nay, while the split-abstain format also allows an abstaining allocation. These formats do not provide higher conviction multipliers. Only the aye and abstain allocations count toward support. Abstaining therefore expresses participation without endorsing the call through approval. The combined allocated balance determines the amount subject to the ongoing voting lock.

Approval and support must clear separate thresholds

Approval measures weighted aye votes divided by the combined weighted aye and nay votes. It answers how the participating voting weight divides between acceptance and rejection. Abstaining capital stays outside that calculation, so an approval percentage does not describe every participating token.

Support measures unweighted aye and abstain capital against the runtime's eligible voting supply. Its denominator extends beyond the tokens participating in that referendum. Conviction multipliers do not increase the KSM capital counted toward a referendum's support.

Each track supplies approval and support threshold curves that change over its decision period. A referendum's tally must satisfy both curves at the relevant point in time. A voting display can consequently show substantial approval while support remains below its required threshold.

New nay votes can reduce approval without increasing support. Removing an aye or abstain allocation can reduce support. Tallies can move in both directions while voting remains open, and the changing threshold curves also affect whether the referendum meets its requirements.

Passing requires the necessary confirmation interval as well as sufficient tallies. Meeting both thresholds temporarily can start confirmation, but a later loss of either threshold interrupts it. A displayed majority therefore does not establish an approved referendum.

Origins determine authority, and tracks determine timing

An origin determines the privileges that an approved call receives, while its track sets the decision rules that voters must satisfy.

Execution authority

Root carries broad authority, while spending and administrative origins provide more limited permissions. The requested origin must authorize the proposed operation. The encoded call identifies what the runtime will attempt, including relevant recipients and amounts. A proposal's discussion text cannot change those bytes. Shared security for parachains also does not give every KSM referendum unrestricted control over every application's rules.

Decision conditions

Tracks have their own preparation, decision, confirmation, and minimum enactment periods. They also define decision deposits and limits on simultaneous deciding referenda. These settings separate the review conditions for calls with different authority. Exact durations and deposit amounts belong to the applicable chain configuration, so one track's values cannot be applied across all Kusama proposals.

Submission and decision deposits serve different purposes

Submitting a referendum requires a submission deposit; entering its decision phase also requires the track's decision deposit. Another account can provide the latter, so its depositor need not be the proposer. Neither deposit supplies an aye vote. Storing an unrequested proposal preimage can create a separate, size-dependent deposit. A preimage contains the encoded call that governance would execute, making its bytes and requested authority material to the decision. Ordinary voting does not require posting the referendum's decision deposit.

Delegation follows the account's chosen track

Delegation assigns a selected KSM balance and conviction to another account's votes on a specified track. Different tracks can use different delegates. The delegator chooses the conviction that applies to its own balance; the delegate's personal conviction does not replace that choice.

Received delegations contribute when the delegate casts a standard aye or nay vote. Split votes and abstention do not apply that received voting power. Delegations also do not propagate through further delegation. Choosing an account that delegates the same track onward therefore does not create an automatic chain of representation.

Voting delegation grants voting influence, without giving the delegate authority to transfer the delegator's KSM. Ending it removes delegated influence from ongoing votes and starts the delegator's conviction-lock period. That period can apply even if the delegate never voted. A change of delegate can consequently leave earlier balance restrictions in place.

Why can KSM remain locked after a referendum ends?

KSM can remain locked because a winning standard vote with conviction creates a post-result commitment measured from the referendum's end. Winning includes aye on an approved referendum and nay on a rejected one. A losing direct vote, a split vote, or a vote without conviction does not create that winning-side commitment. An ongoing recorded vote can still restrict transfers even when its conviction setting is zero.

Vote removal and balance unlocking are distinct protocol operations, although an interface can group them. Unlocking recalculates remaining restrictions; it cannot bypass an unexpired conviction period. Multiple votes and past delegations can overlap on the same balance. Their restrictions are not simply added together. Aggregated prior locks can combine the largest locked amount with the latest expiry. Staking restrictions can still prevent transfers after governance releases its lock.

Confirmation precedes enactment

A referendum reaches approval through sustained confirmation, then its approved call follows an enactment schedule. Preparation time, a decision deposit, and available track capacity govern entry into the decision phase. Earlier votes remain recorded, although they cannot complete the decision during preparation. Once both threshold curves are satisfied, confirmation can begin. Falling below either threshold resets that confirmation interval.

Confirmation can finish after the decision deadline if it began before that deadline and remains uninterrupted. Losing the required thresholds after the deadline instead leads to rejection. This makes a referendum's actual state more informative than a countdown that shows only the decision period.

The proposer requests an enactment time, subject to the track's minimum delay. Approval establishes the voting outcome; the dispatch result establishes whether the scheduled call executed successfully. For treasury spending, records confirming successful payment completion or receipt in the beneficiary's account establish that the funds arrived. An approval percentage cannot establish that receipt, and a passing vote does not repair an invalid or unauthorized call.

Cancellation and killing have different consequences

Cancellation ends an ongoing referendum while leaving its submission and decision deposits eligible for refund. Killing ends it while slashing those deposits. Both require authorized governance action, including the relevant origins; removing a personal vote only withdraws that account's participation. Neither action is equivalent to changing aye to nay. Reversibility changes once an approved call executes: editing a personal voting record cannot undo the network change or retrieve funds that the call already transferred.