Polkadot OpenGov 2.0

1. Introduction

1.1 The Challenge of Decentralized Governance

Blockchain networks promise decentralization of not just execution but governance itself. However, effective governance requires informed decision-making, which in turn demands time, expertise, and sustained attention. In traditional systems, these resources are purchased through salaries, consulting fees, and institutional budgets. In decentralized networks, governance has largely relied on unpaid volunteers motivated by token ownership and ideological alignment.

This volunteer model faces inherent limitations. Token holders with the largest stakes often lack the time for detailed proposal review. Those with relevant expertise may lack sufficient token holdings to influence outcomes. The result is predictable: low participation rates, poor-quality decision-making, and governance capture by whoever can afford to pay the most attention.

Recent data from major blockchain governance systems reveals the scale of the problem. Ethereum's governance discussions see participation from fewer than 200 active addresses. MakerDAO's governance voting regularly involves less than 10% of circulating tokens. Even when participation increases, the quality of decisions does not necessarily improve, as most voters lack the expertise to evaluate complex technical or economic proposals.

1.2 Polkadot OpenGov: Current State

Polkadot's transition from Governance v1 to OpenGov in June 2023 represented a significant architectural improvement. The system introduced 15 parallel tracks with different approval thresholds, eliminated centralized bodies like the Council and Technical Committee, and implemented flexible multi-track delegation. These changes addressed many structural bottlenecks of the previous system.

OpenGov's track-based architecture enables simultaneous consideration of multiple proposals, with governance parameters tuned to each track's privilege level. A Small Tipper proposal requiring 250 DOT moves through a 7-day decision period with relatively low approval thresholds. A Root track proposal that can modify the runtime itself requires 28 days with initial support near 47% of network issuance and approval exceeding 88%.

Despite these improvements, fundamental challenges remain. Participation rates hover around 5% of circulating supply. Treasury proposals often pass with minimal scrutiny because few voters have time to evaluate detailed technical roadmaps or marketing plans. Milestone verification is informal and inconsistent. Projects receive funding in large tranches with limited ongoing oversight, leading to a high failure rate that wastes treasury resources.

1.3 The Need for Evolution

The solution is not to abandon decentralization but to professionalize it. Just as Polkadot compensates validators for securing the network, it should compensate curators for securing governance quality. This requires systematic incentives, accountability mechanisms, and reputation systems that make good governance financially rewarding and poor governance costly.

OpenGov 2.0 proposes evolutionary enhancements that preserve OpenGov's decentralized architecture while adding professional infrastructure. Token holders retain ultimate decision-making power. The curator system provides expert review, milestone verification, and informed recommendations, but cannot override community votes. This hybrid model combines the legitimacy of broad-based participation with the effectiveness of expert analysis. Critically, it transforms the experience of proposing something to the network: rather than entering a public trial with no guidance and hostile debate, proposers enter a supported, collaborative process where experts help them strengthen their submissions before a community vote. Submitting to a network that uses Axiongov should feel like applying to a well-run incubator, not appearing before a court. Critically, the underlying curator network and Axiongov signal layer are designed to be chain-agnostic from the start — OpenGov 2.0 is the Polkadot/Kusama instantiation of infrastructure that can serve any on-chain treasury. Polkadot is the pilot. The architecture is universal.

2. System Design

2.1 Mission Alignment and the Curator Charter

Every curator brings a domain specialty — marketing, technical infrastructure, DeFi economics, business development. That expertise is the basis for their authorization and the source of their value. But expertise alone is not enough. A marketing curator who approves a technically competent campaign that grows the wrong kind of attention, funds a strategically hollow initiative, or concentrates ecosystem influence in ways that undermine decentralization is doing their domain job while failing the network. The current system can detect "did this project deliver?" It cannot, by itself, detect "should this project have existed?"

Mission alignment is the foundational layer that sits above all the mechanics of proposal review, reputation scoring, and milestone verification. Before a curator evaluates a single proposal, they have committed — on-chain, as a condition of authorization — to a shared definition of what constitutes good for the network. That commitment is the Curator Charter.

What the Charter Is

The Curator Charter is a living community document that defines the network's governance mission, the reasoning principles curators apply across all domains, and domain-specific lenses that translate those principles into practice. It is not a list of approved proposal types or a filter on subject matter. It is a framework for how curators reason, not what they approve.

The charter is community-authored and ratified through governance as a first-class on-chain artifact. Its hash is referenced in every curator authorization. When a curator is authorized, they affirm the current charter version. If the charter is amended through a subsequent governance vote, active curators have a defined window to re-affirm the updated version or have their authorization lapse. The platform does not write the charter — the community does. What the platform provides is the architectural requirement and the binding mechanism.

Core Principles Across All Domains

While the specific content of the charter is community-determined, the architecture requires it to address at minimum a set of cross-domain principles that apply to every curator regardless of specialty. These are the properties the community will need to define and ratify:

• Network health over proposal merit. A well-executed proposal that concentrates power, creates dependency on external actors, or extracts value from the treasury without returning it to the ecosystem fails this test regardless of domain-specific quality. Curators evaluate proposals against the network's long-term health, not just their internal coherence.
• Decentralization as a standing constraint. Proposals that reduce the number of independent actors in a critical function, create single points of control, or structurally advantage one participant over others require explicit justification and heightened scrutiny, regardless of how well they execute their stated purpose.
• Self-sustainability over dependency. Treasury funding should build capacity the network retains, not create ongoing reliance on the funded entity. Curators evaluate whether a funded initiative leaves the ecosystem stronger and more capable, or whether it builds a dependency that requires continued funding to maintain.
• Mission coherence across domains. A proposal may be technically sound, financially reasonable, and well-marketed but still misaligned with what the network is trying to become. Curators are expected to surface this misalignment even when it falls outside their primary domain. A marketing curator who sees a business model that undermines the network's credibility should say so, citing the charter, not stay silent because "business isn't my area."

Domain-Specific Lenses

The charter also defines how cross-domain principles translate into domain-specific reasoning. These lenses are not restrictions — they are guidance for how a curator applies their expertise in service of the mission rather than in isolation from it. Examples of what these lenses address (the community will define the actual content):

• Technical curators evaluate not just whether something works but whether it builds reusable, maintainable infrastructure the ecosystem can build on. A technically impressive project the network cannot maintain or extend after the grant period is a failed treasury investment.
• Marketing curators evaluate not just whether a campaign is well-designed but whether it builds genuine ecosystem credibility and attracts the right participants. Vanity metrics, misleading claims, or campaigns that attract extractive users are not good uses of treasury funds even if the creative work is excellent.
• Business and ventures curators evaluate not just whether a business model is viable but whether it creates value that accrues to the ecosystem. A fundable business that captures value for its founders without building on or returning value to the network is not what treasury funding is for.
• DeFi and economics curators evaluate not just mechanism soundness but systemic risk. A novel mechanism that works in isolation but introduces contagion risk or exploitable incentives at scale fails the mission even if the math checks out.

How the Charter Binds Curators in Practice

Charter alignment operates at two levels. The first is individual reasoning: every curator written assessment must reference the charter framework, not just domain-specific technical findings. A recommendation that says "the marketing strategy is strong, the deliverables are achievable, but the business model creates a treasury dependency that violates the self-sustainability principle" is the intended output of a charter-aligned curator. It gives voters a richer signal than domain-specific approval alone.

The second level is reputation accountability. The curator review panel, when evaluating a reputation challenge or conducting a performance review, can assess whether a curator has been reasoning from charter principles or optimizing purely for domain-specific accuracy. A pattern of approving proposals that are competent but charter-misaligned is a legitimate basis for reputation adjustment, separate from outcome accuracy. This creates a second dimension of accountability that the current system cannot enforce.

Charter Governance: Who Creates and Amends It

The charter is not authored by the platform, by Two Pebbles, or by the initial curator cohort. It is authored by the community through an open governance process and ratified by OpenGov referendum. The process the whitepaper recommends — without prescribing the outcome — is:

1. Open drafting period: Forum discussion and working groups across domains produce a draft charter. Multiple competing drafts are welcomed. This phase is explicitly pre-governance and non-binding.
2. Community comment period: A defined period for open comment on a consolidated draft, with structured opportunities for domain experts, token holders, and existing governance participants to refine the language.
3. Governance ratification: The consolidated draft goes to an OpenGov referendum at an appropriate track. Ratification produces an on-chain artifact with a content hash that the platform binds curator authorizations to.
4. Amendment process: Charter amendments follow the same referendum process. Minor clarifications may go through a lighter-weight track; substantive changes to core principles require higher approval thresholds. Active curators have a defined re-affirmation window after any amendment.

The Proposal Health Signal

The charter's domain lenses become most useful when they are made visible during the review process, not just invoked in final written assessments. The Proposal Health Signal translates the charter's dimensions into a live, multi-axis evaluation display that curators update as they work and that proposers and the broader community can read at any point in the review lifecycle.

Rather than a binary approved/rejected state, each proposal carries a signal board with one row per charter evaluation dimension. Each dimension reflects the current assessment from the curator or curators with relevant expertise:

The dimensions on the signal board are not fixed by the platform — they are derived from the charter's domain lenses, configured per deployment through governance. A Polkadot treasury proposal might carry dimensions like: technical soundness, mission alignment, financial sustainability, business model viability, marketing coherence, decentralization impact. A different deployment of the curator network might configure entirely different dimensions appropriate to its ecosystem. The signal board adapts to whatever the charter defines.

Two properties make this more than a status tracker. First, every signal state change requires written reasoning attached on-chain — a curator cannot flip a dimension to Concern without saying why. This keeps the signal honest and gives the proposer something actionable. Second, gaps in coverage are visible: a proposal where mission alignment shows "Not yet reviewed" three days before the decision period ends is a visible gap that other curators, voters, and the community can act on — by flagging it, volunteering to assess, or treating the gap itself as a signal.

In pallet terms, the signal board is stored as a bounded set of (dimension, signal_state, curator_id, reasoning_hash) tuples on each proposal assignment in pallet-curator, updated by curators through a dedicated extrinsic. The signal is readable by any chain participant without additional permissions. It is not a voting mechanism — it does not affect approval thresholds or curator reputation directly. It is an information layer that makes the review process transparent and collaborative rather than opaque and sequential.

2.2 Curator Model Overview

Curators are governance professionals who provide paid review services for proposals and milestone verification. In the OpenGov 2.0 deployment on Polkadot/Kusama, they are elected through OpenGov voting. In other deployments of the curator network, authorization mechanisms are configured by the host chain's governance. In all cases, curators do not hold veto power — their role is advisory and operational: they review proposals, verify milestone deliverables, provide written assessments, and help proposers improve their submissions. The community retains full decision-making authority. All curators operate under the Curator Charter (Section 2.1), which defines the mission-alignment principles their domain expertise is applied in service of.

Curator Selection Process

Becoming a curator requires an OpenGov proposal on the Fellowship Admin or General Admin track. Candidates present their credentials, expertise areas, and conflict of interest disclosures. The community votes to authorize specific individuals as curators for specific tracks. Authorization includes on-chain affirmation of the current Curator Charter — the candidate commits to reasoning from its principles as a condition of their role. This process ensures democratic legitimacy, meritocratic selection, and mission alignment from day one.

Initially, the system targets 5-8 curators across the Small and Medium Spender tracks, expanding to 15-20 curators across all tracks by Phase 3, and eventually 50+ curators in the mature system. Specialization emerges naturally as curators build reputations in specific domains: technical infrastructure, marketing and growth, DeFi economics, ecosystem development, etc.

Curator Responsibilities

Curators perform five primary functions:

1. Proposer Development: Before a proposal reaches formal review, curators provide structured guidance to help proposers strengthen their submissions. This includes feedback on scope, budget, milestone design, and mission alignment. The relationship is collaborative, not adversarial — curators are not gatekeepers, they are the first expert support a proposer receives. A proposal that arrives at community vote having been shaped by curator feedback is more likely to succeed and more likely to deliver on its promises.
2. Proposal Review: Evaluate proposals for feasibility, cost-effectiveness, alignment with network goals, and proposer credibility. Provide written feedback visible to all voters. Every review explicitly references the Curator Charter dimensions that bear on the recommendation.
3. Milestone Verification: When funded projects submit milestone deliverables, curators review documentation, test implementations, and verify that promised work was completed to acceptable standards.
4. Advisory Recommendations: Explicitly recommend approval or rejection based on professional assessment. These recommendations carry weight proportional to the curator's reputation but do not constrain voting.
5. Dispute Resolution: When proposers and curators disagree on milestone completion, serve on resolution panels that arbitrate disputes according to transparent criteria.
6. Charter Application: In every written assessment, explicitly reference the Curator Charter principles that bear on the recommendation — not just domain-specific findings. Mission-alignment reasoning should be visible in every curator output, giving voters a signal that goes beyond technical or operational accuracy.

Capacity Limits

Each curator has defined capacity based on their tier and track responsibilities. A Senior Curator on the Medium Spender track might handle 3-5 active proposals simultaneously, with each requiring 10-20 hours of review work. Capacity limits prevent overextension and maintain review quality.

The system automatically distributes proposals across available curators, preferring those with relevant expertise and strong track records. If all curators are at capacity, new proposals enter a queue. This creates natural market signals: when demand exceeds curator capacity, the community can vote to authorize additional curators.

2.3 Reputation Economy

The reputation system provides accountability and quality control without requiring centralized enforcement. Every curator action affects their on-chain reputation score, which determines their influence, earning potential, and continued employment.

Reputation Scoring Mechanics

Curators begin at 50 reputation points with Junior status. Reputation increases for:

• Approved proposals that successfully complete milestones: +1 to +5 points depending on project scale
• Milestone verifications accepted without dispute: +0.5 points
• Being in the majority position when community vote aligns with recommendation: +0.25 points
• Detailed, high-quality written feedback cited by community: +0.5 points

Reputation decreases for:

