1. Introduction
Polkadot OpenGov is the network’s onchain governance framework for proposing, voting on, and executing protocol decisions. It replaced Polkadot’s earlier Governance V1 model, which used the Council, Technical Committee, and public referenda as separate governance components.
The purpose of OpenGov is to move governance authority closer to DOT holders by allowing public proposal submission, simultaneous referenda, track-specific decision processes, conviction voting, and multi-role delegation. Instead of relying on a small representative body to manage many governance actions, OpenGov allows stakeholders to participate directly or delegate voting power to others based on expertise.
For builders, institutions, contributors, and long-term DOT holders, understanding OpenGov is important because governance decisions can affect protocol upgrades, treasury spending, technical changes, and the broader direction of the network. Participation is not limited to voting. It also includes reviewing proposals, delegating responsibly, submitting preimages, discussing referenda, and understanding the risks attached to each governance action.
This tutorial explains the structure of OpenGov and provides a practical overview of how participants can vote, delegate, and contribute to the governance process.
2. Architectural Role of OpenGov in Polkadot
OpenGov is designed to make Polkadot’s governance process more open, parallel, and risk-aware. Under Governance V1, the system included the Council, Technical Committee, and public referenda. That structure was functional, but it had limitations, including slower decision flow and fewer parallel governance paths.
Source: wiki.polkadot.com
OpenGov changes this by using a multi-track model. Different types of proposals enter different tracks, each with its own parameters for deposits, timing, approval, support, confirmation, and enactment. A low-risk treasury proposal does not need to follow the same process as a high-risk runtime upgrade.
This structure allows Polkadot to process multiple governance decisions at the same time while applying stricter requirements to proposals with greater network impact.
2.1 Defining the Technical Hierarchy
Several terms are important for understanding OpenGov.
A referendum is an onchain vote on whether a proposal should be accepted or rejected. In OpenGov, referenda are public and can be submitted by participants through the correct process.
A preimage contains the executable call behind a proposal. It defines what the referendum will actually do if approved and enacted. Because the preimage determines the technical action, it should be reviewed carefully before voting.
An origin represents the privilege level of a proposal. More powerful actions require more privileged origins. For example, a runtime upgrade requires a more sensitive origin than a small treasury spend.
A track is the governance path attached to an origin. Each track has its own capacity, decision deposit, timing rules, approval curve, support curve, confirmation period, and minimum enactment period.
The Technical Fellowship is a decentralised technical body that replaced some functions of the old Technical Committee. It can whitelist certain technical proposals so they can move through the Whitelisted Caller origin with shorter timelines than the Root origin.
2.2 Core Technical Objectives of OpenGov
OpenGov is designed around several governance objectives.
The first objective is permissionless participation. Public participants can start referenda, vote, and delegate voting power without needing approval from a central governance body.
The second objective is risk-aligned decision-making. Proposals with greater potential impact are placed into stricter tracks, while smaller or lower-risk proposals can move through tracks with different requirements.
The third objective is parallel governance. Multiple referenda can progress at the same time across different tracks, subject to each track’s capacity limits.
The fourth objective is accountable participation. Conviction voting allows participants to increase voting weight by voluntarily locking tokens, while delegation allows people to rely on trusted experts without giving up custody of their funds.
3. Step-by-Step Tutorial: How to Participate in OpenGov
This section explains the practical process for participating in Polkadot OpenGov. The exact interface may vary depending on the platform used, but the core governance concepts remain the same.
Common interfaces include Polkassembly, Subsquare, and Polkadot JS Apps. Polkassembly and Subsquare are often more accessible for proposal browsing and discussion, while Polkadot JS Apps are commonly used by advanced users who want direct interaction with the chain.
Before participating, make sure your wallet is connected to the Polkadot network, your account has enough DOT to pay transaction fees, and your balance remains above the existential deposit.
3.1 Phase I: Reviewing Referenda and Governance Tracks
The first step is to review active referenda. Open a governance interface such as Polkassembly or Subsquare and navigate to the active referenda section.
Look at the referendum title, track, origin, preimage, requested action, discussion history, voting status, and timeline. The track is important because it indicates the type of action being proposed and the level of risk attached to it.
Each track carries a different level of authority, and knowing which one a proposal sits on is often the most useful single piece of information when deciding how to vote.
Root is the highest. It covers runtime upgrades and fundamental network parameter changes. The lead-in time is long, the decision deposit is large, and it requires far higher approval thresholds than any other track, because a bug or bad call here affects every account on the network.
Whitelisted Caller handles technical calls that the Polkadot Technical Fellowship has already reviewed and approved. These move faster than Root proposals because the Fellowship’s review acts as a credibility signal. A time-sensitive fix to a known issue would typically come through here.
Wish for Change is non-binding. It does not execute any code. It lets the community signal a clear direction on something before a more consequential proposal is written.
For treasury spending, there are six tracks with fixed spending limits per proposal. Small Tipper covers up to 250 DOT, Big Tipper up to 1,000 DOT. The spender tracks handle larger amounts: Small Spender up to 10,000 DOT, Medium Spender up to 100,000 DOT, Big Spender up to 1,000,000 DOT, and Treasurer up to 10,000,000 DOT. Most grants and project funding proposals go through Small or Medium Spender. The higher the track, the longer the process and the larger the decision deposit required.
Before voting, read the proposal discussion and check whether the preimage matches the stated intention. A well-written proposal should explain what it does, why it matters, what funds or permissions are requested, and what risks or trade-offs may exist.
3.2 Phase II: Voting with Conviction
After reviewing a referendum, you can cast a vote. Open the referendum page, connect your wallet, and choose your voting direction. OpenGov supports Aye, Nay, Abstain, and split voting options, although conviction voting is not applied to abstain or split votes.
If you vote with conviction, you voluntarily lock tokens for a period of time to increase voting weight. The voting power formula is:
votes = tokens × conviction multiplier
The conviction options are as follows.
| Lock Periods | Vote Multiplier | Length in Days |
| 0 | 0.1x | 0 |
| 1 | 1x | 7 |
| 2 | 2x | 14 |
| 4 | 3x | 28 |
| 8 | 4x | 56 |
| 16 | 5x | 112 |
| 32 | 6x | 224 |
For example, a participant voting Nay with 10 DOT at 6x conviction has 60 voting power. A participant voting Aye with 20 DOT at 1x conviction has 20 voting power. A third participant voting Aye with 15 DOT at 2x conviction has 30 voting power. In this example, the participant with fewer DOT can still have greater influence because they accepted a longer lock period.
Staked DOT can still be used in governance. The lock prevents transfer while the lock applies, but it does not automatically require the user to stop participating in staking.
Only the last vote counts. If you vote again on the same referendum, the newer vote replaces the earlier one.
3.3 Phase III: Delegating Voting Power
Not everyone can read every proposal. That is what delegation is for. OpenGov lets you delegate your voting power per track, which means you can send your technical votes to someone with protocol expertise while keeping your treasury votes for yourself, or delegating those to a different person whose judgment on spending you trust.
If you do not know who to delegate to, governance DAOs are a practical starting point. Several independent groups operate specifically to review Polkadot referenda and vote on behalf of their delegators. You can find active delegates and their voting histories on Polkassembly and Subsquare. Look at their track record on the specific tracks you want to delegate, not just their general reputation.
There is a real cost to leaving your DOT inactive in governance. When a large share of the total DOT supply is not participating, a smaller set of active voters ends up making decisions for everyone. The outcome is more centralised decision-making, even inside a system that was built to prevent that. Delegating, even on tracks where you have no strong opinion, keeps the results more representative of the actual DOT holder base.
To delegate, open a governance interface that supports it, pick the track, choose your delegate, enter the amount and conviction you want to apply, and sign. The delegate cannot transfer your tokens. They can only vote with the power you assigned them on that specific track. You can revoke delegation at any time, though conviction locks may remain depending on how the delegation was configured.
3.4 Bounties and Child Bounties
Direct treasury proposals work well for one-off funding requests, but they are not always efficient for ongoing work. If you are running a recurring programme, like funding community events or maintaining a set of developer tools, submitting a separate referendum for each payment would create enormous governance overhead. Bounties solve this.
A bounty is a single OpenGov proposal that reserves a block of treasury funds for a defined scope of work. Once the community approves it, those funds are locked and managed by a curator, typically a multisig account, whose job is to evaluate contributions and release payments when the work is done. The curator does not have free access to the funds. Every payment still requires the curator to sign off that the agreed conditions were met.
Within an active bounty, curators can create child bounties to fund individual tasks without going back to OpenGov each time. A parent bounty covering ecosystem marketing, for example, might create child bounties for individual events, content pieces, or campaigns. The child bounty is approved and paid out by the curator directly. This is why large ongoing programmes, like Polkadot’s Community Events Bounty, can fund hundreds of individual activities without hundreds of separate referenda.
To contribute work through a bounty, find active bounties on Polkassembly or Subsquare, read the scope and requirements, and contact the curator. You will typically need to describe what you plan to do, why it fits the bounty’s goals, and how you will demonstrate completion. If approved, the curator issues a child bounty, you complete the work, and the payment goes directly to your account once the curator verifies the deliverable.
4. Technical Specifications for Governance Participation
OpenGov participation involves more than clicking Aye or Nay. Each governance action has technical and economic consequences, especially when deposits, locks, preimages, and track rules are involved.
A referendum begins with a proposal and a preimage. The proposal must enter the correct track based on its origin. It then passes through several stages before it can be enacted.
The main stages are the lead-in period, decision period, confirmation period, and enactment period. These stages help prevent rushed execution, allow community review, and ensure that approval and support requirements are met before a proposal becomes active.
4.1 Referendum Lifecycle and Deposits
During the lead-in period, the referendum waits until it satisfies the required conditions to enter the decision phase. These conditions include the minimum preparation time, available room on the track, and the required decision deposit.
During the decision period, votes are counted toward the outcome. The proposal must meet the track’s approval and support requirements.
During the confirmation period, the proposal must continuously satisfy the approval and support criteria. If it falls below the required thresholds, the confirmation timer resets.
During the enactment period, an approved referendum waits before execution. This delay gives the ecosystem time to prepare for the change.
Deposits are used to discourage spam and ensure that governance resources are used responsibly. A submission deposit is required for the proposal preimage, while a decision deposit is required before a referendum can move into the decision period.
4.2 Auditability and Safe Review Practices
OpenGov is transparent, but transparency only helps if participants review proposals carefully.
Before voting on a proposal, check the preimage, track, origin, requested action, proposer context, and community discussion. For treasury proposals, review the requested amount, delivery plan, previous work, reporting expectations, and whether the request fits the relevant track. For technical proposals, review whether credible technical contributors have examined the call and whether the proposal requires special urgency.
Participants should also understand cancellation and killing mechanisms. OpenGov includes specific origins for cancelling or killing referenda in cases where a proposal contains errors or presents a serious risk. These mechanisms help the network respond when a referendum should not proceed.
Do not rely only on proposal titles. The executable call is what matters. If the preimage and the written explanation do not match, treat the referendum with caution.
5. Advanced Governance Strategies
After learning the basics, participants can build a more systematic OpenGov workflow.
A simple approach is to begin by voting with low conviction while learning how tracks, timelines, and proposal discussions work. As confidence increases, participants can use higher conviction only for proposals they understand well and strongly support or oppose.
Institutions and teams may want to create internal review processes. Technical proposals can go to engineers. Treasury proposals can go to finance or operations teams. Ecosystem proposals can go to community or business development teams.
Delegation can also be combined with direct voting. A participant may delegate some tracks to trusted experts while still voting directly on proposals they care about. If they want to vote directly on a track where they have delegated, they may need to remove or adjust that delegation first.
Proposal submission requires additional care. A good proposer should prepare a clear document, define the requested action, generate and submit the correct preimage, choose the correct track, provide the necessary deposits, and engage the community before expecting a successful vote.
Governance participation should also include balance management. Keep enough DOT for fees, avoid reducing the account below the existential deposit, and regularly remove expired votes or unlock tokens when locks have ended.
6. Conclusion
Polkadot OpenGov is a practical system for protocol participation. It allows stakeholders to submit proposals, vote on referenda, delegate voting power, and help shape the direction of the network through onchain decision-making.
The shift from Governance V1 to OpenGov changed the structure of participation. Instead of relying on the Council and Technical Committee, Polkadot now uses public referenda, multiple origins, specialised tracks, conviction voting, and multi-role delegation.
For new participants, the best starting point is simple. Review active referenda, understand the track and preimage, vote with caution, and use delegation where trusted expertise is useful. For advanced participants, proposal submission and structured governance review can become meaningful ways to contribute.
OpenGov turns token ownership into a form of responsibility. Holding DOT allows participation, but effective governance requires judgement, context, and continued attention. By learning how OpenGov works, participants can move from passive holding toward informed stewardship of the network.