Skip to content

On-Chain Governance

Introduction

Polkadot’s governance system exemplifies decentralized decision-making, empowering its community of stakeholders to shape the network’s future through active participation. The latest evolution, OpenGov, builds on Polkadot’s foundation by providing a more inclusive and efficient governance model.

This guide will explain the principles and structure of OpenGov and walk you through its key components, such as Origins, Tracks, and Delegation. You will learn about improvements over earlier governance systems, including streamlined voting processes and enhanced stakeholder participation.

With OpenGov, Polkadot achieves a flexible, scalable, and democratic governance framework that allows multiple proposals to proceed simultaneously, ensuring the network evolves in alignment with its community's needs.

Governance Evolution

Polkadot’s governance journey began with Governance V1, a system that proved effective in managing treasury funds and protocol upgrades. However, it faced limitations, such as:

  • Slow voting cycles, causing delays in decision-making
  • Inflexibility in handling multiple referendums, restricting scalability

To address these challenges, Polkadot introduced OpenGov, a governance model designed for greater inclusivity, efficiency, and scalability. OpenGov replaces the centralized structures of Governance V1, such as the Council and Technical Committee, with a fully decentralized and dynamic framework.

For a full comparison of the historic and current governance models, visit the Gov1 vs. Polkadot OpenGov section of the Polkadot Wiki.

OpenGov Key Features

OpenGov transforms Polkadot’s governance into a decentralized, stakeholder-driven model, eliminating centralized decision-making bodies like the Council. Key enhancements include:

  • Decentralization - shifts all decision-making power to the public, ensuring a more democratic process
  • Enhanced delegation - allows users to delegate their votes to trusted experts across specific governance tracks
  • Simultaneous referendums - multiple proposals can progress at once, enabling faster decision-making
  • Polkadot Technical Fellowship - a broad, community-driven group replacing the centralized Technical Committee

This new system ensures Polkadot governance remains agile and inclusive, even as the ecosystem grows.

Origins and Tracks

In OpenGov, origins and tracks are central to managing proposals and votes.

  • Origin - determines the authority level of a proposal (e.g., Treasury, Root) which decides the track of all referendums from that origin
  • Track - define the procedural flow of a proposal, such as voting duration, approval thresholds, and enactment timelines

Developers must be aware that referendums from different origins and tracks will take varying amounts of time to reach approval and enactment. The Polkadot Technical Fellowship has the option to shorten this timeline by whitelisting a proposal and allowing it to be enacted through the Whitelist Caller origin.

Visit Origins and Tracks Info for details on current origins and tracks, associated terminology, and parameters.

Referendums

In OpenGov, anyone can submit a referendum, fostering an open and participatory system. The timeline for a referendum depends on the privilege level of the origin with more significant changes offering more time for community voting and participation before enactment.

The timeline for an individual referendum includes four distinct periods:

  • Lead-in - a minimum amount of time to allow for community participation, available room in the origin, and payment of the decision deposit. Voting is open during this period
  • Decision - voting continues
  • Confirmation - referendum must meet approval and support criteria during entire period to avoid rejection
  • Enactment - changes approved by the referendum are executed

Vote on Referendums

Voters can vote with their tokens on each referendum. Polkadot uses a voluntary token locking mechanism, called conviction voting, as a way for voters to increase their voting power. A token holder signals they have a stronger preference for approving a proposal based upon their willingness to lock up tokens. Longer voluntary token locks are seen as a signal of continual approval and translate to increased voting weight.

See Voting on a Referendum for a deeper look at conviction voting and related token locks.

Delegate Voting Power

The OpenGov system also supports multi-role delegations, allowing token holders to assign their voting power on different tracks to entities with expertise in those areas.

For example, if a token holder lacks the technical knowledge to evaluate proposals on the Root track, they can delegate their voting power for that track to an expert they trust to vote in the best interest of the network. This ensures informed decision-making across tracks while maintaining flexibility for token holders.

Visit Multirole Delegation for more details on delegating voting power.

Cancel a Referendum

Polkadot OpenGov has two origins for rejecting ongoing referendums:

  • Referendum Canceller - cancels an active referendum when non-malicious errors occur and refunds the deposits to the originators
  • Referendum Killer - used for urgent, malicious cases this origin instantly terminates an active referendum and slashes deposits

See Cancelling, Killing, and Blacklisting for additional information on rejecting referendums.

Additional Resources

Edit this page
Last update: November 21, 2024
| Created: October 16, 2024