Polkadot’s governance mechanism allows the protocol to evolve over time while staying in line with its stakeholders’ expectations. The primary goal of this governance mechanism is to ensure that most of the stakeholders command the network.
Polkadot uses an array of novel mechanisms, such as an amorphous form of state transition function stored on-chain and defined in a platform-agnostic language, along with on-chain voting mechanisms. All changes made to the protocol must be voted on and agreed upon by stake-weighted referenda.
Understanding Polkadot OpenGov
Polkadot’s initial governance mechanism (Governance V1) consisted of three primary components: The Technical Committee, The Council, and the public. This governance mechanism ensured the appropriate use of treasury funds to ensure timely upgrades and fixes. However, in Governance V1, all referenda carried the same weight because only one referendum could be voted upon at any given time, with the voting process dragging on for several weeks. Additionally, an alternating voting timetable allowed voting on either a public referendum or a council motion every 28 days. This led to the consideration of only a few proposals instead of the broad consideration of many.
Polkadot OpenGov addresses this by changing how day-to-day decisions are made. By making the repercussions of any referendum better scoped and agile, Polkadot OpenGov increases the number of collective decisions taken by the system at any given time. Polkadot OpenGov further decentralizes Polkadot by proposing the following changes.
-
Migrating the responsibilities of the Council to the public through a direct democracy voting system.
-
Dissolving the current Council collective.
-
Giving users more ways to delegate voting power to community members.
-
Establishing the Polkadot Technical Fellowship and dissolving the Technical Committee.
How Does Polkadot OpenGov Work?
The public initiates all proposals on Polkadot OpenGov. After it is proposed, the proposal enters a Lead-in period, following which it follows a specific Track. The Track has a dedicated Origin. There are 15 Origins in total, each with a different track. The parameters for Origins and Tracks are preset values that set the duration of the referendum and how many can be simultaneously voted upon.
This means a treasury proposal can now be submitted in different tracks depending on the amount requested. A proposal for a small tip can be submitted to the Small Tipper track, while a proposal for substantial funds can be submitted to the Medium or Big Spender Track. The Technical Fellowship can also whitelist proposals enacted through the Whitelist Caller origin. Such proposals will have a shorter Lead-in, Confirmation, and Enactment period compared to the Root Origin track.
Each Track also has its own preset Approval and Support curves, based on the origin’s privileges. When the approval and support criteria for a specific period are satisfied, the referendum is passed and will be executed once the enactment period is over. Additionally, all referenda within and across tracks can be voted upon simultaneously.
Polkadot OpenGov also comes with multi-role delegations. These allow token holders to assign voting power on different tracks to entities that are experts in judging referenda submitted on specific tracks. For example, suppose a token holder lacks the technical background to consider the merits and vote on the referenda submitted to the Root track. In that case, they can delegate their voting power to a trusted expert who can act in the network’s best interest. This allows token holders to make their vote count even if they are not up-to-date with governance matters.
Disclaimer: This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.
