The Kima Network has an on-chain governance mechanism for signaling (text proposals), changing parameters and allocating funds from the community pool.
Kima governance is driven by the Kima community. Proposals can be followed here.
Drafting and submitting a proposal is a process that takes time, attention, and involves risk.
In an ideal world, a proposal should only fail to pass in a situation where engaged and aware make an informed decision to vote down the proposal.
If you are considering drafting a proposal, you should first review the general background on drafting and submission:
How the voting process and governance mechanism works
How to draft your proposal and engage with the Kima community about it
How to format proposals
How to submit your proposal
You should also review details specific to each kind of proposal, listed in this section.
What are signaling proposals currently used for?
Signaling proposals are used to make an on-chain record of support or agreement on a certain topic or ideas. Text proposals do not contain any code. In other words, they do not directly cause any changes to the Hub if they are passed.
Past signaling proposals have been used for a variety of reasons:
Agreement to adopt (or not adopt) a feature in a future release
A high-signal alert to validators
On-chain record of community opinion
Ratification of a social norm
Signaling proposals are a great way to take an official public poll of community sentiment before investing more resources into a project. The most common use of text proposals is to confirm that the community is actually interested in what the proposer wants to develop, without asking for money to fund development that might not be concrete enough to have a budget yet.
Because the results of signaling proposals remain on-chain and are easily accessible to anyone, they are also a good way to formalize community opinions. Information contained in documentation or GitHub repos can be hard to find for new community members but signaling proposals in a block explorer or wallet is very accessible.
You might make a signaling proposal to gather opinions for work you want to do for the Hub, or because you think it is important to have a record of some perspective held by the community at large.
Technically, nothing happens on-chain. No code executes, and this 'unenforceable' property of text proposals is one of the biggest criticisms of the format. Regardless of whether the results of a signaling proposal are enforced by code, there can still be value from having a proposal on-chain and subject to discussion. Whether a proposal passes or fails, we all get information from it having been considered.
The community might have had a thorough, thoughtful discussion about a topic that they otherwise would not have had.
A development team interested in a feature might have a better idea of how their work will be received by the community.
The community might be more informed about a topic.
The community might feel confident that we are aligned on a particular definition or social norm.
Follow the instructions below to create a text proposal and submit it to the network.
Unlocks the potential for token-holders to vote to approve spending from the Community Pool.
2% of all staking rewards generated (via block rewards & transaction fees) are continually transferred to and accrue within the Community Pool. For example, from December 19, 2019 until January 20, 2020 (32 days), 28,726 ATOM were generated and added to the pool.
Though the rate of funding is currently fixed at 2% of staking rewards, the effective rate is dependent upon Kima staking rewards, which can change with inflation and block times. The current parameter Community Tax parameter of 2% may be modified with a governance proposal and enacted immediately after the proposal passes.
You may directly query Kima for the balance of the Community Pool:
Alternatively, the Kima Explorer will display the ongoing Community Pool balance.
Funds from the Kima Community Pool may be spent via a successful governance proposal.
We don't know 🤷
The prevailing assumption is that funds should be spent in a way that brings value to Kima. However, there is debate about how to keep the fund sustainable. There is also some debate about who should receive funding. For example, part of the community believes that the funds should only be used for those who need funding most. Other topics of concern include:
Retroactive grants
Price negotiation
Fund disbursal (eg. payments in stages; payments pegged to reduce volatility)
Radical overhaul of how the community-spend mechanism functions
We can expect this to take shape as proposals are discussed, accepted, and rejected by the Kima community.
How are funds disbursed after a community-spend proposal is passed?
If a community-spend proposal passes successfully, the number of $KIMA encoded in the proposal will be transferred from the community pool to the address encoded in the proposal, and this will happen immediately after the voting period ends.
As a strategy: funding is fast. Besides the time it takes to push your proposal on-chain, the only other limiting factor is a fixed 14-day voting period. As soon as the proposal passes, your account will be credited the full amount of your proposal request.
To build rapport. Engaging publicly with the community is the opportunity to develop relationships with stakeholders and to educate them about the importance of your work. Unforeseen partnerships could arise, and overall the community may value your work more if they are involved as stakeholders.
To be more independent. The Interchain Foundation (ICF) may not always be able to fund work. Having a more consistently funded source and having a report with its stakeholders means you can use your rapport to have confidence in your ability to secure funding without having to be dependent upon the ICF alone
Drafting and submitting a parameter-change governance proposal involves two kinds of risk: losing proposal deposit amounts and the potential to alter the function of the Kima network in an undesirable way.
The complete parameters of the Kima network are split up into different modules, each of which has its own set of parameters. Most parameters can be updated by submitting a governance proposal.
List of modules whose parameters can be changed via governance:
x/auth x/bank x/distribution x/evidence x/feegrant x/gov x/mint x/slashing x/staking ibc-go/transfer interchain-security/provider Each cosmos-sdk module uses MsgUpdateParams for providing parameter changes. You can learn more about it in the cosmos-sdk documentation of each module, for example msgupdateparam
There are ways to query the current settings for each module's parameter(s). Some can be queried with the command line program gaiad. You can begin by using the command gaiad q [module] -h to get help about the subcommands for the module you want to query. For example, gaiad q staking params returns the settings of relevant parameters:
bond_denom: uKIMA max_entries: 7 max_validators: 180 unbonding_time: 1814400s
If a parameter change proposal is successful, the change takes effect immediately upon completion of the voting period.
Note: You cannot currently query the bank module's parameter, which is sendenabled. You also cannot query the crisis module's parameters.
Parameters govern many aspects of Kima's behaviour. As circumstances and attitudes change, sometimes you might want to change a parameter to bring the chain's behaviour in line with community opinion. For example, the Cosmos Hub launched with 100 active validators and there have been 4 proposals to date that have increased the MaxValidators parameter. At the time of writing, the active set contains 180 validators.
The Cosmos Hub has been viewed as a slow-moving, highly secure chain and that is reflected in some of its other parameters, such as a 21 day unbonding period and 14 day voting period. These are quite long compared to other chains in the Cosmos Ecosystem
Because parameters dictate some of the ways in which the chain operates, changing them can have an impact beyond what is immediately obvious.
For example, reducing the unbonding period might seem like the only effect is in how quickly delegators can liquidate their assets. It might also have a much greater impact on the overall security of the network that would be hard to realize at first glance.
This is one of the reasons that having a thorough discussion before going on-chain is so important - talking through the impacts of a proposal is a great way to avoid unintended effects.
Use the draft-proposal command to create a draft proposal and populate it with required information.
The following are parameters that are currently present in the governance process:
Minimum deposit: 10,000 KIMA
Maximum deposit period: 14 days
Voting period: 7 days
Quorum: 33.40% of participating voting power
Pass threshold: 50% of participating voting power
Veto threshold: 33.40% of participating voting power
The deposit period lasts 14 days.
Before a governance proposal enters the voting period (i.e., for the proposal to be voted upon), there must be at least a minimum number of KIMA deposited (10,000). Anyone may contribute to this deposit, though it is usually filled by the proposal maker. Deposits of passed and failed proposals are returned to the contributors.
Deposits are burned only when proposals are vetoed. Deposits are not burned for failing to meet quorum or for being rejected.
The voting period is currently a fixed 7 day period. During the voting period, participants may select a vote of either 'Yes', 'No', 'Abstain', or 'NoWithVeto'. Voters may change their vote at any time before the voting period ends.
Abstain: The voter wishes to contribute to quorum without voting for or against a proposal.
Yes: Approval of the proposal in its current form.
No: Disapproval of the proposal in its current form.
NoWithVeto: NoWithVeto is a mechanism that allows voters to indicate that they strongly disagree with a proposal or if a proposal is identified to be spam. If more than 1/3 of voters cast a NoWithVeto vote, the proposal is rejected.
Voting 'NoWithVeto' has no immediate additional financial cost to the voter - you do not directly risk your KIMA by using this option.
There are four criteria:
Deposit is filled: A minimum deposit of 10,000 KIMA is required for the proposal to enter the voting period
anyone may contribute to this deposit
the deposit must be reached within 14 days (this is the deposit period)
Quorum is reached: A minimum of 33.40% of the network's total voting power (staked KIMA) is required to participate
Simple majority of 'Yes' votes: Greater than 50% of the participating voting power must back the 'Yes' vote by the end of the 7 day voting period
Not vetoed: Less than 33.4% of participating voting power must have backed 'NoWithVeto' by the end of the 7 day voting period
Currently, the criteria for submitting and passing/failing all proposal types is the same.
Once a proposal is on-chain, it cannot be changed to reflect feedback or new information. It is very important to give a proposal time off-chain to receive feedback, input, and edits before going on-chain and asking for votes.
The process of passing a proposal starts long before it goes on-chain!
There are currently several types of proposals supported by Kima:
Text: Proposal to agree to a certain strategy, plan, commitment, future upgrade or other statement. Text proposals do not directly cause any changes, but they can be used to take a record of the community's opinion or commitment to a future idea.
Community Pool Spend: Proposal to spend funds from the community pool on a project
Parameter Change: Proposal to change a core on-chain parameter.
Software Upgrade: Proposal to upgrade the chain version.
You will first want to determine which kind of proposal you are making. Be sure to review all details of your specific proposal type.
Engagement is likely to be critical to the success of a proposal. The degree to which you engage with the Kima community should be relative to the potential impact that your proposal may have on the stakeholders. This guide does not cover all ways of engaging but here are some suggestions:
Post your idea to the Cosmos Hub Forum
Mention the idea in a community call (often hosted on X/Twitter)
Host an AMA on Reddit
We encourage you to experiment and use your strengths to introduce proposal ideas and gather feedback.
There are many different ways to engage. One strategy involves a few stages of engagement before and after submitting a proposal on chain.
Why do it in stages? It's a more conservative approach to save resources. The idea is to check in with key stakeholders at each stage before investing more resources into developing your proposal.
In the first stage of this strategy, you should engage people (ideally experts) informally about your idea. You'll want to start with the minimal, critical components (name, value to Kima, timeline, any funding needs) and check:
Does it make sense?
Are there critical flaws?
How will this affect other projects or properties of the Hub?
You should be engaging with key stakeholders (e.g., a large validator operator) with a few short sentences to measure their support. Here is an example:
"We are considering a proposal for funding to work on project. We think it will help the Hub to outcome. Timeline is x, and we're asking for y amount. Do you think that this is a proposal that large validator may support?"
Why a large validator? They tend to be the de facto decision-makers on Kima, since their delegators also delegate their voting power. If you can establish a base layer of off-chain support, you can be more confident that it's worth proceeding to the next stage.
Note: Many validators will likely hesitate to commit support, and that's okay. It will be important to reassure these stakeholders that this isn't a binding commitment. You're just canvasing the community to get a feel for whether it's worthwhile to proceed. It's also an opportunity to connect with new people and to answer their questions about what it is you're working on. It will be important for them to clearly understand why you think what you're proposing will be valuable Kima, and if possible, why it will be valuable to them as long-term stakeholders.
If you're already confident about your idea, skip to Stage 2.
Not yet confident about your idea?
Great! Governance proposals potentially impact many stakeholders. Introduce your idea with known members of the community before investing resources into drafting a proposal. Don't let negative feedback dissuade you from exploring your idea if you think that it's still important.
If you know people who are very involved with Kima, send them a private message with a concise overview of what you think will result from your idea or proposed changes. Wait for them to ask questions before providing details. Do the same in semi-private channels where people tend to be respectful (and hopefully supportive).
Great! However, remember that governance proposals potentially impact many stakeholders, which can happen in unexpected ways. Introduce your idea with members of the community before investing resources into drafting a proposal. At this point you should seek out and carefully consider critical feedback in order to protect yourself from confirmation bias. This is the ideal time to see a critical flaw, because submitting a flawed proposal on-chain will waste resources and have reputational costs.
Posting your idea to the Cosmos Hub Forum is a great way to get broad feedback and perspective even if you don't have personal connections to any stakeholders or involved parties.
There will likely be differences of opinion about the value of what you're proposing to do and the strategy by which you're planning to do it. If you've considered feedback from broad perspectives and think that what you're doing is valuable and that your strategy should work, and you believe that others feel this way as well, it's likely worth drafting a proposal. However, remember that the largest KIMA stakers have the biggest vote, so a vocal minority isn't necessarily representative or predictive of the outcome of an on-chain vote.
You could choose to take a conservative approach and wait until you have some confidence that you roughly have initial support from a majority of the voting power before proceeding to drafting the details of your proposal. Or you could propose the idea, or define the problem statement and let the community participate freely in drafting competing solutions to solve the issue.
The next major section outlines and describes some potential elements of drafting a proposal. Ensure that you have considered your proposal and anticipated questions that the community will likely ask. Once your proposal is on-chain, you will not be able to change it.
It will be important to balance two things: being detailed and being concise. You'll want to be concise so that people can assess your proposal quickly. You'll want to be detailed so that voters will have a clear, meaningful understanding of what the changes are and how they are likely to be impacted.
Each major proposal type has a rough template available on the forum: Text, community pool spend, parameter change, software upgrade.
Each proposal should contain a summary with key details about what the proposal hopes to change. If you were viewing only the summary with no other context, it should be a good start to being able to make a decision.
Assume that many people will stop reading at this point. However it is important to provide in-depth information. The on-chain proposal text should also include a link to an un-editable version of the text, such as an IPFS pin, and a link to where discussion about the idea is happening.
A few more pointers for Parameter Change and Community Spend proposals are below.
An example of a successful parameter change proposal is Proposal #66. Note that this proposal went on-chain without the recommended IPFS pin.
Problem/Value: The problem or value that's motivating the parameter change(s).
Solution: How changing the parameter(s) will address the problem or improve the network.
Risks & Benefits: How making this/these change(s) may expose stakeholders to new benefits and/or risks.
The beneficiaries of the change(s) (ie. who will these changes impact and how?)
Voters should understand the importance of the change(s) in a simple way
Supplementary materials: Optional materials eg. models, graphs, tables, research, signed petition, etc
An example of a successful community spend proposal is Proposal #63.
Applicant(s) - The profile of the person(s)/entity making the proposal. Who you are and your involvement in Kima and/or other blockchain networks. An overview of team members involved and their relevant experience. Problem - What you're solving and/or opportunity you're addressing. Past, present (and possibly a prediction of the future without this work being done). Solution - How you're proposing to deliver the solution. Your plan to fix the problem or deliver value. The beneficiaries of this plan (ie. who will your plan impact and how?). Your reasons for selecting this plan. Your motivation for delivering this solution/value. Funding - amount and denomination proposed eg. 5000 KIMA. The entity controlling the account receiving the funding. Consider an itemized breakdown of funding per major deliverable. Note that the 'budget' of a spend proposal is generally the easiest thing to criticize. If your budget is vague, consider explaining the reasons you're unable to give a detailed breakdown and be clear about what happens if you do not meet your budget. Deliverables and timeline - the specifics of what you're delivering and how, and what to expect. What are the specific deliverables? (be detailed). When will each of these be delivered? How will each of these be delivered? What will happen if you do not deliver on time? Do you have a plan to return the funds if you're under-budget or the project fails? How will you be accountable to the KIMA stakeholders? How will you communicate updates and how often? How can the community observe your progress? How can the community provide feedback? How should the quality of deliverables be assessed? eg. metrics. Relationships and disclosures. Have you received or applied for grants or funding? for similar work? eg. from the Interchain Foundation. How will you and/or your organization benefit? Do you see this work continuing in the future and is there a plan? What are the risks involved with this work? Do you have conflicts of interest to declare? Begin with a well-considered draft proposal
Ideally, a proposal is first sent to the forum in Markdown format so that it can be further edited and available for comments. A changelog is a great tool so that people can see how the idea has developed over time and in response to feedback.
This Markdown-formatted post can eventually become the description text in a proposal sent on-chain.
Post a draft of your proposal as a topic in the appropriate category of the forum. Hub Proposals is a catch-all if you are not sure where to post, but there are categories for all types of proposals. Directly engage key members of the community for feedback. These could be large contributors, those likely to be most impacted by the proposal, and entities with high stake-backing (eg. high-ranked validators; large stakers). Alert the entire community to the draft proposal on other platforms such as Twitter, tagging accounts such as the Cosmos Hub account, the Cosmos Governance account, and other governance-focused groups.
Before going to mainnet, you can test your proposal on the testnet.
This is a great way to make sure your proposal looks the way you want and refine it before heading to mainnet.
A majority of the voting community should probably be aware of the proposal and have considered it before the proposal goes live on-chain. If you're taking a conservative approach, you should have reasonable confidence that your proposal will pass before risking deposit contributions. Make revisions to your draft proposal after each stage of engagement.
See the submitting guide for more on submitting proposals.
The deposit period currently lasts 14 days. If you submitted your transaction with the minimum deposit (10,000 KIMA), your proposal will immediately enter the voting period. If you did not submit the minimum deposit amount, then this may be an opportunity for others to show their support by contributing (and risking) their KIMA as a bond for your proposal. You can request contributions openly and also contact stakeholders directly (particularly stakeholders who are enthusiastic about your proposal). Remember that each contributor is risking their funds, and you can read more about the conditions for burning deposits here.
This is a stage where proposals may begin to get broader attention. Some block explorers display proposals in the deposit period, while others don't show them until they hit the voting period.
A large cross-section of the blockchain/cryptocurrency community exists on Twitter/X. Having your proposal in the deposit period is a good time to engage the so-called 'crypto Twitter' Kima community to prepare validators to vote (eg. tag @cosmosvalidator) and KIMA-holders that are staking (eg. tag @cosmoshub, @CosmosGov).
At this point you will want to track which validator has voted and which has not. You'll want to re-engage directly with top stake-holders, ie. the highest-ranking validator operators, to ensure that:
They are aware of your proposal
They can ask you any questions about your proposal; and
They are prepared to vote.
Remember that any voter may change their vote at any time before the voting period ends. That historically doesn't happen often, but there may be an opportunity to convince a voter to change their vote. The biggest risk is that stakeholders won't vote at all (for a number of reasons). Validator operators tend to need multiple reminders to vote.
How you choose to contact validator operators, how often, and what you say is up to you--remember that no validator is obligated to vote, and that operators are likely occupied by competing demands for their attention. Take care not to stress any potential relationship with validator operators.