Cowrie Research

opengov

3 min read

OpenGov

  • Name: OpenGov
  • URL: https://wiki.polkadot.com/learn/learn-polkadot-opengov/
  • Category: Polkadot/Kusama onchain governance system / track-based referendum framework / conviction-voting governance pipeline
  • Summary: OpenGov is Polkadot and Kusama’s onchain governance system. It is worth keeping as a reference note because it is not just generic DAO branding; it is the actual policy machine through which public referenda, treasury spends, admin actions, whitelisted fast-track calls, and root-level runtime changes are routed. The important parts are public proposal flow, privilege-scoped origins and tracks, refundable deposits, approval/support curves, conviction voting, and per-track delegation.
  • What it does:
    • Lets anyone submit public referenda, with proposals routed into specific tracks based on the privilege of the requested action
    • Separates governance power by origin and track rather than forcing everything through one generic queue
    • Uses submission and decision deposits to price queue access and reduce spam
    • Applies track-specific timing, capacity, approval, support, and enactment rules depending on how sensitive the action is
    • Lets tokenholders amplify votes through conviction locking and delegate voting power by governance area
    • Handles not just symbolic voting but real execution paths for runtime changes, treasury spending, admin actions, and whitelisted fast-track calls
  • Key claims:
    • The Polkadot Wiki says all proposals are initiated by the public and then enter specific tracks with dedicated origins and parameters rather than moving through a single governance lane.
    • The same docs say tracks differ by privilege, capacity, deposits, timing, and approval/support curves, which is the real reason this matters: OpenGov is a routing and throttling system for authority, not just a vote counter.
    • The origins page shows how materially different the tracks are. Root, Whitelisted Caller, Wish For Change, Treasurer, Staking Admin, General Admin, Referendum Canceller, and several spender/tipper tracks all have different limits and thresholds.
    • The docs also make clear that OpenGov is execution-capable governance. Approved proposals enter enactment and can dispatch privileged calls after the required waiting period.
    • Conviction voting and multi-role delegation matter because OpenGov does not assume every DOT holder directly evaluates every proposal. Voting power can be amplified by lock duration and delegated by track to specialists.
    • The Whitelisted Caller path is especially important analytically: Polkadot’s Technical Fellowship can whitelist time-sensitive proposals for a shorter path that still executes with root-level force after referendum approval.
  • Whitepaper: No single canonical OpenGov whitepaper surfaced in this pass. The strongest machine-readable primary materials were the Polkadot Wiki’s OpenGov overview, origins/tracks page, and treasury page; see ../../whitepapers/opengov-primary-sources-2026-05-22.md.
  • Sources:

Internal linkages

  • Practical case where this directly controls an external system: snowbridge

  • Token-vote governance baseline with a much simpler single-pipeline shape: governor-bravo

  • Useful bridge comparison note because OpenGov-controlled upgrades are part of the trust model: hyperbridge

  • Last reviewed: 2026-05-22 UTC

Graph View

Backlinks