• Approved proposals that fail to deliver: -1 to -25 points, scaled by treasury damage and project size. A Small Spender failure might be -1 to -5 points, while a Big Spender or Treasurer track failure that wastes substantial funds could be -15 to -25 points. Complete failures with zero delivery at maximum penalty.
• Milestone verifications that are successfully disputed: -5 points per occurrence. Repeatedly approving incomplete or fraudulent milestones compounds penalties and indicates poor judgment.
• Being consistently in the minority when community disagrees: -2 points per occurrence. Occasional minority positions are acceptable, but patterns of being wrong when opposing consensus indicate misalignment with community values or poor judgment.
• Conflicts of interest not disclosed: -20 to -50 points depending on severity and impact. Undisclosed financial relationships or hidden affiliations that influence decisions represent fundamental breaches of trust.
• Malicious behavior or collusion: Immediate removal from curator status, full reputation reset to zero, and potential slashing of any held deposits or bonds.

Retrospective Accountability

The most important feature is retrospective reputation adjustment based on actual outcomes. If a curator approves a proposal that receives 500K DOT and delivers nothing, the reputation penalty is severe (potentially -20 to -25 points), enough to drop a Senior Curator down to Junior status or remove a marginal curator entirely. If they approve a 10K DOT project that delivers as promised, they gain reputation proportionally (+1 to +3 points).

These severe penalties for failures are essential to create meaningful accountability. A curator with 75 reputation points (Senior tier) who approves a catastrophic failure could drop to 50-55 points (regular Curator tier) or even below 50, losing their senior status, higher compensation, and influence. Multiple failures can completely eliminate a curator's career. This creates powerful incentives for accurate judgment rather than risk aversion.

The asymmetry is intentional: gains come slowly through consistent good judgment, while losses from major failures are swift and severe. This reflects the reality that bad governance decisions impose concentrated costs on the network, while good decisions provide diffuse benefits. Curators must build reputation patiently and protect it carefully, as one catastrophic mistake can destroy years of careful work.

Curator Bond Requirements

All curators must stake a DOT bond upon authorization. The full bond model — including the two-layer structure of baseline bond plus per-proposal top-up, and the collective liability mechanism across curator panels — is defined in detail in Section 3.3. What follows here is the slashing framework that governs when and how those bonds are at risk.

Bond amounts are governance-configurable (Bond(tier) for baseline, ProposalBond(curator) for per-proposal top-up) and are designed to be proportional to the blast radius of the proposals each curator approves — not a flat figure disconnected from actual exposure. Bonds are held in escrow, earn standard staking returns, and are returned after a 90-day waiting period upon clean exit from curator status.

Slashing conditions include:

• Primary Slash (partial or full): Applied directly to the responsible curator. Partial slashing (10-50%) covers gross negligence — approving obvious scams without due diligence, repeated undisclosed conflicts of interest, systematic bias, or persistent poor judgment. Full slashing (100%) applies to proven collusion, vote buying or selling, intentional sabotage, fraudulent credential claims, or malicious behavior designed to harm the network.
• Secondary Slash (collective liability): If a primary slash does not fully recover the verified treasury loss, the remaining gap is distributed across the other curators assigned to that proposal. Each has a governance-set window (CollectiveCallWindow) to contribute voluntarily before automatic on-chain slashing applies. Curators subject to secondary slash also receive a reputation penalty for insufficient panel oversight.

Bond slashing requires either unanimous vote from a 5-curator review panel drawn from curators not assigned to the affected proposal, or an OpenGov referendum. Secondary slash is automatic on-chain once CollectiveCallWindow expires — it was accepted as a condition of assignment and requires no additional vote.

For DAO curators, bond requirements follow the same two-layer structure at the collective level. Collective liability calls are directed to the DAO entity; internal distribution among members is governed by the DAO's own rules.

Tiered System

Reputation determines curator tier and associated privileges:

Higher-tier curators receive larger monthly retainers for maintaining availability and expertise, can handle more complex proposals through increased capacity, and their recommendations carry more weight in aggregated curator scores. The flat VerificationRate milestone verification rate ensures all curators are compensated equally for actual verification work regardless of tier, recognizing that the time and effort required to properly verify deliverables is valuable regardless of reputation level. Performance bonuses provide additional upside tied to successful project outcomes.

2.4 Active Voter Recognition and Rewards

Beyond curators and delegators, OpenGov 2.0 recognizes and rewards token holders who actively participate in governance through direct voting. These active voters invest significant time reading proposals, evaluating arguments, and casting informed votes. Currently, this work goes completely uncompensated, creating no incentive for quality participation.

Active Voter Tier System

Active voters build reputation through consistent, informed participation. The system tracks voting behavior to identify voters who demonstrate engagement beyond simple token weight:

• Participation Rate: Percentage of eligible proposals voted on (tracks engagement)
• Reading Time: Optional analytics tracking time spent reviewing proposals and curator feedback
• Vote Alignment with Outcomes: How often voter's position aligns with successful project delivery
• Discussion Contribution: Quality comments on Polkassembly/Subsquare that inform community debate
• Conviction Usage: Willingness to lock tokens with conviction for high-priority votes (demonstrates commitment)

Active voters progress through tiers based on sustained participation and demonstrated judgment:

Axiongov emits a Participation Signal for every wallet that votes: a ZK-attested, privacy-preserving binary proof that a wallet participated in governance. The signal carries no information about how the wallet voted, which way they leaned, or what their token holdings are — only that they participated. Connected platforms receive this signal and build their own reward logic on top: staking bonuses on Polkadot/Kusama, reputation points on governance forums, early access to parachain auctions, DAO membership privileges, or any other incentive the platform chooses to offer. Axiongov does not prescribe the reward — it provides the verified signal that makes any reward system possible.

Active Voter vs. Curator Path

Active voter reputation serves as a qualification pathway to becoming a curator. A token holder who achieves Expert Voter status has demonstrated sustained engagement and good judgment, making them an excellent curator candidate. When they propose themselves for curator status through OpenGov voting, their voter reputation serves as credible evidence of qualification.

This creates a natural talent pipeline that begins with proposers: proposers → engaged community members → active voters → expert voters → curator candidates. Someone who brings a project to the network, experiences collaborative curator support, sees their proposal improved and approved, and then delivers on their milestones has already demonstrated the kind of engagement and judgment that makes an excellent governance participant. The pathway is organic and welcoming, not gatekept.

Preventing Gaming

Several mechanisms prevent active voter rewards from being gamed:

• Outcome Alignment Tracking: Cannot just vote randomly; rewards require voting for proposals that actually succeed
• Minimum Token Requirements: Must hold and stake a meaningful amount (at or above MinStakeThreshold, governance-configurable) to qualify for active voter rewards
• Discussion Quality Signals: Higher tiers require constructive contributions to governance discussions, reviewed by community
• Conviction Requirements: Expert Voter tier requires using conviction voting on significant proposals, demonstrating commitment beyond minimal participation
• Time Locks: Tier advancement requires sustained performance over months, not just short-term gaming

These safeguards ensure active voter rewards flow to genuine participants rather than bots or gaming attempts.

The Participation Signal Interface

The participation signal is an open standard that any platform can consume. Axiongov emits signal events in a standardised format that contains only what is necessary and nothing that compromises voter privacy:

A platform consuming the signal can verify that a wallet genuinely participated in governance at a given tier, on a given chain, within a given timeframe — without learning anything else about that wallet. The platform then applies its own reward logic: a staking protocol might increase yield for Engaged Voters, a DAO tool might unlock features for Active Voters, a parachain auction might prioritise Expert Voters for early access. Axiongov emits the signal and steps back. What platforms build on top of it is limited only by their imagination and their own governance.

This design makes Axiongov useful to any platform that wants to increase governance participation, not just chains that can adjust staking parameters. A forum, a wallet, a block explorer, an analytics dashboard — any of these can integrate the participation signal and reward engaged community members in ways meaningful to their specific user base.

2.5 DAO Curators and Domain Specialization

While individual curators provide valuable expertise, complex proposals often require multidisciplinary evaluation that exceeds any single person's capabilities. A business accelerator proposal needs assessment of marketing strategy, technical architecture, financial modeling, and operational execution. Axiongov enables DAOs — Decentralized Autonomous Organizations from anywhere in the ecosystem — to serve as collective curation bodies, bringing together diverse expertise under a single organizational structure. DAO curators are signal contributors, not fund managers: they strengthen the allocation signal through expert domain review, but the connected chain's treasury retains full control of its funds and acts on signals through its own governance.

DAO Curator Model

A DAO curator consists of multiple specialists who collectively evaluate proposals within their domain of expertise. Rather than individual curators attempting to master all aspects of governance, DAO curators organize around complementary skill sets:

• Technical Infrastructure DAO: Blockchain developers, system architects, security auditors, and protocol engineers evaluating technical proposals
• Marketing & Growth DAO: Brand strategists, community builders, content creators, and growth marketers assessing ecosystem expansion initiatives
• DeFi & Economics DAO: Economists, financial analysts, tokenomics experts, and traders reviewing economic mechanisms and treasury management
• Business & Operations DAO: Startup veterans, business strategists, operational experts, and venture builders (like Two Pebbles) evaluating venture acceleration and business development
• Research & Education DAO: Academics, educators, technical writers, and researchers assessing knowledge creation and educational initiatives

Each DAO curator applies to become authorized for specific domains or tracks through the host chain's governance. The community evaluates the DAO's collective expertise, governance structure, and relevant experience before authorization. Any DAO in the broader ecosystem — an existing parachain team, a research collective, an independent domain expert group — can apply to contribute curation signals on Axiongov without needing to be created for this purpose.

Domain-Specific Curation Signals

Rather than managing separate treasury pools, DAO curators contribute domain-specific signals to the overall allocation signal Axiongov emits. A Technical Infrastructure DAO reviewing a protocol upgrade provides deep technical curation that a generalist curator cannot match. A DeFi & Economics DAO reviewing a treasury management proposal brings specialist financial judgment. These domain signals are aggregated within Axiongov's signal computation and emitted to the connected chain — which retains full control of its treasury and decides how to weight domain expert signals in its own governance process.

This architecture keeps the separation clean. Axiongov is the signal platform. Connected chains are the execution layer. DAO curators are expert contributors to the signal — not fund administrators. A Technical Infrastructure DAO on Polkadot cannot spend protocol treasury funds; it can provide a stronger, more credible technical signal that informs how the community votes on proposals in that domain. The same DAO can simultaneously contribute signals on any other chain connected to Axiongov, building reputation and influence across the ecosystem without being tied to a single treasury.

DAO Composition and Zero-Knowledge Credentials

DAO curators leverage Zero-Knowledge proofs to demonstrate collective expertise while preserving member privacy. When applying for curator authorization, a DAO can prove:

• "Our DAO includes 5 members with PhDs in computer science or related fields" without revealing member identities
• "We have 3 members with 10+ years blockchain development experience" without disclosing employment history
• "Our team includes 2 members who previously founded venture-backed startups" without revealing companies
• "All members have clean reputation records with no conflicts of interest" without identifying individuals
• "Our combined experience spans 80+ years in relevant domains" aggregating member credentials

This enables high-caliber professionals to contribute governance expertise without compromising their primary careers, employment agreements, or personal privacy. A senior engineer at a major tech company can participate in a Technical Infrastructure DAO under pseudonym, proving their credentials through ZK while maintaining separation from their employer.

DAO Internal Governance and Compensation

DAO curators receive the same compensation structure as individual curators (monthly retainers, milestone verification fees, performance bonuses), but scaled to reflect their collective capacity and expertise:

DAO retainers are calibrated to provide roughly equal per-member compensation across all DAO sizes, reflecting that larger DAOs benefit from greater specialization and work distribution but also face higher coordination overhead. The DAOVerificationRate (set lower than the individual VerificationRate) recognizes that collective verification is more efficient — multiple perspectives catch errors faster, work can be parallelized across specialists, and cognitive load is distributed. When the DAO collectively verifies a milestone, the DAO entity earns DAOVerificationRate regardless of how many members participated in the verification.

For example, a Medium DAO receiving DAORetainer(Medium) supporting 8 members distributes a pro-rata share to each member as base compensation. If the DAO performs milestone verification in a month, members split that income equally or weight it by contribution — at whatever DAOVerificationRate the community has set. The internal distribution is at the DAO's discretion; what matters to OpenGov is the DAO's collective performance and reputation.

• Equal Split: All active members receive equal shares regardless of seniority
• Contribution-Weighted: Distribution based on hours contributed or proposals reviewed by each member
• Expertise-Weighted: Senior experts receive larger shares reflecting their credentials and judgment value
• Hybrid Models: Base equal distribution plus bonuses for exceptional contributions

The DAO's internal governance is transparent to members but opaque to the broader network. What matters for OpenGov is the DAO's collective performance, not how they organize internally.

DAO Reputation and Accountability

DAO curators build reputation as organizational entities through the same mechanisms as individual curators: successful project outcomes increase reputation, failures decrease it, accuracy over time determines tier advancement or demotion. However, reputation is collective rather than individual:

• The DAO as a whole is rewarded or penalized based on proposal outcomes
• Individual member identities remain private unless voluntarily disclosed
• Member turnover is permitted; DAOs can add/remove members while maintaining organizational continuity
• If a DAO's reputation falls below minimum thresholds, the entire organization loses curator status

This structure creates strong internal incentives for quality control. DAO members self-police because poor performance by any member affects the entire group's reputation and compensation. Collective accountability reinforces individual responsibility.

Advantages of DAO Curators

The DAO curator model provides several benefits over purely individual curation:

