This article is the first in a series designed to educate the community about the intricacies of open governance (Gov 2.0) within Polkadot and Kusama.
With Open Governance already making waves on Kusama and gearing up for a launch on Polkadot, it’s important for the wider community to understand their roles in Open governance as well as what the processes look like. Educating the community about Open governance will encourage more token holder participation, hence helping keep the process as decentralized and inclusive as possible.
In this part of the series, we’ll talk about the essentials of OpenGov, how it differs from Gov 1.0, navigating open governance, and more. Let’s delve into it.
Polkadot OpenGov – The What and the Why
Polkadot’s legacy governance model (Gov 1.0) already made Polkadot the chain with the most flexible and decentralized governance structure. However, the evolution continued. To put more decision-making control directly in the hands of the token holders, OpenGov was created.
The key tenet of Polkadot’s OpenGov is direct community participation.
Unlike in governance 1.0 where a significant portion of on-chain decisions was left in the hands of council members, OpenGov gives token holders the chance to participate directly in all the on-chain decision-making processes while still giving them the option to delegate their voting power to experts if they so wish.
Some OpenGov terms to be familiar with
Here are some OpenGov terms with which you should familiarize yourself.
Conviction: This is a multiplier that allows a voter to increase the voting weight of his DOT or KSM tokens at the expense of locking his tokens for a longer period of time. For instance, using a conviction of x3 with a token amount of 100 DOT amplifies your voting power to 300 DOT. In this case, 100 DOT is the real voting weight and 300 DOT is the conviction-adjusted voting weight. The real voting weight is used in calculating support while the conviction-adjusted voting weight is used in calculating approval.
Support: This is the percentage of the circulating supply that voted in favor of or abstained in a referendum. As explained earlier, when calculating support, all convictions are removed and only the real KSM and DOT value is used.
Approval: This is the conviction-adjusted percentage of the total number of AYE/NAY votes that voted “AYE”
Origins/tracks:
- In the context of Governance 2.0, Origins are the sources of on-chain referendum transactions. Origins have variable levels of privileges and restrictions depending on what needs to be accomplished and the impact that the change will have on the network. For example, the
treasuryorigin on Polkadot can spend up to 10 Million DOT from the treasury, while theSmallSpenderorigin can spend up to 10,000 DOT from the treasury at once.
- Tracks are pathways that a proposal can follow as it navigates the governance process. Each track has its own configuration parameters including the origin for its referendum call, decision deposit, decision period, confirmation period, minimum enactment period, etc.
Enactment period: The enactment period is the period between the passing of the proposal and its execution on-chain.
Other OpenGov terms are discussed in the relevant sections below.
Ensuring Sanity in OpenGov
Putting the entire decision-making process in the hands of the community could seem detrimental at first. One might wonder how the system prevents malicious actors from attempting to hijack significant funds from the treasury.
Fortunately, OpenGov incorporates some measures to significantly reduce the risks of such hijacks happening. Some of these measures include:
Using support thresholds as an additional mandatory requirement for a proposal to pass.
Conventionally, the number of votes in favor of a proposal is used to determine whether it is passing or not. But Governance 2.0 takes this a step further to include support thresholds as a requirement.
As defined earlier, the support for a referendum is the percentage of tokens in circulation that are either in favor of or abstaining from a referendum.
Using a support threshold makes it harder for malicious actors to have an early approval/execution of proposals with a low voter turnout, even if they’re passing in terms of approval.
Placing more limitations on more critical Origins/tracks.
Tracks whose execution would have more impact on the chain have a higher barrier of entry, especially in terms of launching a referendum, the number of referenda that can exist at a time, and meeting the support and approval thresholds.
For example, to launch a referendum using the root origin which represents the highest level of authority (it can do basically anything on the chain), you’ll need a decision deposit of 3,333 KSM and only 1 referendum from the root origin can exist at a time.
New referenda for the root origin are queued and can only kick off after the last referendum has ended. Also, the rate of decrease of the thresholds for support and approval is slower than the other origins.
Notice this slow rate of the threshold curve for Root origin. This slow rate gives the community enough time to act in case a malicious whale attempts to misuse this origin.
In contrast origins/tracks with lesser impact like the smallspender Origin, where a referendum is only able to spend at most 333.3 KSM from the treasury, are able to afford a lesser barrier of entry (ie, a smaller decision deposit) and steeper support and approval curves
Using mandatory delays
Governance 2.0 uses multiple mandatory delays to ensure that the wider community is given enough time to vote on the outcome of a referendum. These delays include:
A lead-in (prepare) period
This is the period between submitting the referendum and the beginning of the decision period. During this period, the community can still vote. However, the vote cannot pass at this stage, regardless of the number of votes in support of the referendum.
This gives the community a couple of hours to be aware of a new referendum and reduces the chances of a whale attempting to make the referendum pass as soon as it goes on-chain.
One could argue that the lead-in period isn’t necessary since it’s highly unlikely that a whale is able to hit the support threshold required at the beginning of a referendum. But more failsafe measures never hurt. Another sanity measure is that the decision deposit for a referendum must be made before a proposal proceeds from the prepare period to the next stage. If this deposit is not made early enough, the referendum will time out and be removed and other referenda on the queue can start preparing.
The timeout period prevents bloating the tracks with referenda that remain in the prepare period for too long
A threshold-dependent decision period
The decision period is the period where the real voting begins. In this stage, hitting support and approval thresholds can move the referendum to the next stage. This decision period can be up to 14 days depending on the weight of the origin/tracks.
The decision period is threshold-dependent because support and approval threshold requirements decline as we move toward the end of the decision period. This ensures that only referenda with significantly high approvals and support can move on to the next stage earlier.
Proposals with low turn-outs remain in the decision period for a longer time.
A confirmation period
This confirmation period begins immediately after the decision period ends, or once a referendum has met the requirements for both support and approval. This delay is important for two reasons:
- It provides more time for the community to act in case a referendum met both support and approval thresholds right from the prepare period.
- It serves as a pivot to prevent any last-minute hijacks. For example, if a proposal that was passing suddenly started failing during the confirmation period, the referendum goes back to the decision period to give the community more time to assess the change and act accordingly.
An enactment period
The enactment period is the period between the passing of the proposal and its execution on-chain. This period is more important in referenda that involves changes to on-chain logic. the referendum proposers have the option to set the period for this enactment.
However, each origin/track has a minimum enactment period. Setting an enactment period that’s less than the minimum enactment period will default the value to the minimum.
OpenGov is great, but needs community efforts to achieve its goals
Although OpenGov has a lot of advantages when it comes to flexibility and decentralisation, it does present some challenges which will require community efforts to overcome.
Community participation (voter apathy)
For Open Governance to actually be more decentralized than Governance 1.0, It will require a significant level of token-holder participation. Low community participation would mean that the results of referenda may not necessarily be a true representation of the decision of the larger token-holder community.
For Open Governance to fulfil the aim of more decentralization, it would require more token holders to come out and participate (or at least delegate their votes to notable community members) to avoid the scenario of a small group of highly-active participants dominating the process.
Quality of judgment
One advantage of the council model was that council members are well-knowledgeable and notable members of the Polkadot community. Their experience makes it easy for them to provide a decent level of judgement on Proposals.
The larger token holder community may not have the expertise to assess proposals and make firm decisions. One solution to this is to introduce reviewers who are able to assess the quality of proposal ideas and present these to the token holders, who can then use these to make informed decisions.
Time commitments to assess proposals
Another advantage of the council model was that token holders didn’t have to spend much time doing deep assessments of proposals. But with OpenGov where token holders have to vote directly, they’ll need to spend the time to critically assess proposals.
Complexity
Participation in OpenGov presents a steeper learning curve compared to Governance 1.0. It could take some time to understand the various parameters, origins, and tracks. However, with regular participation in OpenGov activities, these concepts should become more familiar over time.
Potential for centralization:
Although OpenGov aims to be a decentralized governance model, there is still the risk of centralization, particularly if a small number of influential participants gain disproportionate control over the system.
Your first step
- Join the Polkadot and Kusama governance discussion channels to ensure that you’re up-to-date with relevant information relating to on-chain governance:
- Monitor discussion posts on platforms like Polkassembly or Subsquare to familiarize yourself with upcoming referenda.
- Cast your first vote on an existing referendum.
If you are new to the Polkadot ecosystem, the following guides may assist you in getting started:
Test your knowledge of Open Governance essentials
Conclusion
This part of the series explored the essentials of Open Governance on Polkadot, including information you need to know to start participating actively. In the subsequent part of the series, we will delve into the lifecycle of a referendum in Open Governance.
Please look forward to it!