What is OpenGov?

Published in

DARWINIA NETWORK

5 min readDec 20, 2023

OpenGov is a new approach to Polkadot community governance, bringing the next generation of decentralized, secure, and democratic governance to Polkadot. Darwinia is also considering adopting OpenGov to enhance community governance.

OpenGov is a more decentralized and equitable form of decision-making, providing users with the opportunity to directly participate in decentralized decision-making and voting processes. OpenGov will enable the Darwinia community to participate as conveniently as possible.

Current: Gov 1

Darwinia currently employs Gov 1, derived from Polkadot, as its governance system. Gov1 revolves around three distinct entities: the Council, the Technical Committee, and the broader RING token-holding community(public). The Council represents passive stakeholders on-chain. The Technical Committee serves as the final line of defense against software errors in the Polkadot network. While the Technical Committee cannot propose changes independently, it can expedite the processing of existing proposals in a shorter timeframe than usual. By meeting certain criteria, the first two entities have the privilege to do operations(dispatch calls).

The current system has been functioning effectively, facilitating Darwinia’s upgrades and issue resolutions. However, Gov1 has become intricate and centralization due to the introduction of the Council and the Technical Committee, both of which possess certain privileges. In response, Polkadot has introduced Gov2, also known as OpenGov.

Next: OpenGov

OpenGov transfers all responsibilities of the council to token holders through democratic voting and allows users to delegate their voting rights to community members in more ways.

Matching the importance level of proposals with the required timeline and level of participation is a core change in OpenGov.

Substrate-based blockchains use origins to represent privileges, and an origin can be roughly equated to a role in traditional systems. Different origins have different permissions. Some important operations need to be executed by origins with higher privileges, while less important operations can be executed by origins with lower privileges. The definition of origins in Gov1 is relatively simple. Additionally, when a collective (like a council) agrees on something, they gain a higher level of origin to execute that operation.

In OpenGov, any token holder can submit a proposal, and different origins will be defined based on the importance of the proposal. OpenGov will define different origins for different tasks (executing or calling a certain call on chain), with each task including the threshold and voting rate required for a proposal to pass. For example, a runtime upgrade (requiring a set_code call, if approved) does not have the same implications for the ecosystem as the approval of a system remark (System.remark_with_event call), and therefore different origins for these two actions are needed in which different deposits, support, approval, and a minimum enactment periods will be predetermined on the pallet.

Referenda

OpenGov also defines different referendum tracks determined by origin, which are completely independent of each other.

In the current governance structure, only one referendum can be conducted at a time (except for emergency referendums). In OpenGov, multiple referendums can take place simultaneously (on different tracks). In OpenGov, anyone can initiate a referendum at any time, and there is no longer a launch period in which a proposal must gain support before entering the public voting stage when submitting a proposal.

Before OpenGov, every referendum proposed was executed by a Root Origin. In OpenGov, proposers choose which origin they wish to use to execute their proposal. Each origin is associated with a type of referendum.

Lifecycle of a Referendum

Lead-in Period

When the referendum is initially created, the proposal enters the Lead-in Period. You can vote at this time.

Decision Period

When certain conditions are met, the referendum enters the Decision Period. Votes must meet **Approval** and Support criteria for at least the confirmation period; otherwise, the proposal will be automatically rejected.

Approval refers to the ratio of “approval weight/total vote weight”, which measures the proportion of approval among the voted weights. Support refers to the ratio of “number of votes in aye and abstain/total number of votes the system can accommodate”, which measures the turnout rate.

Enactment Period

Approved proposals will enter an enactment period, after which the proposed changes will be executed.

Differences

Cancelling a Referendum

In the current governance system, a proposal can be cancelled if the Technical Committee unanimously agrees to do so. Additionally, a two-thirds majority vote in the council can cancel a referendum. This might be used as a last guard if a problem is found too late in a referendum proposal, such as an error in the Runtime code that the proposal would enact.

In OpenGov, the act of cancelling a referendum is also a governance operation, and they have their own origin. This ‘cancel origin’ operates on a faster track. The cancellation track leads to the rejection of the proposal and decides whether the deposit is refunded or burnt.

Council

One of the significant changes brought by OpenGov is that it will dissolve the council.

In OpenGov, voters can choose to delegate their voting rights to another voter in the system, and they can designate different representatives for each type of referendum. Thus, a voter can have multiple individuals representing their vote. For example, a voter can delegate a more authoritative person to vote on proposals managing the Root Origin, while delegating another person to handle proposals from origins of lower importance. (This delegation pertains only to voting rights; the Tokens remain under the user’s control).

Whitelist

Another significant change brought by OpenGov is the whitelist.

A whitelisted proposal will be enacted through the Whitelist Caller origin. Those proposals will have a shorter Lead-in, Confirmation, and Enactment period when compared to the Root Origin track.

Summary

The above is a broad outline of OpenGov and the changes it may bring to the governance of the Darwinia community. For more detailed information, please refer to Polkadot’s documentation 1 and 2.

About Darwinia Network

Darwinia is the community-run technology and service powering the cross-chain capabilities of decentralized applications.