Opengov

❓ Why OpenGov?

The evolution and its importance

As quoted on Polkadot Wiki,

Like most early technologies, the systems and protocols must evolve as they mature to improve upon their shortcomings and keep up with modern advancements.

Governance V1 has been one of the most sophisticated governance systems, but as with any novel innovation, its shortcomings needed to be improved upon.

📘 Terminology & Parameters

Your reference repository!

The important parameters to be aware of when voting using the Referenda module are as follows:

Origin - Each origin has a fixed set of privileges. When making a proposal, it is important to choose the origin that has the privilege to execute the referenda.

Track - Each track has its own dispatch origin and a preset configuration that governs the voting process and parameters.

Submission Deposit - The minimum amount to be used as a (refundable) deposit to submit a public referendum proposal.

Prepare Period - The minimum time the referendum needs to wait before it can progress to the next phase after submission. Voting is enabled, but the votes do not count toward the outcome of the referendum yet.

Decision Deposit - This deposit is required for a referendum to progress to the decision phase after the end of the prepare period.

Decision Period - Amount of time a decision may take to be approved to move to the confirming period. If the proposal is not approved by the end of the decision period, it gets rejected.

Max Deciding - The maximum number of referenda that can be in the decision period of a track all at once.

Conviction - A multiplier to increase voting power.

Approval - The share of the approval vote-weight after adjustments for conviction against the total number of vote-weight for both approval and rejection.

Support - The total number of votes in approval (ignoring adjustments for conviction) compared to the total possible amount of votes that could be made in the system. Support also takes into account abstained votes.

Min Approval - The threshold of approval (along with the min support) needed for a proposal to meet the requirements of the confirm period.

Min Support - The threshold of support (along with the min approval) needed for a proposal to meet the requirements of the confirm period.

Confirm Period - The total time the referenda meets both the min approval and support criteria during the decision period.

Min Enactment Period - Minimum time that an approved proposal must be in the dispatch queue after approval. The proposer has the option to set the enactment period to be of any value greater than the min enactment period.

Creating a Referendum

Who can start a Referendum?

• Anyone is able to start a referendum at any time and they can do so as many times as they wish.
• Origins and Tracks, have been introduced to help aid in the flow and processing of the referenda protocol.

Mechanism

When a referendum is initially created, it can be immediately voted on by the community. However, it is not in a state where it can end, or otherwise have its votes counted, be approved and summarily enacted. Instead, referenda must fulfil a number of criteria before they are moved into a state known as Deciding. Until they are in this state, they remain undecided.

The criteria for entering the Decided state is as follows:

1. A lead-in period that outlines the amount of time that must elapse before deciding can begin.
   This helps mitigate against the possibility of “decision snapping” where an attacker controlling a substantial amount of voting power might seek to have a proposal passed immediately after proposing, not allowing the overall voting population adequate time to consider and participate.

2. There must be room for the decision. All Tracks specify their own limit on the number of referenda which can be decided simultaneously. Tracks that have more potent abilities will have lower limits. For example, the Root level Origin has a limit of one, implying that only a single über-dangerous proposal may be decided on at once.

3. A Decision Deposit must be paid. Creating a referendum is cheap as the deposit value consists of only the value required for the on-chain storage needed to track it. But, having a referendum reviewed and decided upon carries the risk of using up the limited spots available in the referenda queue. It makes sense to have a larger, but refundable deposit requirement to help mitigate spam.

Creating a Referendum on Polkassembly

It is now easier than ever

It is now time to get away from all the complexity!
Please leverage this twitter thread or follow the steps below to create your first proposal on OpenGov for Polkadot & Kusama.

Leverage Polkassembly’s super intuitive & powerful interface to create proposals in three quick steps 🚀

Step 1 ➜

Hop on to http://polkadot.polkassembly.io or http://kusama.polkassembly.io.

Click on the Floating Action Button (FAB) & create your first discussion post.

Gathering feedback via a discussion before creating a proposal leads to higher chances of it passing!

Step 2 ➜

After initial feedback, proceed with linking your discussion post to the proposal you will be creating!
Nudges along the way ensure you follow the right steps!

Step 3 ➜

Add the address/es which should receive funds.
@polk_gov makes adding multiple beneficiaries super easy!
Your track selection will be done automatically based on the amount you enter.
Create the preimage & confirm if everything is right in the summary.

Step 4 ➜

Take your referendum live with a single click by creating the proposal!

Creating a Referendum on Polkadot-JS

How to start a Referendum? (using Polkadot-JS UI)

Submitting a Preimage

