In the second part of the Polkadot OpenGov distilled series, we will explore the lifecycle of an OpenGov proposal, from the pre-proposal phase to the post-enactment phase.
If you haven’t yet, we recommend checking out the first part of the series, where we discussed the essentials of OpenGov on Polkadot and Kusama. The primary aim of this part of the series is to help the community understand their role during the various phases of a proposal’s cycle.
Pre-proposal phase
This is the initial phase in the lifecycle of a Polkadot OpenGov proposal. Though this phase is optional, we highly recommend it as it helps shape the quality of a proposal, allowing it time to mature and accommodating community feedback. These help improve the chances of a successful execution of the proposal.
This phase generally involves crafting a quality proposal, initiating discussions, and ensuring appropriate publicity.
Writing a quality proposal for Polkadot OpenGov
Crafting a quality Polkadot OpenGov proposal is a key, but often overlooked, component of this phase. A quality proposal is one that is grounded in thorough background research, aligns with the community’s needs, and is specific enough for the community to understand exactly what will be delivered.
When formulating your proposal, it’s critical to have a clear vision of your goal and how it aligns with the Polkadot ecosystem’s values and objectives. The proposal should be detailed, accurate, and concise. Outlining the expected benefits, resources needed, and any potential risks or challenges can greatly improve its reception by the community.
One way to ensure that your proposal is in line with the community is to request feedback on the Polkadot forum even before formulating the proposal . That way, community members are able to brainstorm with proponents and help refine ideas.
A robust proposal requires multiple components to guide its direction. Fortunately, there are templates available, such as the proposal template compiled by Coinstudio, which can ensure that you don’t miss essential elements.
Bear in mind that the structure of a proposal largely depends on its aim. For instance, a proposal to upgrade Polkadot’s runtime would primarily comprise technical changes and their effects on the functionalities of the relay chain and parachains.
Engaging in discussions
Once your proposal is written, the next recommended step is to initiate discussions. This is usually done on forums such as Polkassembly, Subsquare, or the Polkadot forum. In this phase, garnering feedback and insights from the community is crucial.
During this period, the community reviews the final draft of your proposal and provides feedback. This period should last long enough to allow the wider community to digest the proposal and provide feedback.
Decentralized auditors can also review the proposal and present their reports during this time.
Though this phase is not mandatory, we recommend that proposal creators leverage this opportunity to understand community sentiment, address concerns, and refine the proposal.”
Publicity of your Polkadot OpenGov proposal
Publicizing your proposal goes hand-in-hand with the discussion phase and involves strategies to enhance the visibility of your proposal and reach as many community members as possible. This could include:
- Announcing it on Polkadot or Kusama’s element channel.
- Attending the Kusamarian’s weekly AAG to discuss your proposal.
- Writing blog posts about your proposal.
- Creating threads about your proposal.
The goal is to ensure maximum awareness and understanding among the community before the proposal moves to the referendum stage to encourage token holder participation.
Referendum phase
At this phase, the proposal is officially submitted on-chain and must navigate several steps to ensure a fail-proof process.
Pre-decision phase
During this period, the proponent submits the proposal and includes a decision deposit.
Submitting the referendum requires two steps:
- Creating a preimage: This term essentially refers to a container for the call(s) that will be made for that particular referendum. This preimage is hashed and stored on-chain. The hash is an identifier for individual
preimageand is required for the next stage of the submission process. - Submitting the referendum: This process requires the preimage hash for the proposal. This allows the community to ensure that a referendum is in keeping with the proposal by viewing the details of the hashed preimage used for the referendum using UIs like Polkassembly or Subsquare.
Once the referendum is submitted, it either starts preparing for decision-making from the community or joins the referenda queue if the space for active referenda on that track is filled up.
But for the referendum to get to the decision phase, a decision deposit needs to be included. Check out the previous part of this series to learn what a decision deposit is and why it’s needed.
Decision phase
During the decision phase, the community can vote on the proposal with their tokens, with or without conviction.
This phase will persist until the referendum starts passing in terms of support and approval, or until the end of the decision phase, whichever comes first.
Post-decision phase
After the decision phase, a couple of events need to take place before the life cycle of the proposal ends. These events include:
Referenda confirmation
After the decision phase elapses or once the referendum starts passing in terms of both support and approval, the confirmation period begins.
This period allows the community to make any final decisions. If the status of a referenda changes during this period, the referenda reverts to the decision phase to give the community enough time to react accordingly to any “last-minute snipe” attempts.
Referenda execution and enactment
If a proposal passes, the next step is for the preimage to be executed onchain. These changes will take place after a certain period of time.
The period between the confirmation of a referenda and its execution is called the enactment period. It’s after this period that the calls included in the referenda’s preimage will actually make the intended on-chain changes based on the logic of the call(s) in question.
Post-enactment
What happens after the enactment depends on the calls included in the preimage of the referendum.
For instance, if the referendum contains a call to spend a certain amount from the treasury (ie., treasury.Spend), enactment of the referenda would add the recipient’s address and amount requested to the spending queue, and the funds would be released after the current spending period at the time the referenda was executed (enacted).
Thus, it is up to the proponents to ensure that the calls included in their referenda’s preimage are the right ones required for the intended on-chain changes.
Delivery phase
For non-treasury proposals, this phase mainly involves monitoring the impact of the implemented proposal on the ecosystem and making necessary adjustments.
If the proposal involves the use of treasury funds, proponents would ideally have to report back to the community regarding the proposal’s expenditures and outcomes to show the community that the funds are being used effectively and as intended.
Addressing failed referenda
If a proposal does not pass, it’s important to understand the reasons behind its rejection. This could involve seeking feedback from the community or analyzing voting patterns. By conducting post-referendum assessments after a failed decision, proposal creators can learn valuable lessons from unsuccessful proposals.
Regardless of the outcome, the primary objective is always to deliver services that benefit the Polkadot ecosystem. The success or failure of a proposal can offer valuable insights into the community’s priorities and values, helping to guide the development of future proposals.
Conclusion
In this part of the series, we have walked through the life cycle of a Polkadot OpenGov referendum. OpenGov is driven by the collective decision-making efforts of its community members, providing an opportunity for every stakeholder to participate in its evolution. Each phase in the proposal and referendum processes allows for checks and balances, encourages open dialogue, and ensures that every token holder’s voice is heard.
The Polkadot network’s prosperity depends on the active participation and informed decision-making of its token holders. Thus, each proposal and referendum is more than a mere decision point—it’s a reflection of the network’s collective vision for the future of the Polkadot ecosystem.
Whether it’s drafting a proposal, engaging in discussions, voting in a referendum, or implementing the changes outlined in a successful proposal, each step in the process is crucial for the ongoing development and improvement of the Polkadot network. Just like in the world of business, the process doesn’t end with the enactment of a proposal; ongoing monitoring, feedback, and adjustments are essential to ensuring that the implemented changes deliver their intended benefits.
The Polkadot proposal and referendum process exemplifies the power of decentralization and the crucial role community participation plays in shaping the network’s future. By adhering to these processes, Polkadot assures its continued development as an open, adaptive, and community-led platform in this rapidly evolving space.