Introduction
Polkadot has made a name for itself thanks to its sophisticated shared security and app-chain infrastructure, and lately with the implementation of OpenGov in mid-2023 also a pioneer in the realm of decentralised governance.
Building on the basic understanding provided in the introductory article, “An Introduction to Polkadot”, this article goes deeper into the OpenGov system and aims to outline OpenGov’s key features, operational mechanics, and the implications it holds for the broader Polkadot network. Readers seeking a basic overview of Polkadot’s architecture and its initial governance mechanisms are encouraged to read the previous introduction article before diving into this one.
Understanding the Evolution of Polkadot Governance
The development of Polkadot’s governance system can be said to mirror much of the evolving landscape across decentralised blockchain networks, though arguably at its frontier; gradually moving from early (some would argue necessary) relative centralisation to more modular and decentralised forms of rule.
Polkadot’s original governance structure, Governance V1, was designed to establish a stable and secure foundation for the network’s early growth: centred around two main bodies, the Polkadot Council and the Technical Committee. The Council, an elected group representing the community, served to manage proposals and safeguard the integrity of the network. The Technical Committee, comprised of active development teams, focused on technical decisions to ensure prompt and efficient handling of key network development.
While Governance V1 served its purpose during the early stages of Polkadot’s growth, its structure had inherent limitations that too often led to slower than necessary implementations of updates and proposals. The somewhat drawn-out decision-making process was in great part due to the system’s inability to handle multiple public referenda simultaneously: a limitation that became increasingly apparent as the network expanded and the community’s needs grew more complex and diverse — culminating in the introduction of the OpenGov system (sometimes also referred to as Gov2 or Governance V2).
Through several key features which are listed in the section below, OpenGov has been designed to facilitate multiple simultaneous decision-making processes to enhance the network’s agility and responsiveness to diverse proposals. For starters, the traditional roles of the Council and the Technical Committee have been redefined; whereby the Council has been dissolved, transitioning its responsibilities to the broader community to enable a more direct form of democratic engagement. The Technical Committee has also evolved into a new Technical Fellowship, a group of technically adept community members serving an advisory rather than an authoritative role, offering guidance on technical matters without direct decision-making power.
Altogether, Polkadot’s transition from a representative model to a more direct democratic system marks a significant practical shift in its governance, though still widely in line with its core vision and philosophy of decentralisation and community participation. By placing decision-making power in the hands of DOT holders, Polkadot has taken a substantial step towards realising a truly decentralised governance model that aims to balance agility, inclusivity and capability; one that can efficiently handle a wide range of proposals and adapt to the evolving needs of the Polkadot community and the broader ecosystem.
The subsequent sections will delve into the specifics of the OpenGov system, exploring the practical workings of OpenGov and its implications for the future of governance in decentralised networks.
Key Features of OpenGov
The OpenGov system is characterised by several key features that collectively enhance the network’s democratic and decentralised nature. This section describes these features to offer insights into how they collectively facilitate a more inclusive and efficient governance process.
Direct Democratic Token-Holder Voting
At the heart of OpenGov lies the principle of direct democracy, where DOT holders have the power to shape the network’s future. Moving away from elected representatives, OpenGov has taken steps to further cement governance power in the hands of the Polkadot community by encouraging DOT holders to participate directly and drive the decision-making process of the network: ensuring that decisions reflect the collective will of token holders through a sense of ownership and engagement.
The Technical Fellowship
The Fellowship, which as mentioned evolved from the former Technical Committee, plays a crucial advisory role in the OpenGov system. Comprising technically proficient community members, the Fellowship’s primary function is to provide expert guidance on the technical aspects of proposals.
It’s designed to be a broad, inclusive body, potentially accommodating up to as many as thousands of members with varying degrees of technical expertise. Members are ranked to reflect their expected level of informed opinion, technical acumen, and alignment with the interests of the Polkadot and/or Kusama networks.
While it does not have hard decision-making authority, its input is vital for maintaining the network’s technical integrity and guiding token holders in making informed decisions. The Fellowship operates through a voting mechanism where members’ votes are weighted according to their rank to promote a collective opinion that reflects a balanced representation of its members’ expertise. The Fellowship’s governance, including membership management and proposal whitelisting, takes place on the Collectives parachain.
Some of the core responsibilities and mechanisms of the Fellowship include:
Whitelisting, which allows the Fellowship to authorise certain operations to be executed with Root-level privileges (i.e. the highest privilege), provided they have been previously approved through Fellowship consensus. The Whitelisting mechanism is crucial for managing and fast-tracking proposals that are deemed safe and time-critical by the Fellowship, especially those requiring immediate attention due to their technical nature or urgency.
Requests for Comment (RFCs) and Technical Oversight, which involves reviewing detailed proposals for changes to the technical implementation of the Polkadot network. RFCs cover a wide range of topics, including but not limited to:
- Internal functionalities of Polkadot node implementations.
- Cryptographic structures and algorithms essential for the network’s upkeep.
- Consensus mechanisms specific to Polkadot, including those for the relay chain and parachains.
- Cross-chain message passing protocols.
- Development and maintenance of the Polkadot networking protocol and synchronisation strategies.
- Governance and operation of the Polkadot runtime and associated pallets.
- The XCM specification and its implementation.
The Fellowship’s role in assessing and signalling approval or disapproval for these RFCs is fundamental, where their expertise plays a key role in ensuring that proposed changes or upgrades are technically sound, align with Polkadot’s core objectives, and maintain the network’s integrity and security.
Categorisation of Proposals
New for OpenGov is that proposals are managed through a system of ‘Origins’ and ‘Tracks’, seeking to streamline the governance process to enable a more organised and efficient review process, ensuring that critical updates receive timely attention while allowing for comprehensive deliberation on long-term changes.
The Role of Origins
An Origin denotes the level of privilege and type of referenda associated with a proposal, essentially representing the transaction source of a proposal which is key to understanding how different proposals are routed through the governance system. Each Origin has a specific Track associated with it, meaning that proposals coming from a specific Origin will follow a designated Track that’s accustomed to that particular proposal type.
Main Tracks in OpenGov
Tracks are channels through which proposals initiated by the abovementioned Origins proceed, with each Track designed to handle proposals of a certain type or level of impact. The idea behind it is to categorise proposals based on their nature and potential implications on the network, ensuring that each is processed in a manner that reflects its importance and required scrutiny. As such, different Tracks follow different parameters throughout the governance process, including when it comes to the number of referenda it can handle simultaneously, the time spent in each phase of the process (the Prepare, Decision, Confirmation, and Minimum Enactment periods; which are described in greater detail further below), as well as the required approval and support thresholds for passing proposals.
For example, a proposal from the Root Origin (involving critical system changes) follows a Track designed for high-impact decisions with higher thresholds and a longer decision-making process. Conversely, less critical Origins, such as smaller spending proposals which come with less notable impact, can have proposals that follow Tracks allowing for multiple referenda to run concurrently; designed to handle proposals that are considered safer in parallel. The Tracks system thus serves to accommodate different kinds of proposals with distinct requirements, allowing Polkadot to manage a diverse range of proposals simultaneously, from critical updates to long-term changes.
Some of the main Tracks include:
Root: The Root Track is reserved for proposals with the highest level of privilege, typically involving critical decisions that impact the core aspects of the network, requiring a higher threshold for approval due to their significance.
Whitelisted Caller: The Whitelisted Calle Track is unique in that it allows certain actions to be executed with escalated privileges, following approval from the Technical Fellowship.
Referendum Killer: The Referendum Killer provides a mechanism to challenge and potentially cancel ongoing referenda, serving as an important safeguard by allowing the community to intervene if new information arises or if a proposal is deemed no longer suitable or safe.
Big to Small Spenders: Simple yet innovative, the different Spender Tracks (Big Spender, Medium Spender, Small Spender) manage proposals related to financial expenditures, categorised by the amount of spending; facilitating financial decisions to be made appropriately and with due consideration to the size and impact of the expenditure.
Multirole Delegation
Building on the newly introduced Tracks, OpenGov further allows DOT holders to delegate their voting power based on the Track of a proposal. Although other networks such as the Cosmos Hub allow for token holders to delegate their stake across multiple delegates (validators), the OpenGov Origins introduce another level of flexibility and precision previously not seen. Instead of (rather unrealistically) relying on and expecting delegates to be able to cover all matters of governance with expertise and informed actions, OpenGov enables holders to entrust Track-specific votes to delegates who align with their values or possess distinct expertise — providing the tools for more specialised, higher quality decision-making. It also has the potential to include a wider array of voices in governance decisions, fostering a more representative and diverse governance environment.
Conviction Voting System
Lastly, a distinctive feature that remains from Polkadot’s V1 governance is its conviction voting system, which allows DOT holders to express the strength of their vote through a conviction multiplier. In practice, this means that votes can be locked for varying lengths of time, whereby the duration of the lock influences the vote’s weight through a defined multiplier scale: a single week lock equates to a 1x multiplier, escalating up to a 6x multiplier for a 32-week lock. As the name suggests, this system aligns voting power with the level of commitment to a decision, encouraging long-term thinking and stability in governance while rewarding voters for their long-term confidence in their decisions and enhancing their influence on governance outcomes.
These features collectively define the OpenGov system, showcasing Polkadot’s continued commitment to evolving its governance structure into a dynamic, inclusive, and effective model. The next sections will delve deeper into the operational mechanics of OpenGov, exploring how these features are implemented in practice and their implications for the Polkadot ecosystem.
Proposal Submission and Processing in OpenGov
In Polkadot OpenGov, the referenda are the central component on which all other parts rely. Each proposal must be accompanied by a decision deposit and after a lead-in period, the votes of the token holders start to be part of the support and approval thresholds of the referendum. To be approved, a referendum must satisfy the approval and support criteria for the confirmation period. Once approved, a short enactment period must pass before enacting the referendum content on-chain. Again, the various parameters and period lengths mentioned vary and are Origin-specific.
The key stages of this process are briefly outlined below:
Proposal Initiation and Submission
Every DOT holder has the privilege to initiate referenda, by which proposals are submitted following a structured procedure, aligning with specific Origins, and then categorised into Tracks based on their content and urgency.
Users can access all governance features, among other things like staking, via the Polkadot-JS UI.
Lead-in Period
Once a proposal has been submitted, it stays within a lead-in period where it remains until three criteria have been fulfilled:
- The pre-defined lead-in time has passed, which serves to protect against proposals being passed too quickly or snuck through by major token holders.
- The specified Origin must have room for the proposal to move along the right Track. Again, different Tracks allow for a different number of proposals at any one time.
- The decision deposit must have been submitted, which is a small-ish amount of DOT that a user must lock up for the duration of a proposal to prevent spam and ensure that only serious proposals are pushed on-chain for consideration by the network’s governance.
Decision Period
Once in the Decision Period, token holders can vote. Here, proposals must meet the approval and support thresholds for the duration of a confirmation period, or else they will be rejected. Approval is determined by the ratio of ‘aye’ votes, adjusted for conviction, to the total of ‘aye’ and ‘nay’ votes, also conviction-adjusted. Support, on the other hand, calculates the proportion of ‘aye’ plus ‘abstain’ votes against the total DOTs in circulation, excluding ‘nay’ votes to avoid skewing the referendum’s outcome.
For a referendum to be approved, approval and support must stay within a required threshold during the entire duration of the specified confirmation period. This means that if either falls below this threshold due to an increase in ‘no’ votes, the referendum exits the confirmation period, resets, and must then re-enter and remain for the entire duration without interruption to succeed.
Enactment Period
Approved proposals move onto the enactment period, which is essentially a waiting room for proposals before they get dispatched, after which proposed changes will be executed.
For more detailed information and specific parameters, please see the Polkadot Wiki on OpenGov.
Summary and Conclusion
In summary, OpenGov has introduced significant updates to Polkadot’s governance, aiming for greater inclusivity and flexibility. Embracing greater decentralisation and an organised proposal system are practical steps towards addressing the perceived rigidity and centralisation of the former Council and Technical Committee system; arguably setting the stage for more dynamic and effective governance. If anything, it serves as a reflection of Polkadot’s dedication to decentralisation and community involvement and stands as a sophisticated example of the possibilities blockchain technology has to offer for political and democratic innovation.
This will certainly be an exciting one to follow! Stay tuned for more articles on Polkadot.
DISCLAIMER: The information provided in our research and content is for informational purposes only and should not be considered as financial or investment advice. Any decision to invest or engage in financial activities is solely your responsibility. We do not endorse or recommend any specific investment strategy, and individuals should conduct their research and seek professional advice before making any investment decisions. We are not liable for any financial loss, damage, or inconvenience resulting from the use of our content for investment purposes. Always be aware of the risks associated with financial markets, and carefully consider your financial situation and risk tolerance before making any investment choices.
