Polkadot has announced that it intends to introduce a new system of network governance. Dubbed Gov 2, it departs significantly from the previous system. As soon as the final expert evaluation is complete, the Kusama version of Gov2 will go live. After it has been tested on Kusama, a proposal will be put to the Polkadot network for a vote.
In order for the system to function properly, it has to be constructed with a certain amount of exclusivity built in. As a result of the high entry hurdles in the effective political organization, inclusiveness and diversity are harmed, and participation and legitimacy are weakened. As soon as Polkadot launched, it was clear that its governance was a work in progress that would evolve over time.
The initial decentralized governance structure included three chambers and a committee for managing the timeline for upgrading the platform. An elected executive “government” was also in existence to regulate the parameters, administration, and expenditure recommendations. Long-term stakeholders also had greater influence in general vote. However, there are significant drawbacks to this approach.
In most circumstances, the elected executive, or Council, is centralized and does not act anonymously. As a result of the shift in protocol, individual councilors may feel under pressure to take a certain course of action. As a result, the Technical Committee is subject to the same risks and is more carefully regulated. In a world where authority (both good and bad) are dispersed throughout society, decentralization is becoming increasingly vital for the safety and security of all people. The next generation of Polkadot ecosystem governance is now ready for proposal.
Polkadot’s Gov2 and how it works
New Polkadot governance system Gov2 is being developed to address the flaws in the current system. As a first step, it adheres to Polkadot’s founding principle that 50% of the total interest in the system should be held by its members. They have the power to shape the system’s future if they are steadfast enough in their beliefs.
There is no interruption from PolkaDot’s Conviction Voting, in which token holders who commit to the system for a longer period of time are given more importance. A technocratic collective is still necessary, even if its relevance, size, composition, and membership mechanics differ slightly from those of the current Technical Committee.
In many ways, Gov2 is easier than present governance. As far as government goes, there are no “first-class citizens” such as the Council or Technical Committee. There is no alternating proposal timeframe. Currently, there is no public proposal queue. As a result, network relies only on the referendum as the primary decision making method.
There are no limits on how many times an individual can initiate a referendum in Gov2 at any given time. Voting in these referenda is open to anyone. Also, I t’s possible to vote on as many referendums as you want, with no restrictions. That may not be a good thing, though, as it could reduce both accessibility and protection. As a result, the plan has brought certain innovative aspects into the referendum process in order to make this possible multitude of items to vote on doable for mere humans.
The Gov2 referendum process
All referenda are predicated on a proposal, which is actually simply another way of stating “an operation” in Polkadot. Making a transaction and adding it to a block results in the same description and execution. Stake and transfer are two common operations that most people are already aware of, but Polkadot can perform a plethora of other tasks as well.
One of the most important aspects of referendums and privilege levels is origin. In most cases, the logic of an operation will check to see if it’s passed in correctly. An ordinary transaction’s Origin parameter is set to Signed after it completes. In other words, the operation could not have taken place without the permission of a certain account within the system. There is a strong implication that only money in this particular bank account can be spent while it has this permission.
Gov2 has a wide variety of Origins, each with their own unique set of exotic benefits, but many of them are far less powerful and specialized than Root. The Root Origin is the most privileged of them all, as it is all-powerful. An earlier governance system’s proposed referenda were all sent out from this single source.
Decision making in the referendum process
Anybody in the community can vote on the first referendum as soon as it is created. As a result, it cannot be terminated, or have its votes counted in order to be authorized and swiftly enacted. Rather, before they may be transferred to the Deciding stage, referendums must first meet a set of requirements. They stay unsure until they reach this point.
Three conditions must be met in order to qualify: There is a lead-in phase for all referendums. Before making a decision, this length of time must have passed since the proposition was made. To prevent “decision sniping,” this allows for an initial amount of time in which votes can be cast. For example, an attacker in this scenario would try to have a proposal passed quickly after it is proposed, denying the general voting populace the opportunity to consider and vote.
Secondly, there needs to be room to make decisions. There is a limit on the amount of votes that can be cast on each track at once. The lower this limit gets as more powerful Origins are allowed on the track.
In order to complete the transaction, a Decision Deposit must be paid. Only the on-chain storage required to keep track of a referendum is required as a deposit. As a result, the network limits the number of referendums that can be decided simultaneously on each track, which increases the risk of a referendum. As a result, a bigger (albeit refundable) deposit is required to prevent spamming or system bloating.
Gov2 ranks and pitfalls
There are many dangers in introducing the concept of rank into an organization. However, if decentralization, accountability, and safety for everyone involved are what we’re looking for, we’re limited to a few possibilities. Not only are rank’s negatives bad for the network but they can have a negative impact on participants as well. If only a small group of people had effective influence over it and so were responsible for its actions, they could be deemed to be in effective control of the network.
The Fellowship must never have hard authority over the network; it cannot change parameters, conduct rescues, or relocate assets. This is the first of our three guiding principles. As far as network governance goes, the only thing that can be done is to shorten the effective voting period.
There’s also need to make sure that the ranks and weights are set up in a way that prevents a small group of people from capturing or controlling the overall decision-making capability. A third consideration is the Fellowship’s ability to build and improve the knowledge of its members. This ensures that the overall decision-making capability of the Fellowship increases.
A further safeguard against the Fellowship becoming a cabal is the requirement for complete (Polkadot) referendum for advancement to the Fellowship’s highest echelons, which cannot be granted just by one’s fellow Fellowship members. It’s possible to raise the privilege level of another Origin using the Whitelist palette. When it comes to Gov2, it gives the Fellowship the ability to authorize the execution of a new process at the Root level.