Osmosis
Osmosis text proposals record governance approval when they pass, without executing the requested protocol change
Osmosis text proposals let OSMO stakers approve a direction while leaving implementation to a separate action. A passed text proposal records community support; it doesn’t rewrite a parameter, transfer community-pool funds, or install software described in the text. Those outcomes require an executable proposal or other authorized implementation suited to the requested change. The distinction starts with the submitted proposal type and its contents. Governance also includes proposals carrying messages the chain can execute, so the text-proposal rule doesn’t describe every vote. Deposits and voting thresholds determine whether a proposal reaches approval; the implementation mechanism determines what happens afterward.
In short: A passed text proposal establishes governance approval, while the requested change still needs a compatible execution mechanism and authorized implementation.
Casting a vote with complete proposal details
A compatible governance interface lets OSMO stakers inspect a text proposal and vote during its voting period. If it omits legacy content, inspect the full onchain proposal record before signing. Consider a hypothetical text proposal requesting a parameter change. Passing this text proposal leaves the requested parameter untouched. Voting eligibility and approval still follow the active governance settings.
- Confirm the submitted content is a text proposal; a descriptive title alone doesn’t establish its type.
- Read its status and voting end time; a proposal still collecting the required deposit hasn’t opened voting.
- Read the applicable thresholds from the chain’s governance parameters instead of reusing an old percentage.
- Inspect the vote message’s proposal identifier and choice before authorizing the transaction.
- Confirm the vote transaction executed successfully onchain; recording a choice doesn’t establish the proposal’s final approval.
After passage, the approved text proposal can coexist with the old parameter value. A later authorized parameter update supplies evidence of implementation.
Which governance proposals can execute changes?
A proposal can execute a change when it carries a supported message or executable legacy content the chain routes to a registered handler. The chain uses Cosmos SDK governance to process those instructions after a successful tally. A text-only proposal doesn’t execute the protocol changes described in its text. Writing an amount, recipient, or proposed parameter value in prose doesn’t supply the matching executable instruction.
Legacy content includes signaling text and executable module-specific proposal types. A legacy wrapper therefore doesn’t establish whether the proposal changes protocol state.
Titles and summaries also accompany executable proposals. Their wording can describe an action without determining its technical effect. The actual message identifies the operation and its inputs. Supported parameter updates differ from software-upgrade plans, and community-pool spending identifies a recipient and token amount.
The deposit opens voting without funding the requested work
A proposal enters voting only after its collected deposit meets the applicable minimum under the governance parameters. The submission deposit, later contributions, and voting transaction fee have different purposes. Depositors place tokens with the governance module to support admission of the proposal. They aren’t paying the named project or replacing a community-pool spending instruction. The initial-deposit requirement and full deposit threshold can also differ. Refund and burn rules depend on the proposal outcome and configured deposit policies, including veto, failure to enter voting, and cancellation. A text proposal’s lack of executable change doesn’t exempt its deposit from those rules.
What determines whether a text proposal passes?
A text proposal passes when its final stake-weighted tally satisfies the applicable quorum, approval, and veto rules. Quorum measures participating bonded voting power against the network’s total bonded voting power, while the approval test uses the Yes share of non-abstaining votes, so neither calculation measures a simple count of wallet addresses. Abstain contributes to quorum while staying outside the Yes-vote approval denominator. No with veto counts toward opposition and a separate veto test. The chain’s governance parameters set the thresholds; text proposals still face those tests even though their requested changes require later work.
The final tally settles the proposal’s decision. A favorable running percentage during the voting period hasn’t yet established passage, and additional votes can change the outcome.
Implementation requires the right permissions and software
Implementing an approved text proposal requires authority over the affected function and a mechanism capable of changing it. Existing module messages can handle supported parameter updates. A change outside the installed software’s capabilities requires development and deployment through the relevant upgrade process. Passage of a text proposal doesn’t grant a proposer arbitrary access to the chain’s state. The author and the people capable of implementation may be different participants.
An executable software-upgrade proposal schedules an upgrade at its specified block height. Node operators must run the required software at that height. The text vote and the scheduled software transition have different technical effects.
Successful execution of a community-pool spending proposal transfers the specified token amount to its recipient, while completing the funded work depends on that recipient’s performance and the commitments described in the proposal. Liquidity-incentive changes likewise need the relevant executable configuration before liquidity pools receive the requested change. The pool’s existence alone doesn’t implement a signaling proposal.
How long does implementation take after a text proposal passes?
A text proposal’s implementation schedule depends on the work and authorized action needed to carry out its request. The voting end time identifies when governance tallies the proposal. It doesn’t specify when developers finish a feature or when an operator applies a later change. A deadline in the description expresses the requested schedule; the prose itself installs no timer. Live governance settings determine voting duration and deposit deadlines. The query
osmosisd query gov params
exposes those parameters, while the stored proposal supplies its own timestamps. A later executable proposal or upgrade plan carries its own conditions.
Approval and completed delivery leave different records
The final proposal record establishes the voting result, while the affected chain state establishes whether an implementation took effect. An executable proposal can satisfy the tally yet finish with a failed status if a message handler returns an error, because governance commits the state changes from its messages only if all execute successfully. An upgrade plan names its activation height; a saved plan alone doesn’t establish active new behavior.
Until the requested change takes effect, users continue interacting with the existing configuration. A passed text proposal alone gives no reason to calculate fees or pool incentives using a proposed replacement value.
Things people ask about Osmosis
Can I change my vote on an active Osmosis text proposal?
You can replace your text-proposal vote while the proposal remains in its voting period. A later successful vote from the same address replaces its earlier recorded choice for that proposal. Once the proposal reaches a final status, you can’t replace its vote; signing a replacement alone doesn’t establish its acceptance onchain.
Is a proposal deposit required for casting a text-proposal vote?
Casting a text-proposal vote doesn’t require you to contribute to the proposal deposit. Voting power comes from eligible staked OSMO, and submitting the vote incurs a network transaction fee. Your available fee balance and your governance voting power serve different purposes, even when both involve OSMO.
Are text-proposal votes private?
Text-proposal votes are public onchain records tied to the voting address. They reveal the proposal identifier and selected option, including any weighted allocation. An address doesn’t, by itself, identify a person’s legal identity. Connecting that address to a public profile can make its votes easier to associate with that person.
Will choosing No with veto burn my staked OSMO?
Casting No with veto doesn’t burn the OSMO you have staked. Deposit-burning rules concern tokens deposited on that proposal and depend on the final result and live settings. A voter who also contributed a deposit holds both roles; the deposit can face the applicable loss conditions.
Can an account submit an Osmosis text proposal without staking OSMO?
An account can submit a text proposal without already holding staked OSMO. Submission still needs the required initial deposit and transaction fee. Staking determines governance voting power, which is a separate requirement from the ability to propose or contribute a deposit. Submission doesn’t entitle the proposer to approval.
What happens to earlier votes when a revised text proposal receives a new proposal identifier?
Votes cast for an earlier proposal don’t count toward a revised proposal with a new identifier. Each submission has a separate voting record and must satisfy its own admission and approval requirements. A similar title, unchanged proposer, or reused wording doesn’t transfer support from the older tally.