Governance votes

Governance lets token holders vote on decisions about a token. The platform supports binding on-chain votes, recorded resolutions, and lightweight off-chain polls, all weighted by each holder's voting power at a fixed record date.

Operators create and manage votes from the Governance section in the Console sidebar. Holders participate from the token's Governance tab, the vote detail page, or the Actions work queue.

What governance is on the platform

A vote is always tied to one token. The first vote on a token deploys a dedicated governance contract pair for that token: a governor that runs the vote and a timelock that holds the authority to carry out approved proposals after a delay. This setup happens automatically inside the create-vote flow.

Voting weight comes from the token's voting-power capability. A holder's weight for a given vote is their delegated voting power at the vote's record date. Balances acquired after the record date do not count; balances sold after the record date still count.

Vote types

Executable proposals are always binary (For/Against/Abstain). Multi-option votes are resolutions only: the winning option is the one with the most votes, provided quorum is met. A tie between leading options means no winning option, and the outcome view says so.

Poll ballots are EIP-712 typed messages signed by the holder's wallet rather than on-chain transactions, so they cost no gas. A holder can replace their poll ballot any time before the poll closes; the latest ballot counts. On-chain votes are final once cast.

Creating a vote

Open Governance in the sidebar and start the create-vote flow. The wizard walks through:

1. Token selection. Votes can be created on any configurable token that has the voting-power capability. If the selected token does not have it yet, the wizard offers to add it first.
2. Vote type and content. Title, description, and either the resolution text, the option list, or the executable actions.
3. Schedule. Record date, voting period, and (for executable proposals) the execution delay.
4. Quorum. The share of record-date voting power that must participate for the vote to pass.

For executable proposals, the wizard composes actions from a curated catalog of token operations (for example, changing a supply cap or updating fee parameters). It checks at compose time that the timelock holds the required governance role on the token; if the role is missing, creation is blocked and the wizard offers the grant-role flow.

Creating a vote requires the governance role on the token. Any current holder of that role can also cancel a vote while it is pending or queued.

Quorum warnings at creation

The wizard shows the token's currently activated voting power next to the quorum you set. If activated power is low, the wizard warns that the quorum may be unreachable. The warning is advisory: delegation activity between creation and the record date can raise or lower the bar, and the final denominator is fixed only at the record date.

Quorum counts every cast ballot — For, Against, Abstain, and every option in a multi-option vote. A tally that lands exactly on the threshold meets quorum.

Activation and record dates

Voting power only counts when it is activated. A holder activates by delegating their voting power — usually to themselves. Holding tokens without delegating gives a voting weight of zero.

Each vote has a record date at least 24 hours after creation. The window between creation and the record date is the notice period: holders who have not activated see an Activate voting power action in their work queue and can still delegate in time. Activation after the record date does not count for that vote.

Participating in a vote

Eligible holders see a Cast vote action in the Actions work queue once voting opens, and can also vote from the token's Governance tab or the vote detail page. Eligibility means having voting power greater than zero at the record date and not having voted yet.

• Binary votes: choose For, Against, or Abstain.
• Multi-option votes: choose one option.
• Polls: choose one option and sign the ballot with your wallet; you can change it until the poll closes.

A holder who delegated their voting power to someone else has a weight of zero for the vote, even with tokens in their wallet. The vote detail page explains this instead of offering a ballot: the delegate casts the vote with the combined weight.

Outcomes and exports

When the voting period ends, the vote detail page shows the outcome:

• Succeeded — quorum met and the outcome positive (For majority, or a winning option).
• Defeated — quorum missed or the majority against.

Every vote offers a CSV export of the ballots: voter address, choice, and weight at the record date. The export includes a disclosure noting that weights reflect record-date balances in full, including balances that were frozen or paused after the record date.

Executable proposals and the timelock

An approved executable proposal does not execute immediately. An operator queues it into the timelock, which enforces a delay of at least 24 hours (the proposal's configured execution delay, if longer, applies instead). After the delay, anyone with queue access in the Console can execute it; the timelock then performs the approved actions on the token.

The timelock holds only the governance role on the token. What it can do with that role is restricted by an on-chain allowlist of approved operations — the same curated catalog the wizard offers. Operations outside the allowlist cannot be proposed at all, even by someone calling the contracts directly. The allowlist deliberately excludes:

• Compliance and identity rewiring
• Role administration
• Minting and burning
• Token capability changes

This means a vote can adjust parameters such as caps, fees, yield schedules, and conversion settings, but cannot dilute holders, bypass compliance, or take over administration of the token.

While a proposal is queued, a governance-role holder can still cancel it; cancelling also removes the scheduled timelock operation.

Troubleshooting

A queued proposal fails to execute

If execution reverts — for example, because the timelock's governance role was revoked after queueing — the vote detail page shows the decoded failure reason where available, or the raw failure otherwise. From there you can:

• Retry after fixing the cause (for example, re-granting the role). The proposal stays queued; retrying is safe.
• Cancel the queued proposal if it should not execute. Cancelling requires the governance role.

Quorum looks unreachable

If the warning at creation flagged low activated power, use the notice period: holders receive the Activate voting power prompt in their work queue until the record date. After the record date, the denominator is fixed; if quorum is missed, the vote is defeated and a new vote must be created.

A holder cannot vote

Check, in order: the holder had activated (delegated) voting power before the record date; they did not delegate that power to another wallet; the vote is still open; they have not already voted. Each of these shows as an explanation on the vote detail page.

A vote appears with a "created externally" badge

Proposals created directly on-chain rather than through the Console show their raw on-chain description with this badge. They are fully operable from the Console: holders can cast, and operators can queue, execute, and cancel them.

Related guides