OpenGov Treasury

Kusama OpenGov is the decentralized governance system that controls the Kusama treasury. The treasury is funded by transaction fees, validator slashes, and governance deposits, enabling the community to directly fund projects through democratic voting.

How OpenGov Works

OpenGov enables anyone to submit proposals for treasury funding:

1. Submit Proposal: Create a referendum with your funding request
2. Community Voting: KSM holders vote with conviction (longer locks = more voting power)
3. Confirmation Period: Proposal must meet approval thresholds
4. Enactment: Approved funds are transferred from treasury

Key Features

Treasury Tracks

Different proposal types follow different tracks with varying voting periods:

Track Parameters

Each track has specific parameters:

Submitting a Treasury Proposal

Step-by-Step Guide

1. Prepare Your Proposal

   • Project description and goals
   • Technical approach
   • Budget breakdown
   • Timeline with milestones
   • Team information
   • Expected deliverables

2. Choose Your Platform

   • Kusama Subsquare - Primary interface
   • Polkassembly - Governance dashboard
   • Polkadot.js Apps - Direct submission

3. Submit the Referendum

   • Select appropriate track (Small/Medium/Large Spender)
   • Pay the decision deposit (varies by track)
   • Set enactment period

4. Campaign for Support

   • Share on social media (Twitter, Discord, Matrix)
   • Present in community calls
   • Engage with OpenGov delegates
   • Answer community questions

5. Monitor Voting

   • Track votes in real-time
   • Respond to concerns
   • Provide additional information as needed

6. Enactment

   • If approved, funds are transferred automatically
   • Begin work on milestones
   • Submit regular progress updates

Writing a Successful Proposal

Essential Components

1. Executive Summary

## Summary
Build a Tornado Cash-style privacy pool for KSM and Kusama-based assets.

## Problem
Kusama lacks private transfer options. All transactions are publicly visible.

## Solution
Deploy a shielded pool using:
- Groth16 proofs (verified via BN254 precompiles)
- Rust-optimized Poseidon hashing
- LeanIMT for efficient Merkle trees

2. Budget Breakdown

## Budget
- Development (3 months): 150 KSM
- Security Audit: 50 KSM
- Infrastructure (1 year): 20 KSM
- Marketing/Community: 10 KSM
- Contingency (10%): 23 KSM
- **Total: 253 KSM**

3. Timeline

## Timeline
- Month 1: Core contract development
- Month 2: Frontend and integration
- Month 3: Testing and audit
- Month 4: Launch and documentation

4. Team

## Team
- **Developer A**: 5 years Rust, 3 years ZK (GitHub: ...)
- **Developer B**: Smart contract auditor, ex-...
- **Advisor C**: Polkadot ecosystem contributor

5. Milestones

## Milestones
1. Contract deployment and testnet launch (30%)
2. Frontend release and user testing (30%)
3. Security audit completion (20%)
4. Mainnet launch and documentation (20%)

Best Practices

Do:

• ✅ Be specific about deliverables
• ✅ Tie payments to verifiable milestones
• ✅ Engage with the community before submitting
• ✅ Provide regular progress updates
• ✅ Budget realistically with contingency
• ✅ Include links to previous work

Don't:

• ❌ Make vague or overly ambitious claims
• ❌ Request full payment upfront
• ❌ Ignore community feedback
• ❌ Underestimate development time
• ❌ Forget about maintenance costs
• ❌ Copy proposals from other projects

Example Proposal Structure

# Treasury Proposal: Kusama Shielded Pool

## Summary
[2-3 sentence overview]

## Problem
[What problem are you solving?]

## Solution
[Technical approach and why it works]

## Technical Details
- Architecture overview
- Technology stack (Rust, Circom, etc.)
- Security considerations
- Integration points

## Budget
[Itemized breakdown]

## Timeline
[Milestones with dates]

## Team
[Members and credentials]

## Milestones
[Payment schedule tied to deliverables]

## Success Metrics
[How will you measure success?]

## Risks and Mitigation
[Potential challenges and solutions]

## Additional Information
[Any other relevant details]

Post-Funding Responsibilities

Once your proposal is funded:

1. Regular Updates

• Post progress reports on your proposal thread
• Update at least monthly
• Include working demos when possible

2. Meet Deadlines

• Deliver milestones on time
• Communicate delays proactively
• Request amendments if needed

3. Community Engagement

• Respond to questions promptly
• Participate in community calls
• Be transparent about challenges

4. Final Report

• Submit completion summary
• Provide links to deliverables
• Document lessons learned

Voting Mechanics

Conviction Voting

Voting power is multiplied based on lock duration:

Approval and Support

Proposals must meet two thresholds:

• Approval: Ratio of Aye vs Nay votes
• Support: Ratio of participating votes vs total eligible

Both thresholds vary by track and time in confirmation period.

Delegation

If you can't vote on every proposal, delegate your voting power:

How Delegation Works

1. Choose a delegate (expert in specific area)
2. Set conviction level
3. Delegate can vote on your behalf
4. You can override delegated votes

Finding Delegates

• Check delegate profiles on Subsquare
• Review their voting history
• Look for expertise in your area of interest
• Consider splitting delegation across multiple delegates

Canceling or Killing Referendums

Referendum Canceller

• For non-malicious errors
• Refunds deposits to originators
• Requires Whitelisted Caller origin

Referendum Killer

• For urgent, malicious cases
• Slashes deposits
• Requires higher authority origin

Resources

Governance Platforms

• Kusama Subsquare - Primary OpenGov interface
• Polkassembly - Governance dashboard and discussions
• Polkadot.js Apps - Submit and track proposals

Documentation

• OpenGov Overview
• Treasury Guide
• Origins and Tracks
• Conviction Voting

Community

• Matrix: #Polkadot-Direction:parity.io
• Discord: Polkadot Official Discord - governance channels
• Forum: Polkadot Forum governance section

Success Stories

Notable Treasury-Funded Projects

Getting Help

Need assistance with your proposal?

1. Community Channels: Ask in Polkadot/Kusama Discord or Matrix
2. OpenGov Delegates: Reach out for feedback and guidance
3. Previous Applicants: Learn from successful proposal authors
4. Technical Fellowship: For technical implementation questions
5. Treasury Working Group: Some communities have dedicated help channels

Previous: Why Kusama for ZK | Next: Zero Knowledge Bounty