Off-Chain Proposal Process

Once a proposal is on-chain, it cannot be changed to reflect feedback or new information. It's 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 severaltypes of proposals supported by the GotaBit Hub:

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.
IBC Client Update - Proposal to update an IBC client.

You'll first want to determine which kind of proposal you are making. Be sure to review all details of your specific proposal type.

Stage 1: Your Idea

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 the GotaBit Hub, 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).

Confident with your idea?

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 GotaBit social group is a great way to get broad feedback and perspective even if you don't have personal connections to any stakeholders or involved parties.

Are you ready to draft a governance proposal?

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 GTB 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.

Stage 2: Your Draft Proposal

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.

Proposal Elements

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 proposal should contain a summmary 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.

Parameter-Change

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

Community-Spend Proposal

Community spend proposal profile

Applicant(s) - The profile of the person(s)/entity making the proposal. Who you are and your involvement in GotaBit 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 GTB. 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 you 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 GotaBit Hub 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.

Engage the community with your draft proposal

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 GotaBit Hub account , the GotaBit Governance account, and other governance-focused groups.

Submit your proposal to the testnet

Before going on 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.

Stage 3: Your On-Chain Proposal

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

The deposit period currently lasts 14 days. If you submitted your transaction with the minimum deposit (512 GTB), your proposal will immediately enter the voting period. If you didn't submit the minimum deposit amount (currently 512 GTB), then this may be an opportunity for others to show their support by contributing (and risking) their GTBs 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 voting period.

The Voting Period

At this point you'll 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.