How to Submit a Governance Proposal on Stabull
Guidelines for Contributors
Governance on Stabull exists to make targeted, evidence-based adjustments to the protocol. As a decentralised organisation, Stabull is proudly governed by our $STABUL token holders.
These guidelines explain how to submit proposals that are aligned with Stabull’s governance scope and are therefore eligible for consideration.
This document should be read alongside:
Stabull Governance Terms of Service (Snapshot)
Stabull Whitepaper
1. What Governance Is For
As defined in the Governance Terms of Service (Section 1.1), governance on Stabull is intended to address protocol-level economic parameters and structural incentives, including:
Protocol fee structures and fee recipients
Liquidity mining incentives and emission frameworks
Staking mechanisms and lockup structures
Governance mechanics and voting parameters
Transparency and reporting commitments
Amendment processes for governance documentation and the whitepaper
Good proposals operate within these boundaries.
Governance exists to correct incentives based on live system behavior — not to replace markets, execution logic, or asset risk assessment
2. What Governance Is Not For
Proposals will be considered out of scope if they attempt to:
Approve or reject specific asset listings
Override asset curation decisions
Modify execution logic, pricing behavior, or AMM mechanics
Change oracle selection or oracle anchoring
Dictate real-time operational or emergency actions
These areas are explicitly excluded from governance under the Governance Terms of Service and remain the responsibility of the core contributors.
Submitting proposals in these areas wastes time and creates false expectations.
3. What Makes a Strong Proposal
A strong Stabull governance proposal answers three questions clearly:
What live behavior or constraint does this proposal address?
Why is governance the appropriate mechanism to address it?
What will not change if this proposal passes?
Proposals are strongest when they:
Reference observed protocol behavior or data
Acknowledge trade-offs and risks
Are narrow in scope
Avoid bundling multiple unrelated changes
Governance is not a brainstorming forum. It is a decision mechanism.
4. Evidence Over Ideology
Stabull is a production system.
Proposals should be grounded in:
Observed incentive outcomes
Fee generation behavior
Liquidity persistence or decay
Capital constraints
Execution quality under real conditions
Where data is incomplete or unavailable, assumptions must be stated explicitly.
Proposals that rely primarily on abstract theory or comparative claims (“other protocols do X”) are unlikely to pass.
5. Scope Discipline Matters
Governance proposals should be incremental and precise.
If a proposal attempts to:
Solve multiple unrelated problems, or
Redefine governance boundaries, or
Implicitly expand governance scope
It should be split into separate proposals or reframed.
Governance effectiveness declines rapidly when scope is not disciplined.
6. Governance Is Iterative, Not Final
As stated in the Governance Terms of Service (Section 5.1), governance outcomes may be reviewed after implementation.
If a change produces unintended or adverse effects:
It may be amended or reversed by subsequent governance proposals
Passing a proposal does not make it permanent in most cases
Proposals should therefore be framed as adjustments, not irreversible commitments.
7. Proposal Lifecycle
A typical governance proposal follows this lifecycle:
Draft & Discussion - Shared informally for feedback and clarification.
Revision - Scope tightened, assumptions clarified, risks acknowledged.
Formal Submission - Submitted using the standard proposal template.
Vote - Conducted via Snapshot under defined parameters.
Implementation & Review - Executed manually where appropriate and later evaluated against expectations.
8. Final Note to Proposers
Good governance proposals respect the system that exists.
They do not assume that voting can override markets, execution, or risk. They aim to improve alignment, not assert control.
If you are unsure whether an idea is in scope, review:
Governance Terms of Service, Section 1.1
When a proposal is ready, it should be submitted via Snapshot using the following template and markdown
Title
Summary (Brief description of what is changing and why.)
Motivation (What live protocol behavior or constraint does this address?)
Proposal (Precisely describe the parameter or structure being changed. State scope: global / per-chain / conditional.)
Rationale (Why is governance the right mechanism, and why now?)
Expected Impact (Intended effects and key trade-offs.)
Out of Scope (Explicitly unchanged: asset listings, execution logic, oracle configuration, operational control.)
Risks (Known downsides, uncertainties, or second-order effects.)
Implementation (High-level execution approach and timing.)
Review (Optional: metrics or time-frame for post-implementation review.)
Last updated