OpenGov

Overview

Why blockchain governance?
Why on-chain?
Goals of on-chain governance
Initial Solution, Governance V1
Improvement, OpenGov
How is it going? By the numbers.
OpenGov and you

Reasons for Blockchain Governance

Software as executive branch
- Applies existing laws (code) in pre-defined ways
- Protocol security ensures the letter of those laws is followed
But evolving protocols need a legislative branch
- To update the laws (code)
- To rectify cases where letter != spirit (bugs)
- To trigger parts of the system that aren't on a set schedule
- To spend treasury funds
Legeslative can be on or off chain

Why On-chain?

Off-chain governance
- Formal proposal by dev team
- Discussions, debates, and media campaigns
- Hard fork
Issues
- Centralization
- Low throughput
- Long decision period
- Little accessibility

Goals of On-chain Governance

Transparency: Decisions by who and by what rules?
Decentralization: Distributed power, weighted only by commitment and conviction
Security: Harmful proposals don't pass or have limited scope
Accessibility: Easy to draft proposal, to receive vote, to vote yourself, and to vote by proxy
Concurrency: Maximize simultaneous referenda as security allows
Speed: Each referendum completed as fast as security allows
Agility: Speed is responsive to support/controversy

Governance V1

Tri-cameral system: Referenda, council, and technical committee
Single track
1 referendum at a time
Root origin (Unlimited Power!)
28 day referendum
1 month minimum enactment period
Emergency handled technical committee
Cancellations by council and technical committee
Most proposals initiated by council
Fully council controlled roles such as tipping

Gov V1, Room for Improvement

The good:

Security
Transparency

The bad:

Decentralization
Concurrency
Speed
Agility

OpenGov Overview

Origins and tracks
Lifecycle of a referendum
Support and approval threshold curves
The Polkadot Fellowship
Vote delegation by track
OpenGov and governance goals

Origins

Level of privilege that code executes with
Similar to user on Unix
Proposal is two things
- Operation: What should happen
- Origin: Who authorizes it
Many operations require a specific origin

Origins and Tracks

Each origin is served by a referendum track
A track can serve more than one origin
These tracks are totally independent from one another
Track examples: Root, ParachainAdmin, BigSpender, Tipper
Emergency tracks: ReferendumCanceler, ReferendumKiller

Track Parameters

Parameters give us the ability to find an optimal balance between security and throughput.

The security needs of the Tipper track are very different than those of the Root track.

Lead-in period duration
Decision period duration
Confirmation period duration
Minimum enactment period
Concurrency, how many referenda can run in this track at a time
Support and Approval threshold curves

OpenGov Tracks

Criteria for Passing a Proposal

Approval: Approving votes/total votes cast, weighted by conviction
- Conviction: Locking tokens for longer periods scales their voting impact up to a maximum of 6x with a lockup duration of 896 days
Support: Approving votes/total possible vote pool, disregarding conviction

Decision and Confirmation Periods

If Approval and Support thresholds met, confirmation period begins
Approval and Support must remain above respective thresholds for entire confirmation period
Confirmation period concludes -> proposal approved early
Decision period expires -> proposal rejected
There is only one decision period, during which a proposal can potentially enter and leave many confirmation periods if thresholds aren't consistently met

Lifecycle of A Referendum

Support and Approval Threshold Curves

We want agility
- Well supported proposals pass quickly
- Controversial proposals get more deliberation
Addressed with time varying curves
- Support threshold
  - Starts at ~50%
  - Ends at minimum secure turnout for track
    (EX: Big Spender ends at 0 + epsilon %)
- Approval threshold
  - Starts at 100%
  - Ends at 50 + epsilon %
Monotonically decreasing at rates determined by track specific security needs

Example Support and Approval Curves

Vote Delegation

Traditional delegation: You entrust one third party with your vote on all matters
Delegation by track: You may delegate your vote to one or more third parties on a per track basis
EX: Tipper vote delegated to local ambassador, WhiteListedCaller vote delegated to Parity Technologies, vote retained for all other tracks
This is likely a first!

OpenGov Acting Under Pressure

Typical path to safety: Lower throughput and restricted origins

But in emergencies we may need to pass proposals that both require root origin and are time critical!

Solution: Some sort of oracle capable of providing expert information

Oraclization of Expert Information

Track everyone's level of expertise
Allow experts to register sentiment
Aggregate opinions by level of expertise

But how are these steps accomplished?

Purely on-chain membership body to recognize and compensate all individuals who hold and use expert knowledge of Polkadot in line with its broad interest and philosophy

Members hold rank denoting proven level of expertise and commitment as recognized by their peers and, for higher ranks, through general referendum.

Who Make up the Fellowship?

Experts in the Polkadot core protocol who maintain a consistent level of active contribution
Notably this does not include core developers of independent parachain protocols, which should develop their own protocol specific fellowships as needed.
Trajectory
- Currently: < 100 core developers, mostly from Parity or the Web3 Foundation
- Next year or two: Hundreds
- Ideal far future: Tens of thousands, independent of any centralized entity
Only one fellowship for Polkadot and Kusama

Function of the Fellowship

WhiteListedCaller track
- Root privileges
- More agile
- Maintains reasonable safety via Fellowship
White list proposals must pass two votes
- Expertise weighted Fellowship vote via second referendum pallet instantiation
- Same general referendum as other tracks, still requiring majority vote from DOT holders
Just an oracle!
Secondarily intended to cultivate a long term base of Polkadot core developers outside of Parity

OpenGov and Governance Goals

Open source + single process + track abstraction -> Transparency
Liberal proposal creation + greater throughput + per-track delegation -> Accessibility
Accessibility + No special bodies -> Decentralization
Limited origins + emergency tracks + white list -> Security
Multiple tracks + low risk tracks -> Concurrency
Low risk tracks + early confirmation -> Speed
Support and approval threshold curves + white list -> Agility

Governance Activity

5.5x more daily governance activity

Proposal Origins

Proposals now primarily authored via democracy

Treasury Usage

Treasury funds used more efficiently

OpenGov and You

Participate in OpenGov and Polkadot Fellowship on Polkadot and Kusama
Can customize OpenGov instances per parachain
Custom fellowships per parachain
Potentially create non-technical fellowships, such as a fellowship for brand ambassadors

Resources

OpenGov in Action

Vote - https://kusama.subsquare.io/referenda
Delegate vote - https://kusama.subsquare.io/referenda
Submit proposal - https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.dwellir.com#/referenda