Mantra
Mantra governance changes the chain when authorized proposal messages execute
Mantra governance uses executable proposals to change network settings, schedule software upgrades or transfer community funds after a successful vote. A passed text proposal records community agreement without directly carrying out the change that it describes. The distinction comes from the submitted message and the module that can execute it. Approval alone doesn’t make new software run or complete a funded project. Upgrade proposals require compatible node software, while spending proposals require a valid recipient and enough available funds. Voting power comes from bonded stake. Deposit requirements, voting deadlines and tally thresholds also shape whether a proposal reaches execution.
In short: A scheduled upgrade needs matching node software at the designated block height before the chain can adopt its new rules.
Executable messages set the proposal’s scope
An executable governance proposal on MANTRA Chain carries instructions that select a chain module, alongside a title, summary and metadata explaining the intended change. Proposal messages use the governance module account’s authority for permitted actions, including spending and upgrade scheduling, while the person who submits the proposal signs the submission transaction from their own account. That account doesn’t gain the module’s powers simply by creating a proposal.
The running chain needs a registered handler for each proposed message, and the affected module must accept its contents. A proposal can contain multiple supported messages, with a description explaining their broader objective. The payload specifies the actions that the chain will attempt. Changing software requires the upgrade machinery; moving pool funds requires a spending instruction. Acceptance into governance doesn’t certify that every message will execute successfully under the later chain state.
Text proposals record voting outcomes
Text proposals let delegators agree on a strategy, commitment or future change. Their direct outcome is a recorded governance decision. They don’t transfer community funds, alter a parameter or install software merely because the text requests it. A later implementation needs the relevant executable proposal or another authorized action. Signaling can gather support before technical details exist, though responsibility for implementation remains outside the text vote itself.
Community pool spending names a recipient
Community pool spending authorizes a transfer from shared chain funds to the recipient named in a message that specifies the amount and its denomination. The proposer and recipient can be different accounts. A valid spending message requires the correct governance authority, an acceptable destination and enough available pool funds. Naming money or a recipient only in supporting prose doesn’t create a transfer instruction.
Successful execution transfers the specified funds. The spending message contains no check that a funded project met its milestones or delivered its intended benefit, so any delivery requirements need separate arrangements.
Software upgrades depend on a plan and matching node software
Software upgrade proposals authorize a change to node software through an upgrade plan. The plan identifies an upgrade name and a target block height, with additional information for operators. Approval schedules that plan when the proposal message executes. The new rules depend on the binary that implements the upgrade, including any migrations that the chain requires. The voting deadline and the upgrade height describe different events.
Scheduling the upgrade
The plan’s height names a block, so its wall-clock timing depends on the chain’s progress. Node operators prepare for that height, and the plan doesn’t distribute the required binary.
Software compatibility at the upgrade height
A matching upgrade handler
The upgraded binary needs a handler that matches the plan’s name. At the scheduled height, the upgrade module invokes that handler and applies any programmed migrations before the application continues processing blocks.
An incompatible binary
Under the scheduled upgrade path, a node without the required handler stops processing at the upgrade height. This prevents that node from continuing under incompatible rules. The governance outcome can remain successful even while an operator still needs to install the matching software.
Cancellation of a pending plan
A cancel-upgrade proposal clears the scheduled plan through the upgrade module. It must take effect before the pending upgrade runs to prevent that transition. Clearing a plan doesn’t undo migrations or transactions that the network has already completed.
Parameter updates change rules that modules already expose
A parameter-update message changes values that a module already exposes to governance, letting those settings alter behavior without necessarily requiring a new software release. The chain’s inflation settings can change through on-chain governance. This connects governance to staking because issuance helps determine the rewards available to participants. A voted change to issuance remains separate from an individual validator’s commission and from the returns that a holder actually receives.
The affected module defines the permitted fields and their validation rules. Governance can update exposed settings; functionality that needs new code still requires a compatible software implementation.
Bonded stake gives delegators and validators voting weight
Bonded native MANTRA supplies voting power through the staking module, so the tally doesn’t use a simple count of wallet addresses. A delegator who votes directly overrides the validator’s choice for that delegator’s stake. When the delegator doesn’t vote, the validator’s recorded choice carries the delegated weight; a validator who also doesn’t vote contributes no such choice. The tally considers bonded validators and delegation shares. Spendable tokens alone don’t create that bonded voting weight, and proposal deposits don’t replace the staking requirement.
Voting options and final status describe different outcomes
Yes supports adoption and No opposes it. Abstain contributes to participation without supporting either side. NoWithVeto can block approval when its share exceeds the active veto threshold. Quorum measures participating voting power against total bonded voting power. The approval threshold applies to non-abstaining votes, while the veto calculation includes all participating voting power. A high displayed Yes share can still accompany too little participation for approval. If all participating voting power abstains, the proposal cannot pass even when participation reaches quorum. The active parameters supply the thresholds; no single percentage describes every governance decision.
After voting ends, the governance module tallies the result and attempts the authorized messages if the vote passes. Rejected identifies a tally that didn’t approve the proposal, while Failed identifies a proposal that couldn’t execute successfully. An execution error in a multi-message proposal prevents the module from retaining partial changes from that message batch. Passed confirms successful processing of the payload, which for a software upgrade schedules implementation at a later height.
Deposit rules determine entry into voting and treatment of funds
Proposal deposits control entry into voting and protect against spam. A submission can start below the total deposit required for voting, provided it satisfies the initial submission requirements. Reaching the applicable minimum before the deposit deadline opens voting. If the minimum isn’t reached in time, governance removes the proposal without a vote. The governance parameter query returns the deposit denomination, minimum amount and allowed period for that network; each proposal record carries its own deposit deadline and voting times. Ordinary and expedited proposals can use different configured deposit requirements. Those values can change, so an old proposal’s amount doesn’t establish the requirement for another submission.
Governance holds deposited funds separately from ordinary transaction fees. Passing the tally returns deposits, while a rejection can also return them. Separate burn settings govern missed quorum, veto rejection and failure to reach voting, so the cause of rejection matters. The fee that the network charges for processing a transaction serves a different purpose, and depositing funds doesn’t cast a vote for the proposal.
Metadata explains a proposal without extending its powers
The title and summary make a proposal readable, while supporting metadata can describe its rationale, authors and discussion. The drafting process separates the proposal transaction from a metadata document and supports storing that document through IPFS, the InterPlanetary File System. The on-chain metadata field identifies the supporting material. Accessible metadata helps participants understand the requested decision.
A description can discuss tokenization or application development. Only the authorized payload specifies the protocol action; publishing supporting metadata doesn’t grant additional execution rights.
Text votes signal intent and executable proposals authorize chain actions
If your next step depends on a verifiable chain change, compare the proposal’s payload with the outcome you need before choosing how to participate.
- Identify the action: agreement in a text proposal, a community pool transfer, a parameter update or an upgrade plan.
- Read the live proposal status, voting end time and governance parameters that apply to the chosen mode.
- Confirm that the signing interface supports the chain’s governance operation. If it doesn’t, the documented mantrachaind interface provides a command-line alternative through a compatible node.
- Submit a vote only during the voting period, then confirm successful inclusion and the recorded choice for the signing address.
- Before relying on implementation, confirm the result that matches the action: a completed transfer, the revised parameter or the applied upgrade.
A text vote suits a decision that needs a recorded expression of support. An executable proposal suits a decision that needs a permitted chain action. For an upgrade, the scheduled plan and the applied software remain different results. If the necessary message or software support is absent, signaling can record intent while implementation needs further work.
Mantra - your questions answered
Do I need to fund a Mantra proposal before I can vote on it?
You don’t need to contribute to a proposal’s deposit to cast a governance vote. The proposal must have entered its voting period, and bonded stake determines your voting weight. A vote is a transaction, so its processing fee is separate from any proposal deposit. Supporting the deposit and choosing a ballot option serve different purposes.
Are my governance votes visible to other people?
On-chain governance votes publicly associate a voting address with its recorded choice. During voting, governance queries expose individual choices; transaction records also show the account and submitted vote. An address doesn’t automatically reveal a person’s identity, although other public activity can connect it to them.
Can someone else contribute to my proposal’s deposit?
Other accounts can contribute to the deposit for an existing proposal. Contributions accumulate toward the minimum that the chain requires to open voting, subject to the deposit rules and deadline. Each contributor remains the depositor for their own funds. Contributing doesn’t give that account ownership of the proposal or automatically cast a Yes vote.
Does a weighted vote give an account extra voting power?
A weighted vote divides an account’s existing voting power among ballot options without increasing that power. The option weights must total one, and the vote cannot repeat the same option. The staking relationship still determines the underlying weight. A signing interface needs support for the weighted-vote message to offer that choice.
Which units should I use when entering a governance deposit?
Use the denomination and base units that the chain’s governance parameters require. Native MANTRA transactions use amantra, where one MANTRA equals 10^18 amantra. A whole-coin display and a base-unit transaction field therefore represent different scales. The denomination identifies the coin; the amount specifies how many base units the transaction deposits.
Will an expedited proposal use the ordinary voting deadline?
An expedited proposal uses the expedited voting period configured in governance parameters. Its approval threshold and minimum deposit also have separate settings. If it doesn’t pass the expedited tally, the governance module converts it to an ordinary proposal and applies the ordinary voting schedule. The proposal’s recorded voting end time distinguishes the active deadline from an earlier expedited deadline.
When can a proposer withdraw an active governance proposal?
The recorded proposer can cancel their proposal during the deposit or voting period before voting ends. Cancellation uses the proposer account, and governance settings determine the charge on deposits and its destination. Governance burns the charged portion if no destination is configured. Any remaining funds return to depositors. Withdrawing an active proposal differs from cancelling an upgrade plan that an earlier proposal already scheduled.
How can I inspect a proposal without signing a transaction?
Read-only governance queries let you inspect proposals, recorded votes and tally information without signing a transaction. The mantrachaind query interface accesses that data through a node. Inspecting a proposal doesn’t submit a ballot or transfer funds. A separate signed transaction submits a proposal, contributes a deposit or casts a vote.
Last updated -