Mitosis
Mitosis governance voting, gMITO delegation and proposal execution
Mitosis governance lets gMITO holders delegate voting power and vote on proposals affecting protocol contracts and network operations. Delegating to your own address enables direct voting; choosing another address assigns voting authority to that delegate. Your eligible power includes held and staked gMITO, with historical checkpoints determining a proposal’s voting weight. Ordinary accounts can’t freely transfer gMITO between themselves, and delegation doesn’t transfer the tokens. A successful vote also doesn’t execute a proposal immediately. The governance system separates voting from timelock execution, with additional routing for branch-chain contracts and consensus modules. Voting requires an active proposal. Queued calls must wait until their timelock operation is ready; defeated or canceled proposals can’t execute.
In this guide
Changing delegates affects future snapshots and doesn’t alter voting power fixed at an earlier proposal snapshot.
Casting your own vote or appointing a delegate
Self-delegation lets you cast votes directly, while appointing another account gives that account authority to cast your governance votes. The choice concerns ballot authority, so it doesn’t select a validator or move a staking position. A delegate’s vote uses the power assigned to its address at the relevant snapshot. Several holders can appoint the same delegate, letting that address cast a ballot backed by their combined delegated power. Choosing self-delegation leaves you responsible for reviewing proposals and authorizing your votes.
The delegate can vote differently from your preference. The delegation record assigns authority without enforcing a personal agreement about each proposal.
Can staked gMITO still supply governance votes?
Staked gMITO remains part of the governance voting-power calculation alongside gMITO held in the wallet.
Wallet-side voting units
Held gMITO contributes voting units through the governance token’s checkpoint system. Those units reflect token balances, while delegation determines which address receives their voting authority. The balance identifies token ownership; the vote count identifies the power an address can exercise. Holding tokens without assigning a delegate doesn’t automatically turn that balance into active votes. Self-delegation links ownership and voting authority to the same address.
Staking-side voting units
ValidatorStakingGovMITO tracks governance voting units for staking positions separately from the wallet-side token record. MITOGovernanceVP aggregates votes across its configured voting sources and applies delegation across those sources. The combined record preserves governance participation for staked tokens without crediting the same token balance twice. Delegating through that voting-power contract coordinates the records, so held and staked balances can share the chosen representative.
Delegation options and voting constraints
The voting-power contract supports self-delegation and delegation to a representative. A signed delegation provides another authorization method, while an undelegated balance contributes no active votes. These choices differ in who controls the ballot and how the holder authorizes the assignment. Each proposal uses the assignment recorded at its own snapshot. Delegation grants no permission to transfer the holder’s tokens.
| Delegation option | Who casts the ballot | Applicable constraint |
|---|---|---|
| Self-delegation | Your own account | The assignment must enter voting history by the proposal snapshot. |
| Delegation to another account | The chosen representative | The representative controls the ballot for assigned voting power. |
| Changing delegates | The replacement representative | Earlier snapshots retain their historical allocation. |
| Signed delegation | The address named by the signer | The signature must satisfy expiry and nonce checks. |
| Leaving delegation unset | No recipient for that balance’s votes | The balance supplies no active voting power until delegation. |
| Delegation assigns ballot authority; the proposal snapshot determines which assignment applies. | ||
Claiming gMITO staking rewards
Staking MITO or gMITO to a validator creates eligibility for gMITO rewards. An estimated reward isn’t a claimed governance-token balance.
Reward allocation
ValidatorRewardDistributor uses validator contribution data to allocate the epoch’s gMITO reward pool. A validator’s designated reward manager receives its collateral reward and commission from the staking portion. Stakers share the remaining staking rewards according to their time-weighted contributions. The validator’s performance and your stake history therefore affect the gMITO you can claim. A displayed staking amount alone doesn’t determine a fixed reward. Time-weighted average balance belongs to reward allocation here; it doesn’t add a duration bonus to the held-plus-staked governance formula.
Claimable balances
Rewards become claimable after the relevant contribution data becomes available to the distributor. A successful claim mints the processed epochs’ gMITO rewards to the authorized caller and records those epochs in the same transaction. Before that claim, an accrued estimate doesn’t establish a wallet balance available for governance delegation. Claim limits can bound the epochs processed in a single operation, so a claim needn’t exhaust every historical entitlement. The claimed amount and remaining entitlement are separate quantities; a partial claim doesn’t show every reward has arrived.
When does a changed delegate affect a proposal?
A delegate change affects a proposal when the new assignment enters the voting record by that proposal’s snapshot. Changing delegation after a proposal’s snapshot doesn’t change the voting power recorded at that snapshot. The voting-power contract can read historical delegated votes, allowing a governor to use the same reference point throughout voting. An account’s current voting power can therefore differ from its weight on an older proposal. Timing matters even if delegation succeeds immediately: confirmation of the new delegate doesn’t create retroactive voting eligibility.
Proposal thresholds and vote counting
MITOGovernance handles proposal creation and voting, while its configuration defines the requirements a proposal must meet. A proposal threshold concerns whether an account has enough votes to submit a proposal. Quorum concerns whether the required amount of qualifying voting power supports the decision. The voting delay separates proposal creation from the voting snapshot, and the voting period governs the ballot window. A proposal-creation threshold therefore isn’t a minimum balance every voter must meet. Their applicable values come from the governor and the individual proposal.
The protocol’s Bravo-style counting module records For, Against and Abstain separately. Under that module, only For votes satisfy quorum, and For must exceed Against for vote success. Abstentions remain visible without helping that quorum calculation. Counting rules belong to the governor’s selected module; a different counting mode changes which tallies qualify. A majority in a displayed tally alone doesn’t establish proposal success.
How does an approved proposal become executable?
An approved proposal reaches execution through the Timelock, which schedules the authorized calls for execution after the applicable delay. Voting success and executable status describe separate stages. The Timelock’s minimum delay controls scheduling, and a queued operation has its own readiness state. Execution also follows the contract’s role permissions. Passing a vote doesn’t mean any address can immediately perform the change. The targets must still accept the authorized calls, so a ready operation and a successful execution remain different outcomes.
The delay’s value belongs to the deployed Timelock configuration. It isn’t a permanent duration implied by the gMITO token. A queued proposal can remain unfinished while its operation waits, and an authorized cancellation removes that timelock operation’s execution schedule.
Branch-chain contracts and consensus modules
Governance execution can reach contracts beyond the Mitosis Chain execution layer, with different entrypoints routing actions to their destination. Branch chains host vaults and strategies outside the central chain. Consensus modules handle another layer of network operation. The proposal’s target determines which route applies; the routes don’t form mandatory steps for every proposal.
Branch-chain contract calls
For a branch-chain action, the Mitosis Chain Timelock passes the execution payload to BranchGovernanceEntrypoint. Cross-chain messaging carries it to the destination GovernanceEntrypoint, where the branch-chain Timelock registers the call. That destination Timelock adds its applicable delay before execution against the target contracts. A completed hub-side operation therefore doesn’t establish completion of the destination contract change. The branch-chain operation and the affected contract state provide separate records of what happened after message delivery.
Consensus-layer messages
ConsensusGovernanceEntrypoint routes approved messages from Ethereum Virtual Machine (EVM) governance to the consensus layer through event logs. The x/evmgov module receives those messages and executes the corresponding consensus-module actions. This route concerns consensus configuration and doesn’t move a vault position to another chain. Its completion evidence belongs to the affected consensus operation. A governance proposal can authorize the route, while the resulting module state identifies whether the intended change took effect.
The destination’s permissions and execution conditions still govern the final call. Governance can authorize changes through these routes, but a vote doesn’t replace cross-chain message delivery or the destination’s scheduled execution. A branch-chain timelock delay also shouldn’t be mistaken for the voting period on the central chain.
Non-transferability and authorized token movements
Ordinary accounts can’t freely transfer gMITO to another account. GovMITO enforces module and sender permissions around transfers and approvals. Those permissions let authorized contracts handle staking and other protocol movements without creating unrestricted token transfers. Delegation changes a voting assignment, so it doesn’t require the recipient to receive gMITO. A representative also gains no withdrawal authority solely from the delegation record. The restriction applies to token movement; it doesn’t prove that every governance decision resists manipulation or that delegated votes can’t concentrate at one address.
Proposal records and changing parameters
MITOGovernance identifies proposal state, while MITOGovernanceVP supplies current and historical voting power. Snapshot and deadline describe the voting window; the Timelock’s operation timestamp describes execution readiness. A transaction receipt establishing a cast vote confirms the ballot operation, without confirming adoption or execution. The affected contract’s state supplies the evidence for a completed parameter change. For cross-chain governance, the destination record remains necessary even after the hub-side proposal reports execution.
A proposal’s threshold or timelock delay can differ from a value remembered from an earlier decision. Proposal-specific snapshot and deadline records preserve the relevant timing, whereas live configuration can describe future proposals. A later configuration change can govern newly submitted proposals without changing an earlier proposal’s stored voting window.
Useful questions about Mitosis
Can I divide one account’s gMITO votes among several delegates?
MITOGovernanceVP assigns a single delegate address for an account across its configured voting sources. Its delegation call doesn’t allocate percentages to multiple representatives. The chosen address can be the holder’s own account or another account. Combining held and staked voting sources doesn’t create separately configurable delegates within that call.
Does a signed delegation message immediately change my on-chain delegate?
A delegation signature changes the on-chain delegate only when the contract accepts the signed delegation operation. MITOGovernanceVP checks the signature’s expiry and the signer’s nonce before applying the assignment. Signing alone leaves the delegation record untouched. A signature the contract rejects therefore doesn’t activate the intended representative.
What time unit do gMITO voting checkpoints use?
gMITO’s voting checkpoint clock uses Unix timestamps in seconds, so a checkpoint timepoint isn’t a block height. The token reports timestamp mode and reads the chain timestamp for its clock. Historical voting-power queries must use the same time format as those checkpoints. Block heights and elapsed staking duration aren’t interchangeable with that timestamp.
Is transferring a staked gMITO position to another account supported?
The gMITO staking contract blocks transfers of staking ownership between accounts. It also requires the staking recipient to match the payer and the unstaking receiver to match the payer. Those restrictions prevent a staking position from bypassing the token’s account-transfer limits. Changing a governance representative doesn’t change the account owning that staking position.
Do governance delegates automatically receive permission to claim staking rewards?
Governance delegation doesn’t automatically grant validator-reward claim permission. The reward distributor keeps claim approvals separately for the account, validator and approved claimer. For an approved third-party claim, the distributor directs the reward to the authorized caller. An account appointed as a representative needs the separate reward permission to claim another holder’s entitlement.
How does unbonding gMITO count toward governance voting power?
The gMITO staking contract includes pending unstaking amounts in its governance voting units until those amounts are claimed. Requesting unstaking reduces the validator’s consensus stake immediately, so consensus power and governance power can change at different points. Claiming removes the returned amount from the staking-side voting record; wallet-side voting accounting then applies to the returned tokens.
Last updated: