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.