提案一旦上链，就无法再根据反馈或新信息进行修改。因此，在上链并发起投票之前，务必要留出充分的链下时间，让提案接收反馈、意见和修订。 推动一项提案通过的过程，早在它上链之前就已经开始了。 目前 Cosmos Hub 支持多种提案类型：
  • 文本提案 - 用于就某项策略、计划、承诺、未来升级或其他声明达成共识的提案。文本提案不会直接引发任何变更，但可用于记录社区对某个未来想法的意见或承诺。
  • 社区资金池支出 - 从社区资金池中拨款支持某个项目的提案。
  • 参数变更 - 用于修改某个核心链上参数的提案。
  • 软件升级 - 用于升级链版本的提案。
  • IBC 客户端更新 - 用于更新 IBC 客户端的提案。
你首先需要明确自己要发起的是哪一种提案。务必查看与你的具体提案类型相关的所有细节。

​
直接与投票社区互动并征求反馈

互动很可能是提案成功的关键。你与 Cosmos Hub 社区互动的深度，应与提案可能对利益相关方造成的潜在影响相匹配。本指南无法涵盖所有互动方式，但以下是一些建议： 我们鼓励你积极尝试，发挥自己的优势来介绍提案想法并收集反馈。 互动的方式有很多。一种策略是在提案上链提交前后，分几个阶段进行沟通。 为什么要分阶段进行？ 这是更保守的做法，可以节省资源。核心思路是在每个阶段先与关键利益相关方确认，再决定是否投入更多资源来完善提案。 在这一策略的第一阶段，你应先就自己的想法与他人进行非正式沟通，最好是相关领域的专家。开始时只需要提供最小但关键的信息（名称、对 Cosmos Hub 的价值、时间线、资金需求），并确认以下几点：
  • 这件事是否讲得通？
  • 是否存在关键缺陷？
  • 这会如何影响 Hub 的其他项目或属性？
你应使用几句简短的话与关键利益相关方（例如大型验证者运营者）沟通，以衡量他们的支持意愿。示例如下： “我们正在考虑发起一项提案，为 project 提供资金支持。我们认为它将帮助 Hub 实现 outcome。时间线是 x，我们申请的金额是 y。你认为这是否会是一项 large validator 可能支持的提案？” 为什么是大型验证者？ 因为他们通常是 Cosmos Hub 事实上的决策者，他们的委托人也将投票权委托给了他们。如果你能先建立一层链下支持基础，就可以更有信心地推进到下一阶段。 注意： 很多验证者可能不会轻易承诺支持，这没有问题。重要的是让这些利益相关方放心，这并不是具有约束力的承诺。你只是在社区中做摸底，判断是否值得继续推进。这也是一个与新的人建立联系、回答他们关于你正在推进事项的问题的机会。重要的是让他们清楚理解，为什么你认为自己的提案会为 Cosmos Hub 带来价值；如果可能，也要说明为什么这对他们这些长期利益相关方同样有价值。 如果你已经对自己的想法很有信心，可以跳到阶段 2。

​
阶段 1：你的想法

​
你对自己的想法还没有信心？

很好。治理提案可能会影响许多利益相关方。在投入资源起草提案之前，先向社区中已知成员介绍你的想法。如果你依然认为这个想法很重要，不要因为负面反馈就放弃继续探索。 如果你认识一些深度参与 Cosmos Hub 的人，可以先私信他们，用简明的方式概述你认为该想法或拟议变更将带来的结果。在他们提出问题之前，不要急于展开细节。在一些相对私密、大家通常较为尊重彼此（并且希望也较支持）的渠道中，也可以采用同样的方式。

​
你对自己的想法有信心？

很好。但请记住，治理提案可能会影响许多利益相关方，而且这种影响可能以意想不到的方式发生。在投入资源起草提案之前，先向社区成员介绍你的想法。在这个阶段，你应主动寻求并认真考虑批判性反馈，以防止自己陷入确认偏误。这是发现重大缺陷的最佳时机，因为把存在缺陷的提案提交上链，会浪费资源并带来声誉成本。 即使你与任何利益相关方或参与方都没有私人联系，把想法发布到 Cosmos Hub Forum 也是获取广泛反馈和不同视角的好方法。

​
你准备好起草治理提案了吗？

对于你要做的事情是否有价值，以及你计划采用的实施策略，很可能会存在不同意见。如果你已经从广泛角度考虑过反馈，认为自己所做的事情有价值、策略也应当可行，并且相信其他人也有类似看法，那么起草提案通常就是值得的。不过请记住，持有最多 ATOM 的质押者拥有最大的投票权，因此，声音很大的少数群体并不一定具有代表性，也不一定能预测链上投票结果。 你可以选择更保守的方式，在继续起草提案细节之前，先等到自己大致确认已获得多数投票权的初步支持。或者，你也可以先提出这个想法，或先定义问题陈述，让社区自由参与，起草彼此竞争的解决方案来解决这一问题。

