Every User is encouraged to contribute to the cheqd Network. To make this easy, it is important to explain HOW a User can contribute, and what the best practices are for making changes.
For this reason, it is important to distinguish when a change can be made entirely off-ledger, and when a change is needed to be voted on, and made on-ledger. To do this we must differentiate between minor changes which are able to take place entirely off-ledger and major network changes which need to be formalised on-ledger.
These are changes that are insignificant, and do not affect the way the Network runs overall. Minor Network changes include, but are not limited to:
Textual edits to the Governance Framework or written general documentation;
Sensible additions to general documentation to improve clarity;
Minor code changes;
Finding, reporting and suggesting fixes to bugs;
Translating the cheqd documentation into various languages.
These are changes that have a materially significant effect on the Network. Such changes SHOULD be made via a Proposal, following the steps in the decision tree diagram below.
Major Network changes include, but are not limited to:
Materially significant Architecture Decisions (ADs), such as:
An additional feature to cheqd;
Removal of a feature of cheqd;
Parameter changes for the Network;
Community pool decisions;
Materially significant changes to a cheqd Principle;
Significant connections to other infrastructure.
See more below:
This means, that major network changes should never oppose a Principle, unless it is acting to update or change a Principle.
You do not have to own any CHEQ to participate in our community discussion. You are free to learn about cheqd and participate in our community discussions across multiple platforms and forums.
These are changes that are insignificant, and do not affect the way the Network runs overall. Minor Network changes include, but are not limited to:
Textual edits to the Governance Framework or written general documentation;
Sensible additions to general documentation to improve clarity;
Minor code changes;
Finding, reporting and suggesting fixes to bugs;
Translating the cheqd documentation into various languages.
To help YOU understand how to make changes on the cheqd Network, the decision tree below visualises how changes should be carried out.
One of the core components of cheqd governance is having both on-chain and off-chain voting mechanisms.
Off-chain voting should be used for Minor Network Changes as well as for more general community polling.
cheqd uses the Governance platform Commonwealth to enable off-chain votes on specific forum discussion topics.
We will point the community to off-chain votes using our Telegram and Discord to keep all of the community in the loop.
You are able to make revisions and amendments to the Wiki and source code without making a formal Proposal.
cheqd is an Open Source project which means that anyone is free to propose or make a revision, addition or amendment.
Changes can be made through two routes:
GitBook is where cheqd's Wiki lives and where YOU can make suggested changes to the written documentation.
We suggest that YOU use our GitBook if you are unfamiliar with GitHub or if you prefer visual editors to code-based editors.
We have a Wiki for:
To make a change on either Wiki, you need to use the link below to become an Open Source Editor on cheqd's GitBook:
Once you have made your account using the link above, you will be classified as a Editor on cheqd's GitBook. This will give you the ability to make edits and submit them to be reviewed by a Reviewer. Reviewers are able to merge submitted changes.
You should follow these instructions to make a edit to any cheqd GitBook content.
Make your edits in the text directly or use comments: Via the link above, you will gain permissions to to read, edit and comment directly to the text. If you are confident with your edits, you can write and amend the text directly. If you are less confident, you can leave comments in the text, which admins will review and make changes from accordingly.
Save your changes as a draft: You can save your changes as a draft and return to your draft later. If you want to remind yourself with the changes you made previously, you should click the Diff view button:
Submit your changes: Once you are happy with your changes in your draft you should click Submit. This will send your changes to one of our Reviewers to be moderated before being pushed onto the documentation. There will be a pop-up asking you to explain the changes you made. Make sure to write a clear sentence summarising your main changes to make it easier for the cheqd reviewers to go through your work.
You should keep your changes in drafts until you are happy with them.
Following this as best practice, avoids the Wiki being misused or flooded with changes from one person.
You may also use GitHub to make changes and amendments to both the source code and the written content in this documentation.
We have multiple GitHub repositories which can all be accessed here.
For instructions about making edits to GitHub repositories, we suggest you follow the instructions here.
Please use clean, concise titles for your pull requests. Assume that the person reading the pull request title is not a programmer, but instead a cheqd Network user or lay-person, and try to describe your change or fix from in plain English. We use commit squashing, so the final commit in the main branch will carry the title of the pull request, and commits from the main branch are fed into the changelog. The changelog is separated into keepachangelog.com categories, and while that spec does not prescribe how the entries ought to be named, for easier sorting, start your pull request titles using one of the verbs "Add", "Change", "Deprecate", "Remove", or "Fix" (present tense).
Example:
It is not always possible to phrase every change in such a manner, but it is desired.
The smaller the set of changes in the pull request is, the quicker it can be reviewed and merged. Splitting tasks into multiple smaller pull requests is often preferable.
Pull requests that do not pass automated checks may not be reviewed.
During the course of cheqd's lifecycle, it is likely that bugs will arise. Reporting these bugs effectively and resolving them promptly will be very important for the smooth running of the Network.
Bugs can be discussed or raised in our Telegram or Discord.
If there is common acknowledgement of the bug, next the bug SHOULD be highlighted as an issue in our forum, at:
Please use the search function to make sure that you are not submitting duplicates, and that a similar report or request has not already been resolved or rejected.
We would greatly appreciate this work from our community to ensure that cheqd reaches a diverse, multijurisdictional and multilingual spread of society.
We are currently working on a simple process for submitting translations through a GitHub branch. Please bear with us until we figure out a simple way to achieve this.
Whenever a major network change takes place on the Network, reference MUST be made to . The Principles should act as a checks and balance against major network changes.
| Not ideal | Better |
|---|---|
Fixed NoMethodError in RemovalWorker
Fix nil error when removing statuses caused by race condition
These are changes that have a materially significant effect on the Network. Such changes SHOULD be made via a Proposal, following the steps in the decision tree diagram below.
Major Network changes include, but are not limited to:
Materially significant Architecture Decisions (ADs), such as:
An additional feature to cheqd;
Removal of a feature of cheqd;
Parameter changes for the Network;
Community pool decisions;
Materially significant changes to a cheqd Principle;
Partnerships or connections to other infrastructure.
To help YOU understand how to make changes on the cheqd Network, the decision tree below visualises how changes should be carried out.
One of the most important questions in this Governance Framework is explaining how any User or Participant can make a proposal or voice their opinion on the Network.
There are two ways of doing this:
Informal ‘off-chain’ proposal
Formal ‘on-chain’ proposal’
These will be discussed in turn.
Rather than making a proposal directly to the Network, proposals SHOULD first be made off-chain.
Off-chain governance is vital for building a healthy and active governance community.
cheqd's off-chain forum is on Commonwealth:
You SHOULD gain feedback on you proposal on Commonwealth before posting any proposal to the cheqd mainnet. Off-chain proposals give the User proposing the Proposal can have more confidence that a Proposal will reach minimum deposit and be approved on-chain.
Before you make a Network Proposal, you should engage people (ideally experts) informally about your idea. You should consider:
Does it make sense?
Are there critical flaws?
Does it need to be reconsidered?
Governance proposals potentially impact many stakeholders. Introduce your idea with known members of the community before investing resources into drafting a formal 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 cheqd, send them a private message with a concise overview of what you think will result from your idea or proposed changes.
You could ask a simple question or present an idea on our Commonwealth, for example:
You may also want to rationalise your idea, or ask your question to the wider community, in:
Engagement is likely to be critical to the success of a proposal. The degree to which you engage with the cheqd community should be relative to the potential impact that your proposal may have on the Network.
Great! However, we still recommend that you introduce your idea with members of the community before investing resources into drafting a proposal on-ledger. 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 will waste resources.
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.
Engage the community with your draft proposal
Post a draft of your proposal as a thread in cheqd Proposal Discussion forum
Post a link to the proposal in the cheqd Discord Proposal channel
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 Node Operators; large stakers).
Target members of the community in a semi-public way before bringing the draft to a full public audience.
Alert the community to the draft proposal via:
Twitter, tagging accounts such as the cheqd account
Once you have sensibly tested your Proposal and bounced your ideas around the community, you are ready to submit a Proposal on-chain.
There are two ways to submit a Proposal on chain, a technical and a non-technical way.
You are able to connect the cheqd Commonwealth forum to your Keplr wallet.
Once you have connected your Keplr wallet, you can create an On-Chain proposal directly through the interface.
You will need a minimum amount of 8000 $CHEQ in order to make a Governance Proposal using Commonwealth. This is important to reduce spam Proposals on the Network.
Currently, on Commonwealth, there is only a Text-Based Proposal and a Community-Spend Proposal option. Parameter Changes and Software Upgrade proposals must be made through the Command Line Interface, below.
If you are using the cheqd Command Line Interface, you must follow the instructions below.
Prior to sending the transaction that submits your Proposal on-chain, you must create a JSON file. This file will contain the information that will be stored on-chain as the governance Proposal. Begin by creating a new text (.txt) file to enter this information. Use these best practices as a guide for the contents of your proposal. When you're done, save the file as a .json file. See the examples that follow to help format your proposal.
Each Proposal type is unique in how the .json should be formatted:
To create a new Proposal type, you can propose a ParameterChangeProposal with a custom handler, to perform another type of state change.
Once on-chain, most people will rely upon Block Explorers to interpret this information with a Graphical User Interface (GUI).
cheqd noded is the Command-Line Interface (CLI) client that is used to send transactions and query the cheqd testnet or mainnet;
tx gov submit-proposal and --type="Text" indicates that the transaction is submitting a text proposal;
--from is the account key that pays the transaction fee and deposit amount;
--gas the maximum amount of gas you accept may be used to process the transaction:
The more content there is in the description of your proposal, the more gas your transaction will consume;
If this number isn't high enough and there isn't enough gas to process your transaction, the transaction will fail;
The transaction will only use the amount of gas needed to process the transaction.
--gas-prices is a flat-rate incentive for a Node Operator to process your transaction:
The cheqd Network accepts zero fees, but many nodes will not transmit your transaction to the network without a minimum fee;
Many nodes use a minimum fee to disincentivize transaction spamming;
This can also be set to "auto"
--gas-adjustment is the range of gas prices that will still enable the transaction to go through. We recommend "1.2" or "1.3"
--chain-id is relevant chain ID, e.g., cheqd-mainnet-1
To prevent spam, Proposals must be submitted with a deposit in the coins defined in the MinDeposit param. The voting period will not start until the Proposal's deposit equals MinDeposit.
When a Proposal is submitted, it has to be accompanied by a deposit that must be strictly positive, but can be inferior to MinDeposit. The submitter doesn't need to pay for the entire deposit on their own. If a Proposal's deposit is inferior to MinDeposit, other token holders can increase the Proposal's deposit by sending a Deposit transaction.
The deposit is kept in an escrow in the governance ModuleAccount until the proposal is finalized (passed or rejected).
Once the proposal's deposit reaches MinDeposit, it enters the voting period. If a proposal's deposit does not reach MinDeposit before MaxDepositPeriod, the proposal closes and nobody can deposit on it anymore.
In this scenario, the tokens spent on the Deposit which did not reach the MinDeposit will be burnt, meaning that they will be removed from the active pool of tokens and put beyond use.
The minimum deposit for cheqd will initially be 8,000 CHEQ.
The MaxDepositPeriod will be 1 week.
When a proposal is finalized, the coins from the deposit are either refunded or burned, according to the final tally of the proposal:
If a proposal does not reach MinDeposit, the CHEQ in the governance ModuleAccount will be burnt, which means that they will be put beyond use and removed from the ecosystem.
If the proposal reaches MinDeposit and is approved or rejected but not vetoed, deposits will automatically be refunded to their respective depositor (transferred from the governance ModuleAccount).
If the proposal is approved, but the minimum quorum (33.34%) is not reached for the vote, deposits will be burned from the governance ModuleAccount.
When the proposal is vetoed by 33.34%, deposits will be burned from the governance ModuleAccount.
After posting your transaction, your command line interface will provide you with the transaction's hash, which you can query using the cheqd Block Explorer below:
There are a number of reasons why a transaction may fail. Here are two examples:
Running out of gas - The more data there is in a transaction, the more gas it will need to be processed. If you don't specify enough gas, the transaction will fail and your gas will be consumed by the network.
Incorrect denomination - You may have specified an amount in 'nanocheq' or 'microcheq' instead of 'ncheq', causing the transaction to fail.
If you encounter a problem, try to troubleshoot it first, and then ask for help. We also encourage you to propose edits to this document as the Network progresses so that it can improve for future use.