The act of making a proposal is split from submitting the preimage for the proposal since the storage cost of submitting a large preimage could be pretty expensive. Allowing for the preimage submission to come as a separate transaction means that another account could submit the preimage for you and pay the fee for it. The example below demonstrates the creation of a preimage on Kusama (the same procedure applies when OpenGov is live on Polkadot). To propose that a remark “Expect Chaos!” be added to the blockchain, the preimage hash would be:

After the preimage is submitted successfully on-chain, Polkadot-JS UI lists it under the tab of Governance > Preimages.

Submitting a Proposal

Submitting a proposal requires you to bond some tokens. On Polkadot-JS UI, you can navigate to the Governance > Referenda to make a new proposal. In order to submit a proposal, you will need to submit what’s called the preimage hash. The preimage hash is simply the hash of the proposal to be enacted. The easiest way to get the preimage hash is by clicking on the “Submit preimage” button as shown in the previous section.

The proposal will be registered from the account selected and the balance lock will be applied to it. An appropriate origin must be chosen, as each origin has different privileges, and acceptance criteria. After entering the hash of the preimage for the proposal, the preimage length field is automatically populated. The enactment delay can be specified either as a block number, or as a specific number of blocks after the referendum is approved. The deposit for this proposal will be locked for the referendum duration.

Origins & Tracks

What are Origins?

• An Origin can be thought of as a rich descriptor for a given privilege level. The proposer of the referenda now selects an appropriate Origin for their request based on the requirements of the proposal.

• Each Origin is associated with a single referendum class and each class is associated with a Track. The Track outlines the lifecycle for the proposal and is independent from other class’s tracks. Having independent tracks allows the network to tailor the dynamics of referenda based upon their implied privilege level.

Origins and Tracks Info

Kusama Tracks (15):

Voting on a Referendum

How does Voting work on Polkadot.JS?

To vote on a referendum, navigate to the “Referenda” tab of Polkadot-JS UI. All the active referenda will be shown in their respective track sections. Click the “Vote” button to cast a vote for the corresponding referendum. As OpenGov takes both the approval and support into account, there are four options to choose from when voting on a referendum:

• Aye
• Nay
• Split
• Abstain

Also, you have to specify the conviction multiplier for this vote. The longer you are willing to lock your tokens, the stronger your vote will be weighted. Unwillingness to lock your tokens means that your vote only counts for 10% of the tokens that you hold.

OPENGOV USES CONVICTION VOTING PALLET (NOT DEMOCRACY PALLET)

Use convictionVoting.vote for voting on Referenda in OpenGov instead of democracy.vote (which only works for old version of governance).

Removing expired voting locks

To remove the lock from votes you first need to call removeVote and then unlock through the convictionVoting pallet.

Learn about Voting

Voting Timetable

In Governance v1, every 28 days, a new referendum will be up for a vote, assuming there is at least one proposal in one of the queues. There is a queue for Council-approved proposals and a queue for publicly submitted proposals. The referendum to be voted upon alternates between the top proposal in the two queues.

The “top” proposal is determined by the amount of stake bonded behind it. If the current queue selection attempts to create a referendum with no proposals (it is empty) and proposals are waiting in the other queue, the top proposal in the other queue will become a referendum.

Multiple referenda cannot be voted upon in the same period, excluding emergency referenda. An emergency referendum occurring at the same time as a regular referendum (either public or council-proposed) is the only time that multiple referenda will be able to be voted on simultaneously.

OpenGov shares the same 28 day eligibility period when the proposal can get approved. If not approved by then end of this period, the proposal is automatically rejected.

Voting on a referendum (OpenGov)

In OpenGov, a proposal is approved if it meets the requirements for approval and support, removing the adaptive quorum biasing system.

Approval is defined as the share of approval vote-weight (after adjustment for conviction) against the total vote-weight (for both approval and rejection).

Support is the total number of votes in the approval (ignoring any adjustment for conviction) compared to the total possible votes that could be made in the system.

It must fulfill this criteria for the minimum of the Confirmation Period. Different tracks have different Confirmation Periods and requirements for approval and support. For additional details on the various origins and tracks. It is now possible to configure the amount of support and overall approval required for it to pass. With proposals that use less privileged origins, it is far more reasonable to drop the required turnout to a more realistic amount earlier than those which use highly privileged classes such as Root. Classes with more political significance can be made to require a higher approval early on, to avoid controversy.

In OpenGov, proposals that are not approved after 28 days are considered rejected by default and the Decision Deposit is refunded. If the proposal manages to stay passing until the end of the Confirmation Period, it is considered approved and is scheduled to execute from the proposed origin but after the Enactment Period. The Enactment Period is specified when the referendum is proposed but is also subject to a minimum value based on the Track. More powerful Tracks enforce a larger Enactment Period to ensure the network has ample time to prepare for any changes the proposal may bring.

Voluntary Locking