​
阶段 2：你的提案草案

下一大节将概述并说明起草提案时可能包含的一些要素。请确保你已经充分考虑自己的提案，并预判社区很可能提出的问题。一旦你的提案上链，你将无法再修改。

​
提案要素

有两点需要平衡：详尽与简洁。你需要足够简洁，这样大家才能快速评估你的提案；同时也要足够详细，让投票者能够清晰且有实际意义地理解将发生哪些变更，以及这些变更可能如何影响他们。 论坛上为每一种主要提案类型都提供了一个大致模板：文本提案、社区资金池支出、参数变更、软件升级。 每个提案都应包含一段摘要，说明该提案希望推动的关键变更细节。即使只看这段摘要、没有任何其他上下文，它也应足以成为做出判断的良好起点。 要假设很多人读到这里就会停止继续阅读。但提供深入信息依然很重要。链上提案文本还应包含一个不可编辑版本文本的链接，例如 IPFS pin，以及一个关于该想法正在进行讨论的位置链接。 下面还提供了针对参数变更提案和社区支出提案的一些补充建议。

​
参数变更

一个成功的参数变更提案示例是 Proposal #66。请注意，该提案上链时并没有附上推荐的 IPFS pin。
  1. 问题/价值 - 推动参数变更的核心问题或价值。
  2. 解决方案 - 变更参数将如何解决问题或改进网络。
  3. 风险与收益 - 进行这一项或多项变更后，利益相关方可能面临哪些新增收益和/或风险。
    • 变更的受益者（即这些变更会影响谁，以及如何影响？）
    • 投票者应能用简单方式理解这些变更的重要性
  4. 补充材料 - 可选材料，例如模型、图表、表格、研究、签名请愿等

​
社区支出提案

一个成功的社区支出提案示例是 Proposal #63。
  1. 申请方 - 发起提案的个人/实体简介。
    • 你是谁，以及你在 Cosmos 和/或其他区块链网络中的参与情况。
    • 参与成员概览，以及他们的相关经验。
  2. 问题 - 你要解决什么问题和/或抓住什么机会。
    • 过去、现在（以及在这项工作不开展的情况下，对未来可能的预测）。
  3. 解决方案 - 你计划如何交付这个解决方案。
    • 你打算如何解决问题或创造价值。
    • 该计划的受益者（即你的计划会影响谁，以及如何影响？）。
    • 你选择这一方案的理由。
    • 你推动这一解决方案/价值交付的动机。
  4. 资金 - 提议的金额和币种，例如 5000 ATOM。
    • 控制接收资金账户的实体。
    • 可考虑按主要交付项列出逐项预算明细。
    • 请注意，支出提案中的“预算”通常是最容易被质疑的部分。如果你的预算较为模糊，请考虑说明为什么无法提供详细拆分，并清楚说明如果未用完预算会如何处理。
  5. 交付物和时间线 - 你将交付什么、如何交付，以及外界应有何预期。
    • 具体交付物是什么？（请详细说明）。
    • 每项交付物将在何时交付？
    • 每项交付物将如何交付？
    • 如果你未能按时交付，会发生什么？
    • 如果预算未用完或项目失败，你是否有退回资金的计划？
    • 你将如何对 Cosmos Hub 利益相关方负责？
      • 你将如何沟通进展，以及沟通频率如何？
      • 社区如何观察你的进展？
      • 社区如何提供反馈？
    • 应如何评估交付物质量？例如使用哪些指标。
  6. 关系与披露。
    • 你是否已经获得或申请过资助或资金？是否是针对类似工作？例如来自 Interchain Foundation 的资助。
    • 你和/或你的组织将如何受益？
    • 你是否认为这项工作未来会持续进行，是否已有相应计划？
    • 这项工作涉及哪些风险？
    • 你是否有利益冲突需要声明？

​
从经过充分考虑的提案草案开始

理想情况下，提案应先以 Markdown 格式发布到论坛，以便进一步编辑并开放评论。变更日志是一个很好的工具，能让人们看到这个想法是如何随着时间推移以及响应反馈而逐步演化的。 这篇 Markdown 格式的帖子，最终可以成为提交到链上的提案说明文本。

​
通过提案草案与社区互动

  1. 在论坛中对应的分类下，将你的提案草案发布为一个主题。如果你不确定该发到哪里，可以使用 Hub 提案 这个兜底分类；不过实际上，各类提案都有各自对应的分类。
  2. 直接联系社区中的关键成员以获取反馈。这些人可以是重要贡献者、最可能受到提案影响的人，以及获得较高质押支持的实体（例如排名靠前的验证者、大额质押者）。
