Governance votes
Governance votes are the Console workflow for creating an on-chain vote, casting ballots on it, and carrying out whatever a token's holders approved.
A governance vote puts a proposed change in front of a token's holders, records their weighted ballots on-chain, and carries out the approved result through a timelock, a contract that enforces a waiting period between approval and execution. Reach for this workflow when a change to a token, such as a new supply cap or a revised fee rate, should rest on a recorded holder decision with a delay before it lands. Nothing changes on the token until someone executes the passed vote, and a vote sitting Pending or Queued can still be cancelled before that happens.
Two neighbouring jobs do not belong here. An administrator who holds the right role on a token can change parameters such as fee rates or caps directly from that token's management screens, with no vote and no delay. Governance is for the change you want backed by a recorded decision, not for routine administration. A poll is not this workflow either: choosing "Poll" while creating a vote collects signed ballots off-chain to gauge opinion, and a poll never reaches the queue and execute machinery this page describes, or the "Votes" list this page walks through. A poll ballot is cast from the Console's "Actions" surface instead. Only the "Resolution" and "Multi-option resolution" modes carry the queue and execute machinery, and everything from the figure onward covers those two.
Ballot weight comes from voting power, a per-holder balance the vote reads as of its record date, a future moment you pick while creating the vote. A holder's own ballot carries weight only if their voting power is activated, and not delegated away, before that date. A holder who delegated away can delegate back to themselves at any time, but the change only counts for a vote whose record date falls after they do.
A vote moves through one path: Pending until its record date, Active while ballots arrive, Succeeded once quorum clears, Queued while the timelock delay runs, then Executed; a Resolution vote also needs its approval threshold met to succeed. Defeated and Canceled are the two other endings, and all three final states never change again.
The Console shows one of seven statuses on every vote. "Pending" means the record date has not arrived and voting has not opened. "Active" means holders can cast ballots now. "Succeeded" means voting closed with quorum, the minimum share of voting power that must take part for the vote to count at all, reached. For a Resolution vote it also means For finished ahead of Against and any configured approval threshold was met. A Multi-option vote succeeds on quorum alone, and its winning option is read from the tallies. "Defeated" means voting closed short of quorum or short of the threshold, and it is final: no queue or execute control ever appears on a Defeated vote again. "Queued" means a Succeeded vote is scheduled on the timelock, counting down its execution delay. "Executed" and "Canceled" are the two ways a vote closes for good from Queued. A Queued vote has no expiry of its own: nothing forces it out of Queued, so it stays there, ready to execute, until someone executes or cancels it.
Every irreversible step here says so before you take it, and this page does the same. Executing a vote carries out everything it holds, in one transaction, through the timelock; once it lands, it cannot be undone. What it changes applies to the token from that moment forward: anything the ledger finalized before execution keeps the old terms, and anything it processes afterward reads the changed ones. Cancelling closes a vote permanently, whether it is still Pending or already Queued, and any current holder of the Governance role on that token can cancel it, not only the person who created it. Neither queueing nor casting a ballot is reversible on its own once submitted, but neither one applies a change to the token by itself either; only execution does that.
Steps
Open the votes list
In the Console, open "Asset lifecycle" and select "Votes" in the sidebar; when more than one governance addon is deployed, each appears as its own entry under its own on-chain name. Which surface you open next depends on what you came to do. The sidebar list is the operator surface: it shows every vote across tokens, with a "Next action" column naming the step each vote is waiting on, and opening a vote here offers the "Manage" menu and "Export CSV". Holders act from the "Governance" tab on a token's own detail page instead: it carries the same list scoped to that token, the "Delegate voting power" control, and the voting-power distribution, and opening a vote there is where ballots are cast. The sidebar entry is hidden from accounts that cannot manage votes, so a holder who does not see it has lost nothing.
The operator votes list shows every vote's title, token, status, mode, and "Next action", with "Create vote" and, on a selected row, the "Manage" menu and "Export CSV".
Create a vote
Select "Create vote" on the votes list. The wizard has four steps. "Vote details" sets the token, the "Vote mode", a title and description, and optional "Document links" to supporting material. Choose "Resolution" for a yes or no decision that can also carry executable changes, "Multi-option resolution" when holders pick between two or more named options, and "Poll" only for an off-chain signal that decides nothing on-chain. A token without the voting-power feature cannot receive a vote; the wizard offers "Attach voting power" in place when you hold the Governance role, and names the role to ask an administrator for when you do not.
"Options & actions" defines the named options for a Multi-option vote, at least two. For a Resolution vote it instead composes what the vote carries from a curated catalog, such as a new supply cap or a revised fee rate; leave the list empty for a plain resolution that decides without changing the token. The step checks that the timelock already holds the authority those changes need and offers "Grant governance role to timelock" if not; only a token administrator can grant it, so composing changes without that role means asking one before the vote can be created.
"Schedule" sets the record date, the voting period, quorum, the approval threshold, and the execution delay, and one of those values can never be lowered once set, so choose it deliberately. The record date must sit at least 24 hours and at most 90 days ahead, and voting power counts only as it stands at that moment, so a later record date gives holders more time to activate. The voting period offers five lengths: one, three, seven, 14, or 30 days, with seven as the default. Quorum is set in basis points against the token's entire supply of voting units at the record date, where 10000 equals that whole supply. Only activated voting power can actually vote, which is why the step shows the activated share and warns when the quorum you typed exceeds it. The approval threshold is also set in basis points, but against a different total: the share of For plus Against that For must reach, so 10000 there means unanimous agreement between the two, not the whole supply. A threshold of 0 keeps a simple majority, where For only has to beat Against; a higher value demands that For reach that share of For plus Against. If this is the first vote created for this token, whatever threshold you choose here becomes that token's approval-threshold floor for good: a later vote on the same token can raise the floor but never lower it. The execution delay offers five lengths too, but a different set from the voting period: one, two, seven, 14, or 30 days, and is the waiting period holders get between approval and execution.
"Review vote" shows everything before you confirm and create it. A governor is the on-chain contract that receives every vote for a token and enforces its rules; creating a vote for a token that has no governor yet deploys the governor and timelock pair first, then submits the vote. The review step says so when that applies.
Cast a ballot
Open the vote from the token's "Governance" tab; the operator list does not offer a ballot. While your account can act, the "Your eligibility" card says so, sometimes alongside a note that the screen cannot state your exact voting power from the vote record; that note does not affect your ability to vote. When your account cannot act, the card names the reason instead: voting not open yet, power delegated away, power not activated before the record date, a ballot already cast, or a vote already closed. Select "Cast ballot" and choose For, Against, or Abstain on a Resolution, or one option on a Multi-option vote, with an optional reason. The reason is recorded with your ballot and appears beside your address in the vote's ballots table, so write it for the audience that will read it there. Abstain counts toward quorum and never toward the approval threshold. Once cast, a ballot cannot be changed, and the results update as more ballots arrive.
An equivalent create, cast, queue, execute, and cancel flow is available outside the Console; see the API explorer for the request and response shapes, or CLI commands for the command-line equivalent.
Managing an existing vote
Three more controls live under "Manage" on a vote's detail page reached from the "Votes" sidebar list, filtered by the vote's current status, and each one opens a wallet-verification dialog before it runs. Opening the same vote from a token's "Governance" tab never shows this menu, no matter what role you hold; go back to the sidebar list to manage it.
Queueing schedules a Succeeded vote on the timelock. Select "Queue for execution"; the vote moves to Queued and its delay starts counting from that moment, using whichever is longer of the delay you set when creating the vote or the timelock's own minimum. The vote's details card shows the resulting "Earliest execution" moment.
Executing carries out everything a Queued vote holds, in one transaction, and it cannot be undone. Select "Execute" once the delay has passed. If execution fails, the vote stays exactly at Queued, so nothing partially applies. The Console decodes the revert reason when it can; when it cannot, usually because the node it queried has pruned older transaction history, it shows the raw value and states that history is unavailable. "Retry execution" and "Cancel vote" both stay available from that failure until a retry is submitted. Execution has no automatic rollback. A corrective change needs another authorized operation, which can be a new governance vote.
Cancelling closes a vote for good. Select "Cancel vote" on a Pending or a Queued vote; the confirmation states plainly that cancelling cannot be undone. A vote that is Active or already Succeeded cannot be cancelled directly; wait for it to close on its own, or, once it reaches Queued, cancel it there.
Troubleshooting
A vote is heading toward Defeated on quorum
The results panel shows quorum progress against the total voting power recorded at the record date; if turnout is short of that number as the deadline nears, the vote is on track to close as Defeated. Nothing you do after the record date changes who counts toward quorum. If you created the vote, the only way to make the same change again is a new vote with a later record date, so more holders can activate their voting power first.
A Resolution vote reaches quorum but still shows Defeated
Quorum counts every ballot cast, Abstain included. The approval threshold works differently: it weighs only For against Against, and Abstain never counts toward it. A vote can clear quorum comfortably and still fail because For did not beat Against, or because For fell short of the configured threshold share. Check the approval-threshold progress on the results panel, not only quorum, when a vote you expected to pass does not.
A Queued vote sits without executing
This is normal, not a stall: nothing but an execute or a cancel moves a vote out of Queued. Check the "Earliest execution" moment on the details card; before it arrives, execute is not yet possible. If you expected someone else to act after that moment, ask whoever holds the Governance role on that token.
Execute fails or shows an undecoded value
Whether or not the Console can decode the revert reason, the vote stays at Queued and nothing has partially applied. Correct whatever the reason names, if you can, and select "Retry execution", or select "Cancel vote" instead if the vote should not run at all.
Cast ballot is not available
Check which surface you are on first: the operator view of a vote never offers a ballot, only the vote opened from the token's "Governance" tab does. If you are on the right surface, the "Your eligibility" card names the specific reason: voting has not opened yet, power delegated away, power not activated before the record date, a ballot already cast, or a vote already closed.
Create vote is not visible, or creation is blocked
The "Votes" sidebar entry and the "Create vote" control appear only for platform administrators, token managers, and Governance role holders; an administrator can grant the role. Creating a vote for a specific token then needs the Governance role on that token. A token without the voting-power feature needs it attached first, which needs the same role. A composed change the timelock cannot yet run also blocks creation, and granting that authority to the timelock is a token administrator's call, so ask one when the wizard reports the authority as missing.
Read Corporate Action for how the changes a vote can carry, such as a new yield schedule or a maturity date, fit into a tokenized security's broader lifecycle.
Frequently asked questions
Does executing a plain resolution or a Multi-option vote change the token?
No. Only the composed catalog changes a Resolution vote carries move the token when it executes. A plain resolution with nothing composed, and every Multi-option vote, carries nothing executable: queueing and executing it completes the vote's lifecycle through the timelock and fixes the recorded outcome, but no token parameter moves. Acting on a multi-option result, or on a plain resolution, means an administrator applying the decision through the token's management screens, or a follow-up Resolution vote that carries the change.
Can a vote created outside the Console appear in the list?
Yes. A vote submitted directly to a token's governor still appears in the votes list and on its own detail page, marked with a "Created externally" badge. Its description is shown exactly as recorded on-chain, and it carries no Console-managed title, rich text, or document links. The same statuses, ballots, and manage controls apply to it as to a vote created in the wizard.
How do I export the ballots for an audit?
Open the vote from the "Votes" sidebar list and select "Export CSV". The export carries the vote's summary: status, mode, the quorum and approval-threshold settings, and the required and recorded totals. Each ballot follows as a row with the voter address, their choice, their weight at the record date, their reason, and when it was cast. The export button sits on the operator view, so it needs the same access as the "Manage" menu.
Does delegating voting power move my tokens?
No. Delegation assigns your voting weight to another address so the delegate can vote on your behalf; your token balance does not move. The voting power feature keeps that weight, with its own checkpoints. Reclaim the weight at any time by delegating back to yourself, which removes it from the previous delegate.
What happens when two options tie on a Multi-option vote?
The results panel reports the leading option while voting runs and the winning option once it closes; on an equal top count it states that the leading options are tied instead of naming a winner. Because a Multi-option vote succeeds on quorum alone and carries nothing executable, a tie does not block anything on-chain: the vote still closes as Succeeded when quorum was met, and reading the result stays with whoever acts on it.
XvP settlement
XvP settlement is the Console workspace for a multi-party exchange in which every party's asset moves in one transaction or none move, so no party sends first.
Organisation participants
Manage everyone the organisation tracks an identity for: users with a login, entities without one, saved contacts, and the verification records a token checks.