Polkadot utilizes a concept called Voluntary Locking which allows token holders to increase their voting power by declaring how long they are willing to lock up their tokens, hence, the number of votes for each token holder will be calculated using the following formula:

The conviction multiplier increases the vote multiplier by one every time the number of lock periods double.

The maximum number of “doublings” of the lock period is set to 6 (and thus 32 lock periods in total), and one lock period equals 28 days. Only doublings are allowed; you cannot lock for, say, 24 periods and increase your conviction by 5.5. For additional information regarding the timeline of governance events, check out the governance section on the Polkadot Parameters page.

While a token is locked, you can still use it for voting and staking; you are only prohibited from transferring these tokens to another account.

Votes are always “counted” at the same time, which is at the end of the voting period. This is not impacted by the locking period of the tokens.

Adaptive Quorum Biasing

Adaptive quorum biasing is no longer used in OpenGov and is replaced by the Approval/Support system.

Delegating Voting Power

Multirole Delegation

In OpenGov, an alternate strategy was required to replace the Council in its previous duties as a body delegated by voters to compensate for the fact that many choose to not take part in day-to-day governance. OpenGov builds on the Vote Delegation feature from v1 where a voter can choose to delegate their voting power to another voter in the system. It does so by improving a feature known as Multirole Delegation, where voters can specify a different delegate for every class of referendum in the system. Delegation can be done per track, and accounts can choose to select different delegates (or no delegation) for each track.

For example, a voter could delegate one entity for managing a less potent referenda class, choose a different delegate for a different class with more powerful consequences and still retain full voting power over any remaining classes.

Occasional delegation and undelegation calls are fee-free: creating an incentive for token holders to use this feature and ensure that wallets can do it “by default” without any cost to end-users. It is worth noting that a user delegating their voting power does not imply that the delegate will have control over the funds of the delegating account: they can vote with a user’s voting power: but they won’t be able to transfer your balance, nominate a different set of validators or execute any call other than voting on the defined call/s by the user.

With the new delegation features, the goal is to ensure the required turnouts for proposals to be enacted are reached while maintaining the anonymity of voters and keeping the overall design censorship-free.

Delegating Voting Power on Polkassembly

The most comprehensive delegation dashboard on Polkassembly

Process

It is super easy to delegate your voting power to a community member in OpenGov -

1. Hop on to Polkassembly’s delegation dashboard for your preferred network.
2. Either choose a delegate you want to delegate to or navigate to a specific track to see the top delegates.
3. Clicking on the “+ DELEGATE” Button allows you to delegate for whichever track you like to the respective delegate!

4. Update the following fields and you are all set! ➜

   • Balance ➜ The amount of token balance you would like to delegate to the address you have mentioned above
   • Conviction ➜ The period for which you would like to lock your votes up determines how much your token balance will be multiplied with, to give the final voting power

Delegating Voting Power on Polkadot.JS

For an overview on how delegation works in OpenGov, check out the Multirole Delegation section on the Learn OpenGov page.

The following steps outline how to delegate voting power in OpenGov through Polkadot-JS UI:

1. Navigate to the referenda tab
2. Click the Delegate icon in the top-right corner
3. Ensure the delegate from account field lists the account you wish to apply delegation over
4. Next, select the appropriate submission track that you wish to delegate (or select the option apply delegation to all tracks)
5. Specify the delegate vote value, which is the amount of DOT or KSM you wish to provide the delegate with
6. Provide a conviction multiplier determining how long the funds from the previous step are locked (for additional details see the section on Voluntary Locking) and click Next
7. The final step is to provide the account address that will be the delegate for the original account provided (this account will be receiving the voting power for the source account on the specified track)

When you are ready to undelegate:

1. Navigate to the extrinsics tab
2. Select a wallet address that is currently delegating to another account
3. From the submit the following extrinsic dropdown, select convictionVoting
4. Select undelegate from the next dropdown to the right of the previous step (note you can also delegate from this page as an alternative to the solution provided above)
5. Provide the submission track that was used when originally delegating from above
6. Sign and submit the transaction to restore the voting power back to the original source address

Comparing Gov1 and OpenGov Referendums

To read about how referenda worked in case of Gov1, please read this - [Referendum

Fellowship

Fellowship is a mostly self-governing expert body with a primary goal of representing the humans who embody and contain the technical knowledge base of the Polkadot network and protocol.

Members

This shows a bird’s eye view of all members of the fellowship with their current level. The community can view the voting details and social handles of a user by clicking on their respective card.

Member Referenda

This section aggregates the data for referenda created by different categories of fellowship members

• On clicking on a specific referendum, you can see details for it
  • This includes the track level card information
  • The details for the votes casted by the fellowship members
  • Details of the referendum