3. 在 Twitter 等其他平台上提醒整个社区关注这份提案草案，并标记诸如 Cosmos Hub 账号、Cosmos Governance 账号 以及其他聚焦治理的群体。

​
将你的提案提交到测试网

在进入主网之前，你可以先在 测试网 上测试你的提案。 这是一个很好的方式，可以确保你的提案呈现效果符合预期，并在进入主网前进一步完善它。

​
第 3 阶段：你的链上提案

在提案正式上链之前，投票社区中的大多数成员最好已经了解该提案，并对其进行了考虑。如果你采取较为保守的做法，那么在冒着押金损失风险之前，你应该对提案能够通过有较合理的把握。在每个互动阶段结束后，都要继续修订你的提案草案。 有关如何提交提案的更多信息，请参阅提交流程指南。

​
押金期

当前押金期持续 14 天。如果你在提交交易时附带了最低押金（250 ATOM），你的提案将立即进入投票期。如果你没有提交最低押金金额（当前为 250 ATOM），那么这可能会成为其他人通过为你的提案出资并承担风险来表达支持的机会。你可以公开请求他人出资，也可以直接联系利益相关方（尤其是那些对你的提案非常支持的利益相关方）。请记住，每一位出资者都在承担资金风险，你可以在这里进一步了解押金被销毁的条件。 在这个阶段，提案可能会开始获得更广泛的关注。有些区块浏览器会显示处于押金期的提案，而另一些则要等到提案进入投票期后才会显示。 Twitter 上聚集了相当大一部分区块链和加密货币社区成员。你的提案进入押金期后，是一个与所谓“加密 Twitter”中的 Cosmos 社区互动的好时机，可以提前为验证者投票做准备（例如标记 @cosmosvalidator），也可以提醒正在进行质押的 ATOM 持有者（例如标记 @cosmoshub、@CosmosGov）。

​
投票期

到了这个阶段，你需要跟踪哪些验证者已经投票，哪些还没有。你还需要再次直接联系主要质押持有者，也就是排名最高的验证者运营者，以确保：
  1. 他们已经知晓你的提案；
  2. 他们可以就你的提案向你提出任何问题；
  3. 他们已经准备好投票。
请记住，在投票期结束前，任何投票者都可以随时更改自己的投票。历史上这种情况并不常见，但你仍然可能有机会说服某位投票者改变其投票。最大的风险在于利益相关方根本不投票（原因可能有很多）。验证者运营者通常需要多次提醒才会投票。你选择如何联系验证者运营者、联系频率以及沟通内容，都由你自己决定——请记住，没有任何验证者有义务投票，而且运营者往往还在处理其他同样需要他们关注的事务。注意不要给与验证者运营者的潜在关系带来压力。
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 several types of proposals supported by the Cosmos 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.

​
Engage directly with the voting community and seek feedback

Engagement is likely to be critical to the success of a proposal. The degree to which you engage with the Cosmos Hub 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: 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 Cosmos Hub, 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’s 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 the Cosmos Hub, 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 to the Cosmos Hub, 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.

​
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 Cosmos 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 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.

​
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 ATOM 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 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.

​
Parameter-Change

An example of a successful parameter change proposal is Proposal #66. Note that this proposal went on-chain without the recommended IPFS pin.
  1. Problem/Value - The problem or value that’s motivating the parameter change(s).
  2. Solution - How changing the parameter(s) will address the problem or improve the network.
  3. 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
  4. Supplementary materials - Optional materials eg. models, graphs, tables, research, signed petition, etc

​
Community-Spend Proposal

An example of a successful community spend proposal is Proposal #63.
  1. Applicant(s) - The profile of the person(s)/entity making the proposal.
    • Who you are and your involvement in Cosmos and/or other blockchain networks.
    • An overview of team members involved and their relevant experience.
  2. 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).
  3. 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.
  4. Funding - amount and denomination proposed eg. 5000 ATOM.
    • 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.
  5. 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 Cosmos 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.
  6. 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

  1. 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.
  2. 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).
3. 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.

​
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 (250 ATOM), your proposal will immediately enter the voting period. If you didn’t submit the minimum deposit amount (currently 250 ATOM), then this may be an opportunity for others to show their support by contributing (and risking) their ATOMs 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. A large cross-section of the blockchain/cryptocurrency community exists on Twitter. Having your proposal in the deposit period is a good time to engage the so-called ‘crypto Twitter’ Cosmos community to prepare validators to vote (eg. tag @cosmosvalidator) and ATOM-holders that are staking (eg. tag @cosmoshub, @CosmosGov).

​
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:
  1. they are aware of your proposal;
  2. they can ask you any questions about your proposal; and
  3. 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.