• Multidisciplinary Expertise: Complex proposals receive comprehensive evaluation covering technical, business, marketing, and operational dimensions
• Reduced Individual Burden: Members contribute 10-20 hours monthly to their specialty rather than attempting full-time comprehensive curation
• Natural Specialization: DAOs self-select into domains matching their collective expertise, contributing higher-quality signals in areas where they have genuine depth
• Built-in Checks and Balances: Multi-signature decision-making prevents individual bias or conflicts from dominating
• Collective Deliberation: Internal discussion improves analysis quality and catches issues individual curators might miss
• Sustainability: DAOs absorb member turnover more gracefully than individual curators (one member leaving doesn't eliminate the expertise)
• Privacy Preservation: High-caliber professionals can contribute under organizational pseudonymity with ZK-proven credentials
• Scalability: As proposal volume grows, new DAO curators can be authorized more easily than recruiting individual experts

Implementation Pathway

DAO curators are introduced in Phase 2-3 of the implementation roadmap, after individual curators prove the model's viability. The phased approach enables:

1. Phase 1: Individual curators establish baseline reputation systems and workflows
2. Phase 2: First DAO curators authorized as signal contributors for specific domains (e.g., Technical Infrastructure, DeFi & Economics)
3. Phase 3: Full domain curation coverage with specialized DAO curators contributing signals across all major proposal categories
4. Phase 4: Mature ecosystem with mix of individual and DAO curators, competition driving quality

This gradual rollout allows the community to evaluate DAO curator signal quality against individual curators, refine governance structures, and adjust domain coverage based on demonstrated outcomes.

2.6 Delegation Incentives

For token holders who cannot or prefer not to directly vote on every proposal, delegation provides an alternative path to governance participation. The current lack of delegation incentives creates a tragedy of the commons: everyone benefits from good governance, but no individual is rewarded for contributing to it. OpenGov 2.0 addresses this through the participation signal layer, and on Polkadot/Kusama specifically through staking boost mechanisms.

Staking Integration (Polkadot/Kusama Deployment)

On Polkadot/Kusama, the participation signal could be consumed by the staking layer to enhance validator rewards for active governance participants — but this requires a deliberate decision by Polkadot and Kusama governance to modify their tokeneconomics through a runtime upgrade and community vote. Axiongov provides the verified participation data that makes that decision possible; whether and how the connected chain acts on it is entirely within that chain's own governance authority. This is one example of what a platform can build on the signal — other deployments will choose reward mechanisms appropriate to their own economics and governance. The formula below represents what staking return enhancement could look like if a connected chain adopts this model. Token holders who stake DOT earn BaseStakingRate through validator rewards — a network-determined figure that varies with staking ratio, era rewards, and validator commission. As of 2026, native on-chain staking rates are in the mid-to-high single digits annually. If a chain chooses to reward governance participation, the incremental bonus would be capped at MaxGovernanceBonus, a governance-configurable parameter:

Under a chain that has adopted this model, a fully engaged token holder achieving Expert Voter status could earn BaseStakingRate + MaxGovernanceBonus. Someone who prefers pure multi-track delegation earns BaseStakingRate + MultiTrackDelegationBonus. The hard cap at MaxGovernanceBonus ensures the governance incentive system remains economically viable while still providing meaningful rewards for participation — a meaningful relative increase over base staking returns without creating unsustainable treasury burden. The community sets all these values through governance.

Delegator Reputation

Just as curators build reputation through accurate assessments, delegators build reputation through intelligent delegation choices. Token holders who consistently delegate to high-performing curators accumulate delegator reputation, which unlocks higher bonus rates and potentially other ecosystem benefits (priority access to parachain auctions, governance NFTs, etc.).

This creates a market for curator quality. Good curators attract more delegators, which increases their influence and validates their expertise. Poor curators lose delegators and eventually lose their curator status as their reputation falls below minimum thresholds.

2.7 Zero-Knowledge Credentials

A significant barrier to expert participation in blockchain governance is the pseudonymity/transparency tradeoff. Real-world experts with valuable credentials often cannot link their professional identity to on-chain activity without compromising privacy or facing regulatory concerns. Similarly, active voters may want to prove their voting track record without revealing their identity or wallet addresses.

The Privacy Challenge

Consider a senior engineer at a major tech company who has deep expertise in distributed systems. They could provide valuable technical review for Polkadot infrastructure proposals or votes, but they cannot reveal their employer affiliation without violating employment agreements. Similarly, an economist at a financial institution might have relevant insights for DeFi governance but cannot publicly associate themselves with crypto activities.

Active voters face related challenges. Someone who has built strong voter reputation might want to become a curator but cannot risk doxxing themselves by revealing their voting wallet address. A privacy-conscious participant might want to prove "I'm an Expert Voter with 80%+ accuracy" without revealing which specific proposals they voted on or their token holdings.

Current governance systems force a binary choice: either prove credentials publicly (and sacrifice privacy) or remain pseudonymous (and sacrifice credibility). This excludes many potential high-quality curators.

ZK Proof Solution

Zero-knowledge proofs enable curators to prove specific attributes about themselves without revealing identifying information. A curator can prove:

• "I hold a PhD in cryptography from an accredited university" without revealing which university or their identity
• "I have 10+ years of experience in software architecture" without revealing where they worked
• "My curator reputation score exceeds 75" without revealing the exact score or review history
• "I am an Expert Voter with 80%+ outcome alignment" without revealing voting history or wallet address
• "I've voted on 200+ proposals over 18 months" without revealing which proposals or positions taken
• "This is my only curator/voter account" without revealing any other addresses I control

These proofs are cryptographically verifiable but reveal zero additional information beyond the specific claim. The curator interface displays verified credentials as badges: "Verified Technical Expert (ZK)" or "Reputation >80 (ZK)", giving token holders confidence in curator qualifications without compromising curator privacy.

Implementation Approach

Phase 3 of the implementation roadmap introduces ZK credentials. For the OpenGov 2.0 deployment, this leverages existing Polkadot infrastructure (potentially zk-SNARKs capabilities being developed for Polkadot 2.0). For other deployments of the curator network, ZK credential infrastructure is chain-specific but the proof format is standardized at the Axiongov layer, enabling cross-chain credential portability. All deployments integrate with established credential providers (universities, professional associations, existing identity services) to anchor ZK proofs in real-world verification while maintaining on-chain pseudonymity.

This feature is optional. Curators can operate with full public disclosure of their identity and credentials, with ZK proofs, or with pure pseudonymity (though the latter will likely struggle to build reputation without demonstrated expertise). The system accommodates all approaches.

3. Economic Mechanisms

3.1 Money Flow Architecture

Axiongov creates two distinct and deliberately separate value flows for every proposal: the governance flow (who pays for the process of evaluating and overseeing a proposal) and the grant flow (the treasury funds released to the proposer upon community approval and milestone delivery). These flows never mix. Understanding the separation is essential to understanding how Axiongov aligns incentives without creating conflicts of interest.

The Governance Flow: Proposer Pays

The proposer pays for the entire governance process associated with their proposal. This covers document storage on Crust Network, curator review and assessment work, Health Signal documentation, milestone verification throughout the project, and Axiongov’s operational costs. Payment is made at submission in the currency of the connected chain. See Section 3.2 for the full submission fee model.

The proposer interacts with their connected chain’s governance interface — they never see Axiongov directly. The submission fee is collected by the connected chain’s Axiongov integration and routed to a per-proposal fee pool held by Axiongov. As curators perform work, they are paid from this pool by Axiongov. The proposer has no visibility into curator payment and curators have no visibility into fee source — both see Axiongov as the counterparty. Any unspent balance at project completion returns to the proposer.

Why the proposer pays: The governance process is a service the proposer consumes — expert review, structured feedback, professional milestone oversight. It is not a cost the network should absorb indefinitely. This makes Axiongov self-funding from its first proposal and removes the dependency on treasury subsidies to bootstrap. As deployments mature and the connected chain has seen sustained value, the chain may choose through its own governance to absorb curator costs as a standing operational expense — at which point the submission fee becomes a smaller deposit covering Axiongov’s direct costs rather than full curator compensation. That transition is a sign of a healthy, proven deployment.

The Grant Flow: Treasury Pays the Project

After curator review and community approval, the connected chain’s treasury releases funds to the proposer in milestone-based tranches. Each tranche requires curator verification via Axiongov signal before release. A portion of each tranche is withheld into a pallet-held escrow buffer until it reaches one full milestone disbursement — see Section 3.3 for the full escrow mechanism. The grant flow is entirely separate from the governance flow: the treasury is paying for the project, not for the process of evaluating it.

Document Storage Flow

Every proposal requires documentation stored on Crust Network via Axiongov’s XCM integration. Axiongov submits the storage order to Crust at proposal submission and the transaction is atomic — if storage fails, the proposal does not go on-chain. There is no proposal without documented evidence. Storage costs are paid from the proposer’s submission fee pool. All documents are retained for 2 years after the project reaches terminal state (all milestones verified or abandonment declared). The on-chain content hash is permanent; Crust-backed availability is guaranteed for the retention period.

The proposer has an allowance for multiple document submissions over the project lifetime — updated specifications, supplementary evidence, milestone deliverables. Curator-generated documents (written assessments, Health Signal reasoning, milestone verification reports) are also stored through the same Crust integration and paid from the same proposal fee pool. Everything associated with a proposal is stored, linked by on-chain hash, and available for the full retention period.

The RFP Flow: Platform Pays

In a Request for Proposal, the connected chain initiates rather than the proposer. The issuing chain pays all costs: RFP documentation and storage, curator time evaluating responses, and the submission costs for proposers responding to the RFP. Responding to an RFP is free to the proposer. When a winning response transitions to the proposal stage and passes community vote, it enters the standard governance flow — milestone escrow, curator verification, Crust storage — but the submission fee for that transition is covered by the issuing chain. See Section 3.7 for the full RFP model.

Participation Signal Flow

Axiongov emits a ZK-attested, privacy-preserving participation signal for every verified vote. Connected platforms consume this signal and build their own reward logic on top — staking bonuses, forum reputation, DAO access, or any other incentive a platform chooses. The signal carries no vote direction or token holding information. Whether and how a platform acts on the signal is entirely that platform’s governance decision. Axiongov provides the verified data; platforms decide the reward.

The Self-Funding Arc

In early deployments, the submission fee funds the full governance cost. As the system matures and proves value, connected chains absorb ongoing curator costs as infrastructure investment — making Axiongov self-funding from a network perspective rather than a per-proposal cost to proposers. The transition is organic: it happens when the efficiency gains demonstrably exceed the costs, which the on-chain data makes measurable. See Section 3.6 for the self-funding model in detail.

3.2 Proposal Submission Fee & Document Storage

Every proposal entering the Axiongov system requires a submission fee paid upfront by the proposer. This fee is the proposer’s single payment covering all governance costs associated with their proposal from submission through project completion. It is not a deposit returned on approval — it is the cost of accessing professional governance infrastructure. What is not consumed by actual work returns to the proposer at the end.

Fee Calculation

The submission fee is calculated as a percentage of the requested grant amount, with a governance-configurable floor to prevent dust submissions:

The percentage model ensures the fee scales naturally with the work involved: a large proposal requires more curator time, more milestone verifications, more document storage, and more Health Signal iterations than a small one. The floor prevents the system from being used for trivial proposals where the curator cost would exceed the fee.

What the Fee Covers

The submission fee is held by Axiongov in a per-proposal pool and disbursed as work is performed:

• Document storage: Crust Network storage orders for all proposal documents at submission, plus an allowance for additional documents submitted over the project lifetime (updated specifications, supplementary evidence, milestone deliverables). Storage is retained for 2 years after project terminal state.
• Curator review costs: Curator time spent on proposal assessment, Health Signal updates with written reasoning, and written recommendation. Paid at VerificationRate for time spent, not as a flat fee — a proposal rejected in the first week costs less in curator time than one reviewed thoroughly over a full decision period.
• Milestone verification costs: Curator time verifying each deliverable submission throughout the project. Paid per milestone at VerificationRate as work is completed.
• Curator documentation storage: Crust storage for all curator-generated documents — written assessments, Health Signal reasoning, milestone verification reports. These are part of the governance record and must be stored with the same retention guarantee as the proposal documents themselves.
• Axiongov operational contribution: A small fixed percentage of the submission fee (Axiongov OperationalRate — governance-configurable) retained by Axiongov to cover signal computation, XCM transaction costs, and platform infrastructure. This is the only portion not subject to return.

Unspent Balance Return

When a project reaches terminal state — either all milestones verified and the retention period clock starts, or abandonment declared — pallet-milestone calculates the total governance costs incurred: curator work at verified time logs, storage orders placed, and the Axiongov operational contribution. The difference between the original submission fee and total costs is returned to the proposer.

A proposal that moves quickly through review, requires minimal back-and-forth, delivers cleanly on all milestones, and completes ahead of schedule will return a meaningful balance to the proposer. A proposal that requires extensive curator iteration, raises multiple Health Signal Concerns requiring resolution, or runs long on milestone verification will consume more of the fee. The proposer has every incentive to submit well-prepared proposals and deliver efficiently — not because of penalty, but because their own unspent balance depends on it.

Document Storage: The Atomic Requirement

No proposal can enter the Axiongov system without documentation. When a proposer submits, pallet-document initiates a Crust storage order via XCM before any other state is written. The submission extrinsic is atomic: if the Crust storage order is not confirmed, the entire transaction reverts. There is no on-chain proposal record without a corresponding stored document. There are no partial states, no proposals with missing documentation, no promises without evidence.

This is not a soft requirement enforced by front-end validation. It is a hard protocol constraint enforced at the pallet level. A proposer who attempts to submit without documentation cannot succeed — the transaction will fail regardless of which interface they are using.

The proposer uploads their full proposal document, budget breakdown, team credentials, and milestone specifications at submission. Over the project lifetime they may submit additional documents within their storage allowance: updated technical specifications, supplementary evidence, responses to curator concerns. Each additional document submission also goes through pallet-document and is stored on Crust with the same content-hash on-chain linkage.

Governance Parameters

• SubmissionFeeRate: Percentage of requested amount. Governance-configurable per deployment. Starting point for testing; expected to be refined based on observed proposal volumes and curator workloads.
• SubmissionFeeFloor: Minimum fee regardless of request size. Prevents spam and ensures small proposals still cover basic curator costs.
• Axiongov OperationalRate: Percentage of submission fee retained by Axiongov for infrastructure costs. Governance-configurable.
• StorageRetentionPeriod: Duration documents are retained after project terminal state. Default: 2 years. Governance-configurable per deployment.
• StorageAllowance: Maximum number of additional document submissions permitted over the project lifetime within the base fee. Proposals with high document volume may incur additional storage costs drawn from the fee pool.

3.3 Proposer Milestone Escrow

Two separate financial pools protect the network’s interests in every proposal. The submission fee pool (Section 3.2) is paid upfront by the proposer and covers governance costs — curator work, document storage, platform operations. The milestone escrow pool described here is withheld from the proposer’s approved grant during execution and protects the treasury against abandonment. They are funded differently, serve different purposes, and are managed by different pallets. A proposer who delivers everything receives every approved dollar from the grant; what they paid in submission fees is the cost of the governance process, not a deposit on the grant.

Milestone-based payments protect the treasury from large upfront losses, but a proposer who abandons after receiving their first tranche still imposes a real cost: curator time already spent on verification, and a funded milestone that delivered nothing. The Proposer Milestone Escrow closes this gap by requiring proposers to contribute to their own accountability from the moment funding begins.

The Core Mechanism

When a milestone tranche is approved and released, pallet-milestone withholds a portion and holds it in escrow rather than releasing it directly to the proposer. The withheld amount accumulates with each successive tranche until the escrow balance reaches EscrowTarget — one full milestone disbursement. Once the target is reached, subsequent tranches are released in full. At the final milestone, the proposer receives their final tranche plus the full accumulated escrow released back to them. Deliver everything, get everything.

A proposer who delivers everything receives their full approved amount. The escrow is not a penalty or a fee — it is a temporary hold that returns in full on successful completion. Its only cost to a good-faith proposer is the time value of the withheld amount during the project.

Loss Bounding on Abandonment

The escrow's function is to bound the treasury's maximum exposure on any proposal that is abandoned or fails to deliver. Without escrow, a proposer who disappears after milestone 1 has cost the treasury the full value of milestone 1 with no recourse. With escrow, the treasury holds a buffer that grows toward covering one full milestone:

• Abandonment after milestone 1: Treasury holds EscrowBuildRate × M. At 50%, the loss is bounded to half a milestone rather than a full one.
• Abandonment after milestone 2: Treasury holds EscrowTarget = M. The escrow covers the cost of the next milestone entirely — the treasury's net loss is zero on that milestone's funding.
• Abandonment at any later milestone: Escrow remains at EscrowTarget. Maximum treasury loss is always bounded to one milestone regardless of how far through the project the abandonment occurs.

Escrow Claim: What Happens When a Proposer Abandons

If a proposal is formally declared abandoned — either by the proposer, or by curator determination after a defined non-response period — pallet-milestone initiates the escrow claim sequence:

1. Curator verification costs paid first. Any curators who performed verified work on the abandoned milestone submit their time logs. Compensation at VerificationRate is paid out of the escrow balance first. This ensures curators are never left unpaid for work they completed in good faith on a project that subsequently abandoned.
2. Remainder returned to treasury. Whatever escrow balance remains after curator compensation is returned to the treasury. The community retains the recovered funds and can redeploy them.
3. Proposer reputation penalized. Abandonment triggers a reputation event on the proposer's on-chain record, affecting their eligibility for future funding. The severity scales with how far through the proposal the abandonment occurred and how much of the committed work was delivered before exit.

Governance Parameters

All escrow parameters are governance-configurable and can be adjusted based on observed proposal behaviour across deployment:

• EscrowBuildRate: Percentage withheld per tranche while building toward target. Default 50%, adjustable between 25-75%. Higher rates reach the target faster but reduce early proposer cash flow.
• EscrowTarget: The ceiling escrow accumulates toward. Default is one full milestone disbursement. Governance may adjust this to a fraction or multiple of a milestone for different track sizes.
• AbandonmentWindow: Days of non-response after a milestone submission deadline before curators can formally declare abandonment and trigger escrow claim.
• MinEscrowThreshold: Proposals below this total value may be exempted from escrow requirements, reducing friction for small grants where the administrative overhead outweighs the protection.

The escrow mechanism applies to all proposals by default. The community may introduce track-specific configurations as operational experience accumulates — for example, higher EscrowBuildRate for new proposers without a track record, or lower rates for teams with a demonstrated history of successful delivery.

3.4 Compensation Model

Hybrid Compensation Structure: Retainer + Performance Model

Curator compensation uses a hybrid model combining monthly retainers with performance-based bonuses. This structure provides income stability for professional curators while aligning incentives toward outcomes rather than time spent. The retainer covers base availability and proposal review work, while bonuses reward successful project outcomes and exceptional performance.

This model solves several problems inherent in pure hourly compensation: it prevents unlimited budget exposure, eliminates incentives to artificially extend review time, ensures predictable treasury costs, and shifts focus from activity metrics to outcome quality.

Monthly Retainer Structure

Curators receive modest monthly retainers based on their tier and capacity allocation. The retainer compensates them for maintaining availability, staying current with ecosystem developments, conducting proposal reviews within capacity limits, and providing advisory services. Retainers are intentionally sized as part-time compensation rather than full salaries, reflecting that curator work is expected to be 20-40 hours monthly rather than full-time employment.

The capacity point system allocates curator bandwidth appropriately. A Small Spender proposal might require 15-20 capacity points, a Medium Spender 25-30 points, a Big Spender 50-60 points, and a Treasurer track proposal 80-100 points. Curators accept proposals up to their capacity limit, ensuring they maintain quality rather than overextending.

This creates highly predictable base costs: total monthly retainer spend equals N_curators × Retainer(avg), making the budget a direct function of curator count and community-set rates. The retainer ensures curator availability and baseline engagement without creating excessive treasury burden. Actual amounts are governance-configurable and expected to be substantially lower than traditional consulting or full-time governance staff costs.

Milestone Verification: Universal Premium Rate

While proposal reviews are covered by retainers, milestone verification requires separate hourly compensation due to its unpredictable timing and variable complexity. Milestones arrive throughout the month based on project delivery schedules, and verification time ranges from 2 hours (simple deliverables like marketing reports) to 20+ hours (complex technical implementations requiring testing and validation).

All curators earn a flat governance-set rate (VerificationRate) for milestone verification work, regardless of tier. This universal premium rate reflects several important considerations:

• Equal Value of Verification Work: The time and effort required to properly verify deliverables is equally valuable regardless of curator reputation. A Junior Curator spending 10 hours thoroughly testing a technical implementation provides the same verification service as a Senior Curator doing the same work.
• Premium for Real Work: Milestone verification is the most concrete, valuable work curators perform. Unlike proposal review (which is advisory), verification directly gates treasury fund release. This deserves premium compensation.
• Incentive Alignment: The flat rate prevents tier-based distortions. Junior Curators are incentivized to take on verification work (good learning and income), while Expert Curators don't avoid it despite lower hourly equivalent versus their retainer value.
• Simplicity: A single rate is easier to understand, implement, and audit than tier-based rates. Reduces complexity in the compensation system.

Milestone verification is capped at 40 hours per curator per month to prevent excessive costs and ensure reasonable workload distribution. The curator dashboard tracks verification time with 5-minute idle detection and 10-minute auto-pause for inactivity, preventing gaming while accommodating legitimate verification activities like reading documentation, testing implementations, or analyzing metrics.

Monthly caps on verification hours protect against budget overruns. If curators consistently hit their caps, this signals demand for additional curator authorization to handle verification workload. At the cap, a single curator can earn up to MaxVerificationHours × VerificationRate per month in verification fees alone, providing substantial income opportunity for engaged curators willing to do the detailed verification work.

Performance Bonuses

Performance bonuses reward curators for accurate judgment and successful project outcomes, creating powerful incentives beyond base compensation:

• Project Success Bonus: When an approved project successfully completes all milestones as promised, the curator receives SuccessBonus(track) — a governance-configured amount scaled to proposal track complexity
• Exceptional Outcome Bonus: Projects that significantly exceed expectations (2x impact vs. promised, major ecosystem adoption, technical breakthroughs) trigger 50-100% bonus multipliers
• Accuracy Bonus: Quarterly bonuses for curators maintaining 80%+ success prediction rates on their approved projects
• Satisfaction Bonus: Curators receiving consistently high ratings from proposers (>8/10 average) receive quarterly bonuses of SatisfactionBonus — a governance-configured amount
• Reputation Maintenance Bonus: Annual bonuses for curators who maintain or improve their tier throughout the year

These bonuses align curator incentives with network outcomes. Curators succeed financially by making accurate assessments that lead to successful projects, not by maximizing proposal volume or review time. A curator who approves fewer proposals but achieves higher success rates earns more through bonuses than one who approves many proposals that fail.

Penalty Structure

While bonuses reward success, severe penalties create accountability for poor performance and enforce high standards:

• Failed Project Penalties: When approved projects fail to deliver, curators face reputation penalties scaled to the damage: -1 to -5 points for small failures, -10 to -15 points for medium failures, -20 to -25 points for catastrophic failures. These penalties can drop curators multiple tiers (Senior to Junior or below), resulting in 30-50% compensation reduction and loss of influence.
• Disputed Milestone Penalties: Milestone verifications that are successfully contested result in -5 point reputation penalties. Curators who consistently approve incomplete or fraudulent milestones face compounding penalties that quickly eliminate their standing.
• Minority Position Penalties: Being wrong in minority positions (rejecting proposals that succeed, or being lone approver of failures) results in -2 points per occurrence. This prevents curators from either playing too conservatively or ignoring consensus without strong justification.
• Conflict of Interest Violations: Undisclosed conflicts result in -20 to -50 point reputation penalties depending on severity. A -30 point penalty can drop an Expert Curator to Junior status or remove marginal curators entirely. These violations represent fundamental breaches of trust that warrant career-ending consequences.
• Malicious Behavior: Provable collusion, vote buying, fraud, or intentional sabotage results in immediate removal from curator status, reputation reset to zero, and potential financial slashing if bonds are implemented. There is no path back from malicious behavior.

Curator Status Management: Pause and Challenge Mechanisms

Curators need flexibility to manage their availability and the ability to contest reputation changes they believe are unfair. The system includes two critical mechanisms to address these needs:

Pause Status: Curators can voluntarily pause their curator status at any time for any reason (personal circumstances, professional conflicts, extended travel, health issues, temporary lack of capacity). During pause status:

• No new proposals are assigned to the curator
• Monthly retainer payments cease immediately
• Existing proposal reviews must be completed or reassigned before pause becomes effective
• Reputation score is frozen and does not change (no gains or losses during pause period)
• Curator capacity allocation is temporarily removed from the available pool
• Pause status is publicly visible on curator profiles
• No time limits on pause duration (can be days, months, or indefinite)
• Reactivation is immediate upon curator request (no waiting period or reapproval needed)

This mechanism prevents unfair reputation damage when curators cannot maintain engagement due to legitimate life circumstances. A curator dealing with family emergency or career transition can pause without penalty, then resume when ready. The system recognizes that life happens and accommodates it gracefully.

Reputation Challenge Process: Curators can formally challenge any reputation penalty they believe was incorrectly applied. The challenge process works as follows:

1. Challenge Submission: Curator submits formal challenge through the curator dashboard, specifying which reputation change is contested and providing detailed justification with supporting evidence
2. Challenge Review Panel: A randomly selected panel of 3 other curators (excluding those involved in the original decision) reviews the challenge. Panel must include at least one curator from same tier or higher as challenger
3. Evidence Consideration: Panel reviews original proposal/milestone documentation, curator's review and reasoning, project outcomes, and any mitigating circumstances
4. Decision Timeline: Panel has 14 days to reach majority decision (2 of 3 curators). If no decision within 14 days, challenge automatically escalates to community vote
5. Possible Outcomes:
   • Challenge Upheld: Reputation penalty reversed or reduced; curator reputation restored proportionally
   • Challenge Partial: Reputation penalty reduced but not eliminated (e.g., -20 points reduced to -10 points)
   • Challenge Rejected: Original reputation penalty stands; curator may lose additional -1 point for frivolous challenge if panel determines challenge had no merit
6. Appeal Option: If challenge is rejected and curator believes panel decision was unfair, they can appeal to community governance through OpenGov referendum (requires deposit, refunded if appeal succeeds)

Valid grounds for reputation challenges include: project failure due to external circumstances beyond curator or proposer control (regulatory changes, market collapse, ecosystem-wide technical issues), incomplete or misleading proposal information that curator could not reasonably detect, proposer fraud or misrepresentation that was sophisticated enough to deceive expert review, force majeure events affecting project delivery, or procedural errors in reputation calculation.

The challenge mechanism protects curators from unfair reputation damage while discouraging frivolous appeals through the potential -1 point penalty for clearly meritless challenges. It balances accountability with fairness, recognizing that even expert judgment cannot predict all outcomes and that some failures are legitimately unforeseeable.

3.5 Incentive Alignment

The system succeeds only if all participants are incentivized toward the same goal: treasury funds deployed to high-quality projects that deliver promised outcomes.

Curator Incentives

• Short-term: Earn stable monthly retainer for professional review work within capacity
• Medium-term: Build reputation to access higher tiers with increased retainers (Retainer(Junior) to Retainer(Expert) progression); earn premium VerificationRate for milestone verification work
• Long-term: Earn substantial performance bonuses for successful project outcomes; maintain reputation to sustain curator career
• Perverse incentive mitigation: Cannot maximize earnings by dragging out reviews (retainer pays same regardless); cannot approve everything (reputation destroyed by failures); cannot reject everything (reputation damaged by missed opportunities); income tied to accuracy and outcomes

DAO Curator Incentives

• Short-term: Receive scaled monthly retainers for contributing collective domain signals across proposals in their area of expertise
• Medium-term: Build organizational reputation to access larger capacity and higher compensation tiers
• Long-term: Establish DAO as recognized expert authority in domain; earn substantial bonuses for portfolio success
• Perverse incentive mitigation: Collective reputation means all members suffer from poor decisions; internal governance creates peer accountability; multidisciplinary review catches issues individual bias might miss; ZK credentials prevent credential fraud

Active Voter Incentives

• Short-term: Earn platform-specific rewards for consistent voting participation — on Polkadot/Kusama this could include enhanced staking returns if the chain adopts the model through its own governance; on other connected platforms this may include forum privileges, DAO access, early auction rights, or other platform-defined incentives. All rewards are driven by the Axiongov participation signal, which provides the verified data. What platforms do with it is their decision.
• Medium-term: Build voter reputation through accurate judgment; tier advancement unlocks higher ParticipationSignal tier, enabling access to richer platform rewards
• Long-term: Voter reputation qualifies candidates for curator positions; become recognized governance expert with career opportunities
• Perverse incentive mitigation: Cannot game rewards through random voting (outcome alignment required); must maintain participation over months (no short-term farming); discussion quality matters for higher tiers

Delegator Incentives

• Short-term: On chains that adopt the model, could earn enhanced staking returns (up to MaxGovernanceBonus combined with any active voting bonuses) for delegation — subject to the connected chain's governance decision
• Medium-term: Build delegator reputation for better returns and ecosystem privileges
• Long-term: Benefit from better governance outcomes (higher network value, better treasury efficiency)
• Perverse incentive mitigation: Random delegation to low-quality curators yields poor outcomes and no reputation gain; must actively select good curators

Proposer Incentives

• Short-term: Receive professional feedback to improve proposals before community vote
• Medium-term: Build track record of successful delivery for easier future funding
• Long-term: Access to milestone-based funding provides working capital for ongoing projects
• Perverse incentive mitigation: Cannot game the system by submitting low-effort proposals (curators reject); must deliver on promises (reputation tracks outcomes)

Token Holder Incentives

• Short-term: Delegate to high-quality curators rather than reading every proposal personally
• Medium-term: On chains that adopt the participation signal reward model, benefit from enhanced staking returns; on all chains, benefit from better governance decisions that improve long-term network value
• Long-term: Network value increases from efficient treasury deployment and successful projects
• Perverse incentive mitigation: Passive non-participation yields lower returns; must engage with delegation for optimal outcome

Curator Insurance Bond

All curators must post a bond when authorized. The design principle is straightforward: a curator's bond must be meaningfully proportional to the blast radius of the proposals they approve. A flat tier-based bond disconnected from actual proposal value is a formality, not accountability. OpenGov 2.0 combines a baseline bond (proving commitment to the role) with a per-proposal bond top-up (proportional to funds at risk) and a collective liability mechanism (distributing accountability across the assigned panel).

Bond denomination: Bonds are held in stablecoins or in the same currency the proposal is denominated in — not exclusively in DOT. This removes price-volatility risk from the bond’s protective function: a bond worth $10,000 today should still be worth $10,000 when called, regardless of market conditions. For DOT-denominated proposals, bonds are held in DOT. For stablecoin-denominated proposals, bonds are held in the relevant stablecoin. The denomination is set at assignment time and locked for the duration of the proposal. All bond amounts remain governance-configurable per deployment.

Bond sizing: The per-proposal top-up is capped at approximately half one milestone disbursement (BondCap = 0.5 × MilestoneValue). This makes participation viable — requiring five curators to collectively post the full value of a large proposal would kill curator supply — while still creating meaningful accountability. Larger proposals require larger panels, distributing the bond requirement across more participants and scaling total coverage proportionally.

Baseline Bond by Tier

The baseline bond establishes a curator's authorization and reflects the track complexity they are cleared to handle. It is held in escrow for the duration of their active status and earns standard staking returns.

Large Strategic Proposals: Advisory Board Engagement

Proposals above LargeStrategicThreshold — typically multi-year, multi-million dollar ecosystem investments — represent a qualitatively different governance challenge. A curator who reviews a proposal in three weeks and verifies milestones quarterly is not sufficient oversight for a project that spans three years and involves ongoing architectural decisions. For these proposals, Expert Curators take on an advisory board posture rather than an auditor role.

In advisory board mode, assigned curators are actively involved in steering the project throughout its lifecycle. This includes:

• Pre-proposal development: Work with the proposing team during proposal design to stress-test scope, timeline, and milestone structure before submission. A well-designed proposal from this process is more likely to pass and more likely to succeed.
• Quarterly steering check-ins: Structured reviews beyond milestone verification — assessing project trajectory, flagging scope drift, connecting the team with relevant ecosystem resources or partners, and providing strategic guidance between formal milestones.
• Milestone co-design: Advisory curators help the team define what success looks like at each milestone, not just verify it after the fact. This reduces disputes and improves milestone quality.
• Network access: Expert Curators with deep domain expertise bring their professional networks to the project — connecting teams with technical talent, potential partners, or domain experts as needed throughout the engagement.
• Escalation authority: Advisory curators can escalate concerns to the broader community before a milestone is formally submitted, rather than waiting for failure to trigger a penalty. Early flagging is encouraged and carries no reputation cost.

The accountability asymmetry for large strategic proposals is significant: a failed multi-year project that wastes millions in treasury funds would be catastrophic for the curators who approved it. Expert Curators taking on advisory board roles for proposals above LargeStrategicThreshold have so much reputation and bond exposure on the line that failure would effectively end their curator careers. This asymmetry is the mechanism — it ensures only curators who genuinely believe in a project's mission alignment and executability will accept advisory board roles for strategic proposals.

Per-Proposal Bond Top-Up

When a curator accepts assignment to a specific proposal, pallet-curator computes an additional bond requirement proportional to that proposal's total value and the number of curators sharing the assignment:

This means a Junior Curator cannot be assigned to a 500K DOT proposal simply because one is available. Their bond capacity constrains the proposal size they can meaningfully cover. Larger proposals naturally require either higher-tier curators with larger baseline bonds, or a larger curator panel that distributes the per-proposal requirement across more participants.

Collective Liability: The Curator Panel Guarantee

Individual bonds alone create a gap: a curator whose bond is fully slashed may still leave the treasury under-recovered if the proposal value dwarfed their coverage. OpenGov 2.0 addresses this through collective liability across the curator panel assigned to each proposal.

When a governance-confirmed breach occurs — fraud, collusion, or gross negligence resulting in treasury loss — the recovery sequence operates as follows:

1. Primary slash: The responsible curator's bond is slashed first, up to 100%, with proceeds returned to the treasury.
2. Coverage gap assessment: pallet-curator computes the remaining unrecovered loss: Gap = VerifiedLoss − PrimarySlash.
3. Panel call: If Gap > 0, the remaining curators assigned to that proposal are issued a collective liability call, proportional to their share of the original panel. Each curator has a governance-set window (CollectiveCallWindow) to contribute their share voluntarily.
4. Secondary slash: Any curator who does not contribute within the window has their pro-rata share slashed automatically from their held bond.
5. Reputation consequence: Curators who are secondarily slashed — even if not personally responsible for the breach — receive a reputation penalty for failing to exercise sufficient oversight over a co-assigned proposal. The penalty is smaller than for the primary offender but real.

Bond Mechanics

• Staking Compatible: Both baseline and top-up bonds remain staked and continue earning staking rewards. Curators do not lose yield by bonding more.
• Assignment Confirmation: pallet-curator locks the per-proposal top-up at assignment time. The curator cannot withdraw or reassign those funds until the proposal reaches a terminal state (all milestones resolved, or proposal abandoned).
• Slashing Conditions: Primary slash applies to gross negligence or malicious behavior: approving obvious fraud, proven collusion, intentionally falsified milestone verification, or coordinated misconduct. Secondary slash (collective liability) applies when the panel gap recovery is triggered and a curator fails to contribute within CollectiveCallWindow.
• Slashing Process: Primary slash requires either unanimous vote from a 5-curator review panel drawn from curators not assigned to the affected proposal, or an OpenGov referendum. Secondary slash is automatic on-chain once the window expires, with no additional vote required — the collective liability was accepted as a condition of assignment.
• Bond Return: Baseline bond is returned after a 90-day waiting period following retirement or indefinite pause. Per-proposal top-ups are returned (or released from lock) as each proposal reaches a terminal state, provided no slash event is pending.
• Tier Advancement: Curators advancing tiers have 30 days to post the additional baseline bond for the new tier. During this window they continue operating at their current tier.

DAO Curator Bonds

DAO curators face the same two-layer bond structure. The baseline bond is collective (DAOBond(tier, size)), contributed proportionally by members or through the DAO treasury. The per-proposal top-up is computed identically against the DAO's assigned share of the proposal value. Collective liability calls are directed to the DAO entity; internal distribution of the call among members is governed by the DAO's own rules. A DAO that cannot meet a collective liability call within CollectiveCallWindow faces the same secondary slash and reputation consequence as an individual curator.

The overall penalty structure makes curator status a high-stakes responsibility rather than a sinecure. Curators cannot simply collect retainers indefinitely while making poor decisions. The system is self-correcting through economic consequences: bad curators lose tier status (reducing compensation), lose capacity allocation (reducing work opportunities), and eventually lose curator status entirely if reputation falls below 25 points. The severity is calibrated to ensure that one major mistake significantly damages reputation, while two to three major mistakes within a year will likely end a curator's career. This creates the appropriate level of care and diligence expected when managing millions of DOT in treasury decisions.

3.6 Self-Funding Dynamics

The ultimate test of OpenGov 2.0's economic design is whether it becomes self-sustaining through demonstrated value creation rather than requiring ongoing subsidization.

Efficiency Gains

Treasury efficiency improvements from curator oversight include:

1. Pre-funding filtering: Rejecting proposals before funds are allocated prevents waste entirely
2. Milestone discipline: Releasing funds incrementally based on verified delivery stops failing projects earlier
3. Quality feedback: Helping proposers improve plans before submission increases success rates
4. Coordination: Identifying overlaps and synergies across proposals reduces duplication
5. Expertise matching: Connecting proposers with appropriate curators improves domain-specific evaluation

If these mechanisms collectively improve treasury ROI by even 10-15%, the system pays for itself multiple times over. At any meaningful treasury spending rate, even a 10-15% efficiency improvement generates savings that dwarf curator compensation costs — the exact crossover point is a function of TreasurySpend_annual and the community-set compensation parameters.

Network Value Creation

Beyond direct treasury efficiency, successful projects funded through OpenGov 2.0 create ecosystem value that accrues to all token holders. A well-curated portfolio of treasury investments should generate:

• Increased developer activity and parachain deployments
• Better public perception and mainstream adoption
• Technical innovations that improve network capabilities
• Marketing and education that grows the user base
• Successful businesses built on Polkadot that validate the platform

These effects compound over time. Each successful treasury-funded project becomes a case study attracting more builders. Better governance outcomes improve network reputation, attracting more capital and talent. The virtuous cycle becomes self-reinforcing.

4. Implementation Roadmap

4.1 Phased Approach

OpenGov 2.0 will be implemented over 24-36 months through five distinct phases, each building on demonstrated success from the previous phase. This approach minimizes risk, enables learning and adjustment, and builds community confidence through evidence rather than promises.

Phase 0: Foundation (3-4 months)

The foundation phase designs the complete system without deploying any on-chain components. Deliverables include detailed curator program specifications, economic modeling, UI/UX design for curator interfaces, integration architecture with existing OpenGov infrastructure, and a comprehensive proposal for Phase 1 pilot. Budget range accounts for team composition (solo vs. small team), depth of economic modeling required, complexity of UI/UX design work, and extent of community consultation during design phase.

This phase is distinct from other initiatives and focuses purely on designing the OpenGov 2.0 curator infrastructure. The work involves governance system design, mechanism design, interface design, and economic modeling specific to professional curation systems.

Phase 1: Pilot Launch (6 months)

The pilot begins with 5-8 curators operating on Small Spender and Medium Spender tracks only. These tracks involve 10K-100K DOT proposals, providing meaningful data without risking catastrophic failure. Curators receive modest monthly retainers (Retainer(tier)) plus VerificationRate for milestone verification work. The minimal viable interface is web-based and manually operated. Final budget depends on curator count, actual milestone verification volume, and development costs for the pilot interface.

Success metrics include: 20%+ higher completion rates for curator-reviewed proposals, curator feedback cited in 50%+ of community votes, zero curator misconduct, and satisfaction scores above 7/10 from both proposers and token holders. After six months, comprehensive results are presented to the community through OpenGov for a continue/iterate/abandon decision.

Phase 2: Scale & Incentivize (6-9 months)

Upon successful pilot completion, Phase 2 expands to Big Spender and Treasurer tracks (up to 10M DOT), increases individual curator count to 12-15, implements automated on-chain reputation tracking, and introduces delegation incentives (governance-configured staking boost per track). The curator interface becomes fully functional with workflow management and reputation display.

Critical Addition: First DAO Curators. Phase 2 authorizes 2-3 pilot DAO curators as domain signal contributors (likely Technical Infrastructure and Marketing & Growth). These DAOs prove the collective curation model while individual curators continue handling general tracks. Domain signal weights are configured experimentally to test how specialized curation improves governance outcomes. Budget range reflects uncertainty in DAO curator compensation structures, technical development costs for reputation system, and actual proposal/milestone volume.

This phase introduces retrospective accountability where curator reputation adjusts based on actual project outcomes. Success metrics include: 25%+ delegation rate, 30% improvement in treasury efficiency, and emergence of high-reputation curators with 80%+ success prediction rates.

Phase 3: Advanced Features & Domain Coverage (6-12 months)

Phase 3 implements full domain curation coverage with 5-6 specialized DAO curators contributing expert signals across all major proposal categories. Individual curators continue operating but increasingly specialize within their domains. Administrative tracks (Staking Admin, Fellowship Admin, etc.) receive curator oversight. Zero-Knowledge credential proofs become fully operational for both individual and DAO curators. Delegation bonus levels (up to MaxGovernanceBonus) are available to connected chains that have adopted the reward model through their own governance, and specialized curator types mature across all domains. Budget range accounts for ZK infrastructure development costs, additional DAO curator authorization, potential runtime upgrades, and increasing proposal volume requiring more curator capacity.

Success metrics include: 50%+ delegation rate, self-funding status achieved (efficiency gains exceed curator costs), and 10+ curators operating with ZK-proven credentials.

Phase 4: Full Integration (Ongoing, Self-Sustaining)

The final phase extends curator oversight to highest-privilege tracks including Root and Whitelisted Caller, requires Technical Fellowship + Curator approval for runtime changes, enables maximum delegation incentive levels (up to +1% APY on chains that have adopted the reward model through their own governance, combined with any active voting bonuses), and establishes curator reputation as standard governance infrastructure. The model exports to parachains as reusable governance modules. Both individual curators and DAO curators from across the ecosystem contribute signals competitively across all domains, with signal quality and reputation determining influence.

At maturity, the majority of voting power is actively delegated or voting directly, a community-approved cohort of individual curators plus DAO curators from across the ecosystem contribute domain signals, project success rates significantly exceed baseline, and Polkadot governance is recognized as the industry gold standard for decentralized decision-making at scale. Annual operating costs are expected to be fully offset by treasury efficiency gains, making the system self-sustaining rather than an ongoing budget burden.

4.2 Risk Mitigation

Each implementation phase includes specific risk mitigation strategies addressing the most likely failure modes.

Centralization Risk

Risk: Curators become gatekeepers who control access to treasury funding, undermining decentralization.

Mitigation: Curators provide recommendations but cannot block proposals from community votes. Token holders retain ultimate authority. Multiple curators per track prevent single points of control. Curator selection and removal both require OpenGov votes. Reputation system creates accountability without requiring trust.

Collusion Risk

Risk: Curators collude with proposers or each other to approve low-quality proposals in exchange for kickbacks, including through sophisticated long-term social engineering campaigns.

Mitigation: Retrospective reputation penalties make collusion expensive (short-term gains, long-term career destruction). Public reviews create transparency. Anomaly detection in pallet-signal identifies suspicious patterns — a curator consistently approving a specific proposer faster than peers, or multiple curators showing correlated approval behavior beyond statistical baseline. Slashing mechanisms punish provable collusion with reputation destruction and financial penalties. For advanced persistent threats including state-actor infiltration, see Section 4.3.

Capture Risk

Risk: Wealthy token holders capture curator positions to serve their interests rather than the network.

Mitigation: Curator selection requires OpenGov voting, so capture would require controlling community votes (same difficulty as current system). Reputation system means captured curators who serve narrow interests will lose standing when their decisions produce poor outcomes. ZK credentials enable merit-based curation without plutocratic requirements.

Scaling Risk

Risk: System becomes bottleneck as proposal volume increases, slowing governance.

Mitigation: Curator capacity scales horizontally (add more curators). Market signals (queue length, curator capacity utilization) trigger authorization of additional curators. No hard constraints on curator count. Fast-track mechanisms for time-sensitive proposals.

Economic Risk

Risk: Curator costs exceed efficiency gains, making system unsustainable.

Mitigation: Phased approach proves economic viability before major investment. Detailed metrics track treasury efficiency, project success rates, and ROI at each phase. Community can defund curator program if economics do not materialize. Conservative estimates show breakeven at 10-15% efficiency improvement, well below reasonable expectations.

4.3 State-Actor and Advanced Social Engineering Threat Model

The cryptocurrency ecosystem faces a threat that conventional security frameworks were not designed to address: state-sponsored actors with multi-year time horizons, professional operational security, and nation-scale resources. The April 2026 Drift Protocol breach — in which North Korean group UNC4736 spent six months posing as a quantitative trading firm before draining $285M in under a minute using a durable nonce attack — is not an outlier. It is the current standard of the threat. Similar operations have targeted Bybit ($1.5B, February 2025), Radiant Capital, and over 40 DeFi platforms where embedded IT workers provided persistent insider access.

This threat will not go away. North Korea has stolen an estimated $6.75 billion in cryptocurrency since 2017, with 2025 setting a new annual record at $2.02 billion — a 51% year-over-year increase. Traditional deterrents do not apply to a sanctions-isolated state funding weapons programs. The asymmetry is structural: attackers need to succeed once; defenders need to succeed every time. The honest response is not to claim immunity but to make the attack dramatically more expensive and the blast radius dramatically smaller. OpenGov 2.0 was not designed specifically as a counter-intelligence system, but its architecture contains properties that naturally resist this threat class — and can be deliberately strengthened.

Structural Protections Already in the Design

Several properties of the curator system make the Drift-style playbook substantially harder to execute, even without modifications.

Milestone-gated tranches eliminate the single unlock event. The Drift attack worked because six months of trust-building was enough to obtain the multisig approvals needed to empty an entire vault in one transaction. In OpenGov 2.0, no single approval event unlocks the treasury. Each milestone tranche requires fresh curator verification, and approval of one tranche does not pre-authorize subsequent ones. An attacker who compromises one curator can at most release one tranche — which immediately creates an on-chain event visible to the community.

Independent multi-curator approval prevents single-point compromise. Proposals require quorum across independently selected curators who do not share a social surface. A DPRK operative who cultivates one curator over six months still cannot reach approval threshold alone. They would need to simultaneously compromise multiple independent parties, each with financial and reputational skin in the game, without any of them noticing the coordinated pressure.

Retrospective reputation penalties make infiltration economically costly. A state actor who builds a legitimate curator identity over 18 months and then approves a malicious proposal faces immediate bond slashing, permanent on-chain reputation destruction, and identity flagging. Unlike a traditional hack where the attacker disappears, the curator identity used in the attack is burned permanently. Building a new identity requires starting the reputation climb from zero under increased scrutiny.

On-chain history creates a permanent audit trail. Every curator decision, every milestone approval, every reputation change is recorded on-chain with timestamps. This creates retrospective forensics capability that simply does not exist in multisig-based systems. When Drift was attacked, the investigation required weeks of off-chain research. In OpenGov 2.0, the full decision history is queryable from genesis.

Deliberate Hardening: Trip Wires Built into the System

Beyond the structural properties above, several concrete mechanisms can be added or enforced to specifically address state-actor infiltration.

Quorum-plus-delay for large tranches. Above a governance-configurable threshold (LargeTrancheThreshold), milestone approvals enforce a mandatory execution delay (MinExecutionDelay) between approval quorum and fund release. This is enforced natively in pallet-milestone: the extrinsic sets a release_at block rather than releasing immediately. The delay gives the community a window to raise a dispute, review the approval, or trigger an emergency pause if something looks wrong. The Drift attack executed in under a minute after obtaining approvals. A 48-72 hour delay makes that specific playbook impossible.

Proposer entity verification separate from curator ZK credentials. ZK credentials appropriately protect individual curator privacy. Proposers, however, should face the opposite requirement — stronger, not weaker, identity verification for large proposals. A proposer claiming to be a professional trading firm or investment entity (exactly the Drift attack vector) should demonstrate on-chain history: minimum account age, prior verified activity, and ideally a track record of smaller successfully completed proposals. pallet-curator can enforce a ProposerMinimumHistory requirement for proposals above LargeTrancheThreshold. A freshly created front company presenting at a conference fails this check automatically.

Curator device isolation as a tiered protocol requirement. Any curator whose verification work involves opening files or running code supplied by proposers is a potential target for the "open this folder" attack class — the exact vector used in the Drift compromise. The instinctive answer is to use containers (Docker, Podman) for document review. Containers are better than nothing: they provide filesystem separation and process isolation that stops most common malware. But they are not sufficient against this threat class. DPRK tooling is specifically engineered to escape common sandboxing. Containers share the host kernel, meaning a kernel-level exploit — which nation-state actors actively develop and hoard — breaks container isolation entirely. Mounted volumes needed to actually view documents create a shared surface between container and host. And misconfigured container privileges (--privileged, mounted Docker sockets, SYS_ADMIN capabilities) are common in practice and make the boundary meaningless.

The critical architectural principle is that the signing path and the document review path must never share the same execution environment. A container running on the same host as your signing keys does not achieve that separation. The isolation must be at the machine boundary, not the filesystem boundary.

OpenGov 2.0 enforces a tiered isolation requirement scaled to proposal size, documented in curator onboarding and enforced as a condition of curator authorization:

• Standard proposals (below LargeTrancheThreshold): A hardened container is the minimum acceptable bar — read-only mounts, no shared volumes with the signing environment, network disabled during document review, run as non-root, no privileged flags. The container must be destroyed and recreated between review sessions, never reused across proposers.
• Large proposals (above LargeTrancheThreshold): A dedicated virtual machine (KVM, QEMU, or equivalent) with no shared folders, no clipboard sharing, and no network access to the signing environment. The VM is spun up from a clean snapshot for each review session and restored to snapshot after. A hypervisor escape is substantially harder than a container escape, and the clean-snapshot discipline means any compromise is contained to that session.
• Treasurer and Root track proposals: A physically separate device used exclusively for document review — no signing keys, no wallet software, no connection to any machine that holds key material. The approval signature is generated on a separate hardware device (hardware wallet or dedicated signing machine) that has never touched proposer-supplied content. This mirrors the operational security standard used by hardware wallet manufacturers for their own internal key operations.

This is an operational security requirement, not a pallet-level constraint. pallet-milestone cannot verify what machine a curator used. What it can enforce is that curators acknowledge this requirement on-chain as part of their authorization, and that violation — if demonstrated — constitutes grounds for bond slashing under the misconduct provisions.

Correlated behavior detection in pallet-signal. The signal computation engine already aggregates curator decisions across proposals. It can additionally compute a CuratorCorrelationScore: if curator A and curator B are approving the same proposers significantly faster than peer curators, or agreeing with each other beyond a statistical baseline across a shared proposal set, pallet-signal surfaces this as an anomaly flag. This does not penalize curators who genuinely agree — it flags statistical outliers for human review. A DPRK team operating two embedded curators in coordination would show exactly this pattern.

Velocity limits on reputation-building for new curators. The graduated capacity unlock already exists in the design. It can be extended to cap the rate at which a new curator can advance tiers regardless of successful decisions — a minimum time-in-tier requirement alongside the decision count. This prevents a well-resourced actor from rapidly manufacturing reputation through a burst of carefully orchestrated approvals. Legitimate curators are not harmed by this; state actors trying to reach Expert tier quickly are.

Emergency circuit breaker. pallet-milestone should include a governance-callable pause_all_releases extrinsic requiring a low-threshold OpenGov vote (Small Tipper track or equivalent). This is distinct from the existing curator pause mechanism — it halts all pending fund releases network-wide for a governance-configurable window while an incident is investigated. Cost of triggering: low. Cost of a successful attack continuing during an investigation window: potentially catastrophic. The asymmetry favors having the brake.

What This Architecture Cannot Prevent

Honesty about limitations matters. A sufficiently patient state actor willing to build genuine curator reputation over years, operate without raising anomaly flags, and act only once when the ROI justifies it represents a threat no governance architecture fully eliminates. The fundamental asymmetry of that scenario does not disappear.

What the architecture above does is raise the cost of the attack dramatically, compress the blast radius when one succeeds, and create enough observable trip wires that a compromise is likely detected and interrupted before execution. A DPRK operation against Drift cost six months of work and returned $285M in a single transaction from a unified vault. The same operation against a mature OpenGov 2.0 deployment would require compromising multiple independent curators simultaneously, defeating the execution delay, bypassing proposer history requirements, operating without triggering correlation anomalies, and still being limited to one milestone tranche — a fraction of total treasury value. The expected return per unit of operational effort is substantially lower, which is the most durable deterrent available to a governance system.

4.4 Success Metrics

Each phase defines specific, measurable success criteria that must be met before proceeding to the next phase. This data-driven approach ensures the community can make informed decisions about continued investment.

Participation Metrics

• Delegation rate: Percentage of circulating supply actively delegated to curators
• Active curator count: Number of curators meeting minimum activity and reputation thresholds
• Proposal review rate: Percentage of eligible proposals receiving curator review
• Community engagement: Comments, discussions, and votes influenced by curator feedback

Quality Metrics

• Project success rate: Percentage of funded projects completing milestones as promised
• Milestone approval rate: First-submission approval percentage (higher is better, indicates clear requirements)
• Dispute rate: Percentage of milestone verifications contested (lower is better)
• Curator accuracy: Correlation between curator recommendations and actual outcomes

Economic Metrics

• Treasury efficiency: Value delivered per DOT allocated (compared to baseline)
• Curator cost ratio: Total curator compensation as percentage of treasury spend
• ROI calculation: Efficiency gains divided by curator costs
• Failed project costs: DOT wasted on projects that do not deliver (should decrease)

Satisfaction Metrics

• Proposer satisfaction: Survey scores from funded projects about curator process
• Delegator satisfaction: Survey scores from token holders about governance experience
• Community sentiment: Polkassembly discussions, governance forum feedback, social media analysis

5. Technical Architecture

5.0 What Exists Today

OpenGov 2.0 is not a whitepaper waiting to be built. A working implementation already exists. The following components are live as of April 2026.

Six Custom FRAME Pallets

The core logic lives in six purpose-built Substrate pallets, each with its own storage, extrinsics, and events:

pallet-curator manages curator identity, authorization, tier assignment, capacity tracking, and status transitions. Community-authorized via OpenGov Root origin; curators self-manage pause and resume.

pallet-reputation tracks on-chain reputation scores for curators and active voters. Every delta is recorded with source, reason, and block number. Scores are bounded unsigned integers that saturate at zero and cannot underflow.

pallet-milestone manages the full milestone lifecycle from proposer submission through curator verification, dispute panel formation, and outcome recording. Deliverable evidence is stored as Crust IPFS hashes; the pallet enforces that no milestone can be approved without a verified hash on record.

pallet-allocation implements the quadratic funding score computation and conviction vote weight normalization that feed the signal engine. All math uses integer arithmetic with u128 intermediate values; no floating point enters the runtime.

pallet-signal is the Axiongov signal engine. It aggregates curator scores, QF outputs, and on-chain activity into a composite allocation signal and emits signed signal events. It has zero connection to any balance or treasury pallet; it emits recommendations, never authorizes payments.

pallet-document manages all proposal and governance documentation. At proposal submission it initiates a Crust Network storage order via XCM, waits for confirmation, and writes the content hash and CID to on-chain storage only after Crust confirms. The submission extrinsic is atomic: no Crust confirmation means no on-chain record. The pallet tracks document metadata (proposal ID, document type, CID, submission block, retention expiry), manages the per-proposal storage allowance for additional submissions over the project lifetime, and enforces the 2-year post-completion retention period. It also manages storage orders for curator-generated documents — assessments, Health Signal reasoning, milestone verification reports — ensuring every governance action has a corresponding retrievable document.

Test Coverage

The pallet library has 159 passing unit tests across all five pallets. Every extrinsic has a happy-path test and at least one failure-path test covering wrong origin, out-of-bounds inputs, and invalid state transitions. The reputation delta table is fully covered. Each pallet runs against its own minimal mock runtime using frame_support::construct_runtime!.

Live Axiongov Runtime

The Axiongov runtime composes all five pallets and is running on the Paseo testnet via polkadot-omni-node. Signal computation has been verified end-to-end on-chain: a test proposal was submitted, a test curator was authorized via Root origin, a milestone was submitted and verified, the resulting reputation delta was applied and confirmed in storage, and the signal pallet computed and emitted a signed signal event that is readable on-chain.

Next.js Frontend

The signal display frontend is a Next.js application using polkadot-api (PAPI) with generated TypeScript descriptors for full type safety across both the Kusama and Axiongov chains. It maintains a live block subscription that updates the UI in real time as new blocks are finalized. The frontend reads Kusama OpenGov proposals and overlays Axiongov signal data, displaying curator recommendations alongside live referendum state without any polling or manual refresh.

This implementation validates the core thesis: a five-pallet FRAME library can express the full curator, reputation, milestone, and signal stack; the signal computation is deterministic and verifiable on-chain; and the frontend can present that data to token holders in a usable interface. The economics and governance parameters described in this paper sit on top of a foundation that already works.

6.1 Integration with Existing OpenGov

OpenGov 2.0 is designed as an enhancement layer that integrates with existing Polkadot governance infrastructure rather than replacing it. This architectural decision minimizes technical risk, reduces development complexity, and preserves the option to disable curator functionality if needed.

Referenda Pallet Integration

The current referenda pallet handles proposal submission, voting, and execution. OpenGov 2.0 adds curator review as an optional enhancement. When a proposer submits a referendum, they can opt-in to curator review (eventually this may become mandatory for certain tracks, but initial phases keep it optional).

Curator reviews attach to referenda as on-chain remarks or metadata. The referendum proceeds through normal OpenGov lifecycle (prepare period, decision period, confirmation, enactment) regardless of curator involvement. Curator recommendations are visible to voters but do not programmatically affect vote outcomes.

Conviction Voting Compatibility

OpenGov's conviction voting (time-locked tokens for vote weight multipliers) continues unchanged. Delegation bonuses to staking rewards are separate from conviction voting mechanics. A token holder can simultaneously:

• Stake DOT for validator rewards
• Delegate voting power to curators for governance participation bonus
• Lock tokens with conviction multipliers for individual high-priority votes

These mechanisms are orthogonal and composable. Delegation does not require giving up direct voting rights; token holders can override delegated votes at any time.

Treasury Pallet Modifications

The treasury pallet requires modest enhancements to support milestone-based funding. Instead of single-tranche payments, approved proposals trigger a payment schedule tied to milestone verification. Each milestone approval by curators (or curator panel for high-value proposals) unlocks the next payment tranche. Payment release also deducts the EscrowBuildRate portion into pallet-milestone's escrow hold until EscrowTarget is reached — the proposer escrow mechanism described in Section 3.2 operates at this layer.

This change is backward-compatible. Simple proposals can still request full funding upfront if appropriate. Complex multi-month projects structure payments across milestones. The flexibility accommodates both models.

6.2 Reputation Tracking System

Curator reputation is stored on-chain as a numerical score with associated metadata tracking the source of reputation changes. The reputation pallet maintains:

• Current reputation score
• Historical reputation changes with timestamps and reasons
• Proposals reviewed and outcomes
• Milestones verified and outcomes
• Minority/majority position tracking

Reputation Calculation

Reputation updates occur through deterministic on-chain logic. When a proposal completes (successfully or unsuccessfully), the reputation system evaluates both outcome accuracy and, through periodic curator review panel assessments, charter alignment over time:

1. Identifies curators who reviewed the proposal
2. Calculates outcome delta (promised vs. delivered)
3. Applies reputation adjustments proportional to curator recommendation strength and outcome severity
4. Records the change on-chain with reference to the proposal

This creates a transparent, auditable reputation history. Any token holder can examine a curator's track record, see which proposals they approved or rejected, and evaluate their judgment quality.

Anti-Gaming Mechanisms

Several mechanisms prevent reputation gaming:

• Time-weighted effects: Reputation changes from recent actions are weighted more heavily than historical actions, but full history remains visible
• Outcome-based adjustment: Cannot game reputation through volume; quality of judgment matters more than quantity
• Minority position tracking: Being contrarian is not penalized per se, but consistently wrong minority positions affect reputation
• Sybil resistance: Each curator identity must be unique (enforced through ZK proofs or social verification)

6.3 User Interface Design

The curator interface prioritizes usability for both curators (who use it daily as a professional tool) and token holders (who interact occasionally for delegation and voting).

Curator Dashboard

The curator dashboard provides:

• Active proposals queue: Proposals assigned to this curator awaiting review
• Milestone verification queue: Deliverables submitted and pending verification
• Reputation display: Current score, tier, historical changes
• Earnings tracker: Time logged, compensation earned, payment status
• Capacity monitor: Current capacity utilization vs. limits

Proposal Review Interface

When reviewing a proposal, curators see:

• Full proposal text and attachments
• Proposer history and reputation
• Budget breakdown and milestone schedule
• Similar past proposals and outcomes
• Community discussion from Polkassembly/Subsquare
• Proposal Health Signal board — the live multi-dimension evaluation display showing the current signal state across all charter-derived dimensions, including any Concerns or Conditionals already raised by other curators with written reasoning attached. Curators update their relevant dimension signals as they work, before submitting a final written assessment.
• Timer tracking review duration
• Structured feedback form with required fields
• Approve/Reject/Request-Changes decision options

Milestone Verification Interface

The milestone verification screen displays:

• Expected deliverables checklist
• Submitted documentation and artifacts
• Download links for all materials
• Testing/verification guidelines
• Proposer notes explaining submission
• Feedback text area for curator assessment
• Approve/Reject/Request-Revision workflow

Token Holder Participation Interfaces

Token holders interact through interfaces optimized for their participation style:

Active Voter Dashboard:

• Active proposals awaiting vote with curator recommendations and Proposal Health Signal board prominently displayed — voters can see at a glance which dimensions have concerns, which have cleared, and which remain unassessed before casting their vote
• Voter reputation score and tier status
• Voting history and outcome alignment statistics
• Quarterly reward eligibility and progress toward next tier
• Discussion threads from Polkassembly/Subsquare integrated
• Quick-vote interface for proposals with clear curator consensus
• Deep-dive interface for complex or controversial proposals

Delegation Interface:

• Available curators with reputation scores and specializations
• Track-by-track delegation options (can delegate different tracks to different curators)
• Current staking boost calculation based on delegations
• Curator track records (proposals reviewed, success rates, specialties)
• One-click delegation with adjustable conviction settings

6. System Enhancements and Best Practices

Beyond the core curator infrastructure, several supporting mechanisms enhance system effectiveness, reduce friction, and improve outcomes for all participants. These enhancements address common failure modes, improve curator quality, and create a more professional governance environment.

6.1 Curator Onboarding and Training Program

New curators, especially those entering at Junior tier, benefit from structured onboarding that reduces early mistakes and accelerates effectiveness. The curator onboarding program includes:

• Shadowing Period (First 3 Proposals): New curators review their first 2-3 proposals alongside an experienced Senior or Expert curator. The new curator writes their assessment, but the senior curator provides feedback and guidance before submission. This prevents catastrophic early mistakes while allowing learning through actual practice.
• Documentation Library: Comprehensive repository of curator best practices, common pitfalls, proposal evaluation frameworks, milestone verification checklists, and case studies of past proposals (both successes and failures). Searchable by proposal type, track, and domain.
• Mentorship Pairing (90 Days): Each new curator is paired with an experienced mentor for their first 90 days. Mentors are available for questions, review draft assessments, and provide guidance on difficult decisions. Mentors receive a small governance-configured bonus per mentee successfully onboarded.
• Evaluation Frameworks: Standardized frameworks for evaluating proposals in different categories: technical infrastructure, marketing campaigns, DeFi protocols, educational initiatives, etc. These frameworks provide consistent structure while allowing curator judgment.
• Monthly Curator Calls: Regular video calls where curators discuss challenging proposals, share insights, debate evaluation approaches, and build collective knowledge. Optional but encouraged; builds community and shared standards.

This onboarding infrastructure improves curator quality from day one, reduces the learning curve, and establishes professional standards across the curator community. It also helps Junior Curators build confidence and competence faster, accelerating their progression to higher tiers.

6.2 Proposal Complexity Rating System

Not all proposals within a track are equally complex. A $500K marketing campaign requires different expertise than a $500K protocol upgrade, even though both might be Big Spender track. The complexity rating system addresses this:

• Curator-Assigned Ratings: After reviewing a proposal, curators assign complexity score (1-10 scale). Multiple curator ratings are averaged to create consensus complexity score.
• Complexity Factors: Technical sophistication, cross-domain requirements (needs both technical + business + marketing evaluation), novel approaches without precedent, regulatory considerations, ecosystem integration complexity, number of milestones and interdependencies.
• Capacity Adjustment: High-complexity proposals (8-10 rating) consume 1.5x normal capacity points. Low-complexity proposals (1-3 rating) consume 0.75x normal capacity points. This ensures curator capacity reflects actual workload rather than just dollar amounts.
• Bonus Calibration: Success bonuses for high-complexity approvals are 1.5-2x normal bonuses, recognizing the greater difficulty and risk involved in evaluating sophisticated proposals.
• Expertise Matching: System prioritizes routing high-complexity proposals to Expert and Senior curators or to specialized DAOs with relevant depth.

The complexity system ensures workload is fairly distributed, appropriate expertise is matched to difficult proposals, and curators are rewarded proportionally for handling sophisticated evaluations.

6.3 Conflict of Interest Registry

Transparency about curator interests prevents corruption before it occurs. All curators maintain public on-chain conflict of interest registries that must be updated quarterly or upon material changes:

• Token Holdings: Disclosure of holdings in any parachain tokens, DeFi protocol tokens, or projects that might submit proposals. Threshold: holdings worth >$5,000 or >1% of supply.
• Employment & Consulting: Current and recent (past 12 months) employment relationships, consulting arrangements, advisory roles, or contractor positions with blockchain projects or companies.
• Financial Relationships: Investment relationships, SAFT agreements, grants received, or any financial arrangements with projects that might seek funding.
• Personal Connections: Family members or close personal relationships working for or founding projects in the ecosystem. Disclosure protects curators from suspicion.
• Past Business: Previous business relationships, partnerships, or collaboration history with proposers or their organizations.

Automatic Flagging: When proposals are submitted, the system automatically checks if assigned curators have declared conflicts with the proposer or project. Flagged conflicts trigger automatic reassignment to different curators. Curators can also manually recuse themselves if they identify conflicts not captured by automated checks.

Enforcement: Failure to disclose material conflicts discovered post-facto results in -20 to -50 reputation penalties (as previously detailed). The registry makes conflicts transparent and prevents "oops, I forgot to mention" scenarios that undermine trust.

6.4 Curator Specialization and Expertise Tags

Curators and DAOs declare specialized expertise areas upon authorization and update as they develop new competencies. Specialization tags enable intelligent proposal routing and improve review quality:

Core Specialization Categories:

• Technical: Blockchain infrastructure, consensus mechanisms, cryptography, protocol development, smart contracts, security auditing
• DeFi & Economics: Tokenomics, DeFi protocols, market mechanisms, treasury management, financial modeling
• Marketing & Growth: Brand strategy, community building, content marketing, growth hacking, ecosystem development
• Business & Operations: Startup operations, business model design, venture building, project management, organizational design
• Gaming & Entertainment: Game design, NFTs, virtual economies, content platforms
• Infrastructure & Tooling: Developer tools, wallets, block explorers, data infrastructure
• Research & Education: Technical research, academic collaboration, educational content, documentation
• Legal & Regulatory: Regulatory compliance, legal structures, policy analysis

Routing Logic: When proposals enter the system, they're tagged by proposer with relevant categories. The system preferentially assigns proposals to curators with matching specialization tags. A technical protocol upgrade routes to curators with Technical specialization; a marketing campaign routes to Marketing & Growth specialists.

Cross-Domain Proposals: Complex proposals spanning multiple domains (e.g., a DeFi protocol needing technical review AND economic analysis) are routed to either: (a) DAO curators with multidisciplinary teams, or (b) multiple individual curators with complementary expertise who collaborate on review.

This prevents the failure mode where curators review proposals outside their expertise and either approve them without proper understanding or reject them out of caution. Specialization improves review quality and curator confidence.

6.5 Emergency Fast-Track Process

While most governance can follow standard timelines, genuinely time-sensitive situations require expedited review. The emergency fast-track process accommodates legitimate urgency without enabling abuse:

Qualifying Criteria:

• Critical security vulnerabilities requiring immediate patches
• Time-sensitive market opportunities with narrow windows (parachain auction bidding, partnership deadlines)
• Emergency responses to ecosystem crises (network outages, exploit responses)
• Coordination with external entities on strict timelines (regulatory deadlines, partnership agreements)

Fast-Track Mechanics:

• Proposer Request: Proposer must explicitly request fast-track with detailed justification of urgency
• Dual Curator Approval: Requires approval from 2 Senior or Expert curators to activate fast-track (prevents single curator abuse)
• Shortened Timeline: Review period reduced from standard 7-14 days to 48-72 hours
• Premium Compensation: Curators reviewing fast-track proposals earn FastTrackVerificationRate (a governance-set premium over standard VerificationRate) for milestone verification; retainer bonuses of FastTrackReviewBonus for fast-track proposal reviews
• Community Notification: Fast-tracked proposals are prominently flagged in governance UI with explanation of urgency
• Post-Facto Audit: All fast-track uses are reviewed quarterly to ensure appropriate usage; abuse patterns result in curator reputation penalties

The premium compensation recognizes that fast-track work disrupts curator schedules and requires concentrated effort. The dual-approval requirement prevents individual curators from declaring everything "urgent" to maximize income.

6.6 Proposer Feedback and Curator Quality Ratings

Proposers interact directly with curators and experience feedback quality firsthand. Their perspectives should inform curator evaluation, though not override objective outcome metrics. After each curator review, proposers rate feedback quality:

Rating Dimensions (1-10 scale each):

• Thoroughness: Did curator deeply engage with proposal details or provide superficial review?
• Constructiveness: Was feedback actionable and helpful, or vague and dismissive?
• Timeliness: Did curator complete review within reasonable timeframe?
• Professionalism: Was interaction respectful and professional?
• Accuracy: Did curator correctly understand the proposal and its implications?

Rating Usage:

• Proposer ratings are publicly visible on curator profiles but do NOT directly affect reputation scores (prevents proposers gaming system by punishing honest rejection)
• Consistently low ratings (<6 average across 10+ proposals) trigger curator performance review by peer panel
• High ratings (>8.5 average) qualify curators for quarterly satisfaction bonuses of SatisfactionBonus — governance-configured
• Patterns of low ratings specific to rejected proposals are filtered out (expected that rejected proposers might rate lower)
• Extreme outlier ratings (all 1s or all 10s without nuance) are flagged as potentially unreliable

This creates accountability for feedback quality beyond just approval/rejection outcomes. Curators who approve everything might have high success rates but low proposer satisfaction because their feedback is useless. Curators who reject thoughtfully with detailed constructive feedback should receive high satisfaction scores even from rejected proposers.

6.7 Quarterly Curator Performance Reports

Transparency enables informed delegation decisions. Every quarter, the system auto-generates public performance reports for each curator showing:

• Activity Metrics: Number of proposals reviewed, milestones verified, hours logged, capacity utilization percentage
• Outcome Metrics: Approval/rejection ratio, success rate of approved proposals, accuracy of outcome predictions
• Reputation Trajectory: Starting/ending reputation scores, reputation changes by source (successes, failures, challenges)
• Specialization Performance: Success rates broken down by proposal category (technical vs. marketing vs. DeFi, etc.)
• Proposer Satisfaction: Average satisfaction ratings across all dimensions
• Financial Summary: Total compensation earned (retainer + milestone fees + bonuses), earnings per hour equivalent
• Comparative Ranking: Curator's standing relative to peers in same tier (percentile rankings on key metrics)

These reports are automatically published on-chain and highlighted in delegation interfaces. Token holders can easily compare curators when deciding delegation. High-performing curators are rewarded with increased delegation, while low-performers face scrutiny and potential loss of delegator support.

Reports are cumulative over time, creating long-term track records that enable sophisticated evaluation. A curator with 8 quarters of consistently strong performance is more trustworthy than one with 2 good quarters.

6.8 Graduated Capacity Unlock for New Curators

New curators, even when authorized by community vote, should not immediately handle full capacity loads. Graduated capacity unlock reduces early mistakes and protects both curators and the treasury:

• Initial Capacity Limit: New curators start at 50% of their tier's maximum capacity (e.g., Junior Curator starts at 50 points instead of 100)
• Unlock Conditions: Full capacity unlocks after EITHER: (a) 10 successful proposal reviews with no major failures, OR (b) 6 months of active service, whichever occurs first
• Early Performance Tracking: First 10 reviews are monitored more closely; significant failures trigger extended mentorship rather than immediate harsh reputation penalties
• Compensation During Ramp: Curators earn full tier-appropriate retainer even at 50% capacity; this prevents financial pressure to rush capacity unlock
• Voluntary Extension: Curators can request to remain at reduced capacity longer if they feel they need more experience before taking on full load

This graduated approach recognizes that new curators are learning even if they have relevant expertise. Reducing early exposure to high-stakes decisions gives them room to develop judgment without catastrophic consequences.

6.9 Cross-Parachain Reputation Portability

Curator reputation built through the curator network is portable across the entire ecosystem — both within Polkadot/Kusama parachains and across any chain connected to Axiongov via Hyperbridge. The participation signal is similarly cross-chain: a wallet that has been voting consistently on one connected chain can prove its participation tier to any other connected platform, enabling rewards across the full Axiongov-connected ecosystem. Cross-chain reputation and participation portability create career and incentive value that compounds across deployments:

• Reputation as Credential: Curators can prove their reputation to any connected chain using the same ZK-proof infrastructure used for expertise credentials. "I have Expert Curator status with 92 reputation" becomes portable proof of governance expertise — readable on Polkadot parachains, EVM chains connected via Hyperbridge, or any future Axiongov integration.
• Cross-Chain Curator Roles: Any chain deploying the curator network — whether a Polkadot parachain, an EVM network via Hyperbridge, or a future Axiongov-connected treasury — can recognize existing curator reputation as qualification. An Expert Curator does not need to re-qualify for each new deployment.
• Governance Consulting: High-reputation curators become valuable consultants to parachains designing governance systems, projects seeking treasury funding, or ecosystem initiatives requiring governance expertise.
• Fellowship Integration: Curator reputation complements Technical Fellowship membership. Someone can be both a Technical Fellow (for protocol development) and an Expert Curator (for governance), with credentials reinforcing each other.
• Ecosystem-Wide Standards: As the curator network proliferates across chains via Axiongov, curators with proven track records become standard-setters and mentors for emerging deployments — whether parachains, EVM ecosystems, or new treasury structures yet to emerge.

This portability creates long-term career incentives for reputation-building. Curators aren't just earning compensation from a single treasury; they're building credentials that are valuable across the entire Axiongov-connected ecosystem — a growing network of chains that share a common signal and reputation layer.

7. Case Studies and Precedents

While OpenGov 2.0's specific design is novel, the core principles draw on established precedents from both traditional governance and blockchain experiments.

Business Incubator Model

Research on business incubators demonstrates that structured support and professional oversight dramatically reduces startup failure rates. The Two Pebbles proposal cites studies showing incubator-supported startups have failure rates below 10% compared to 60-80% for unsupported ventures. This 6-8x improvement in success rates comes from systematic mentorship, milestone-based support, and expert guidance.

OpenGov 2.0 applies this model to treasury governance. Curators provide incubator-style support: reviewing proposals for viability, connecting projects with resources, verifying milestone delivery, and providing expert feedback. The economic logic is identical: spending on professional support yields multiples in improved outcomes.

Delegation in Liquid Democracy

Polkadot's delegation features build on liquid democracy research. Studies from experimental systems like LiquidFeedback show that expertise-based delegation improves decision quality when properly incentivized. However, first-generation systems suffered from low participation because delegation was unpaid volunteer work.

OpenGov 2.0's staking boost mechanism solves the incentive problem. Token holders are paid (through enhanced returns) for thoughtful delegation, creating economic motivation to identify and support high-quality curators. This should dramatically increase delegation rates compared to purely voluntary systems.

Reputation Systems in Digital Platforms

eBay, Stack Overflow, Reddit, and other digital platforms demonstrate that reputation systems can effectively govern quality without centralized enforcement. Key design patterns from successful reputation systems include:

• Reputation based on outcomes, not process compliance
• Transparent history enabling informed trust decisions
• Costs for reputation damage creating skin-in-the-game
• Tiered systems where reputation unlocks privileges
• Anti-gaming mechanisms preventing easy reputation farming

OpenGov 2.0's curator reputation system incorporates these principles while adding economic stakes through paid compensation and retrospective accountability.

Validator Economics in Proof-of-Stake

Polkadot already demonstrates that professional infrastructure roles can be effectively compensated while maintaining decentralization. Validators are paid for block production and finalization work. Bad validators are slashed and removed. The system scales horizontally (more validators as needed) and creates competitive markets for quality.

Curators are governance validators. They secure decision quality the way validators secure state transitions. The compensation logic is analogous: pay professionals to provide essential infrastructure services, enforce quality through reputation and slashing, scale horizontally as demand increases.

Traditional Corporate Governance

Public company boards provide instructive parallels and cautionary tales. Boards work well when:

• Directors have relevant expertise and diverse perspectives
• Compensation aligns incentives with shareholder value
• Independence prevents conflicts of interest
• Accountability mechanisms (elections, removal) exist

Boards fail when directors are captured by management, lack expertise, face no consequences for poor decisions, or serve narrow interests. OpenGov 2.0 incorporates the positive patterns (expertise, compensation, accountability) while using decentralization and transparency to mitigate the failure modes (capture, conflicts, opacity).

8. Conclusion

Polkadot OpenGov represents a significant achievement in on-chain governance architecture, but it remains incomplete. Like a city with excellent roads but no traffic lights, the infrastructure exists but coordination mechanisms are insufficient for scale. OpenGov 2.0 completes the picture for Polkadot/Kusama — but it does so by deploying a three-layer architecture with reach far beyond any single chain. Axiongov provides the universal signal layer. The curator network provides chain-agnostic professional review infrastructure. OpenGov 2.0 is the first production deployment, proving the model where governance challenges are most acute and the community most engaged.

The curator system is not a departure from decentralization but an evolution toward professionalized decentralization. Token holders retain ultimate authority through both direct voting (with rewards for active participation) and delegation to expert curators. Community votes remain the final arbiter. What changes is the quality of information available to voters, the compensation for those who do the work of informed participation, and the accountability of those who provide expert guidance.

By creating economic incentives for expert review (both individual and collective through DAOs), implementing reputation-based accountability, and rewarding both active voting and engaged delegation through staking bonuses and direct compensation, OpenGov 2.0 aligns individual incentives with collective benefit. Individual curators and DAO curators succeed by providing accurate assessments across specialized domains. Active voters prosper by making informed decisions. Delegators benefit by backing good curators. Token holders collectively gain from enhanced returns and better governance decisions. Projects deliver value because they receive multidisciplinary expert support. The treasury deploys capital efficiently because professional oversight prevents waste.

The phased implementation approach minimizes risk while enabling rapid learning. Phase 0 covers complete design and planning at a community-approved budget. Phase 1 pilots the model on low-risk tracks for 6 months at a similarly community-approved cost. Only after demonstrating value does the system scale to higher-stakes governance. At each stage, the community votes on whether to continue based on evidence rather than promises.

If successful, OpenGov 2.0 establishes Polkadot as the first proof point for professional decentralized governance at scale. The curator network and Axiongov signal layer become reusable infrastructure that any treasury can connect to, creating network effects as expertise, reputation, and signal quality compound across every new deployment. The demonstrated ability to maintain decentralization while achieving governance quality at scale is not just a competitive advantage for Polkadot — it is a replicable blueprint for the broader ecosystem.

More fundamentally, OpenGov 2.0 addresses a critical challenge facing all blockchain networks: how to govern complex systems with diffuse stakeholders and no central authority. The answer is not to avoid professionalization out of ideological purity, but to professionalize in ways that preserve decentralization through transparency, accountability, and market competition.

This is the path forward for decentralized governance — starting with Polkadot, scaling to every chain. Not through centralization or plutocracy, but through systematic incentives that make expertise valuable, accountability enforceable, and participation rewarding. OpenGov 2.0 makes professional governance compatible with decentralized control, and Axiongov makes that model portable to any on-chain treasury willing to connect. The infrastructure scales to thousands of proposals and millions of token holders across chains while maintaining the quality and legitimacy the ecosystem requires.

9. References

1. Adegbite, O. (2001). "Business Incubation as an Economic Development Strategy: A Review of Research Orientations, Impacts, and Determinants of Success." Research Gate.
2. Polkadot Wiki. "Learn Polkadot OpenGov." https://wiki.polkadot.network/docs/learn-polkadot-opengov
3. Polkadot Wiki. "Polkadot OpenGov Origins." https://wiki.polkadot.network/learn/learn-polkadot-opengov-origins
4. Web3 Foundation. "Polkadot OpenGov Documentation." https://polkadot.com/opengov/
5. Messari Research. "Polkadot OpenGov Deep Dive." March 2024.
6. Two Pebbles Ventures. "Polkadot for New Ventures: Business Accelerator Proposal." October 2025.
7. Buterin, V. et al. "Flexible Voting in DAOs." Ethereum Research Forum, 2023.
8. Zamfir, V. "Casper the Friendly Finality Gadget." Ethereum Foundation, 2017. [Precedent for reputation-weighted consensus]
9. OpenGuild Community. "Implementing Governance Proposals on Polkadot." August 2024.
10. Polkadot Ecosystem. "Step-by-Step Guide to Participate in Polkadot OpenGov." 2025.