Treasury Guardian v2
We have updated our proposal to include the applicable feedback.
Feedback Summary:
- High Budget: ~83.6k USDC deemed excessive (https://polkadot.subsquare.io/referenda/1767#4)
- Unclear Deliverables: Milestones lacked specificity (https://polkadot.subsquare.io/referenda/1767#11)
- Integration with UIs: Suggested integrating with existing governance UIs like Polkassembly/Subsquare (https://polkadot.subsquare.io/referenda/1767#12 https://polkadot.polkassembly.io/referenda/1767#comment-Du77Qca5DOhvSjjMVoDY)
- Guardian Rewards: 2%/5% rewards risk large payouts; need caps (https://polkadot.subsquare.io/referenda/1767#5 https://polkadot.subsquare.io/referenda/1767#4)
Changes Made:
- Reduced Budget: Removed Milestones 5-6; reducing total request to 60,800 USDC.
- Refined Milestones:
- Added detailed deliverables.
- Milestone 1: MVP Core Implementation and Reward Validation
- Deliver product with core functionality (includes AssetHub integration)
- Present appropriate solution for Guardian Rewards
- Milestone 2: Refinement of Tool Enhanced Oversight
- Delay/Cancel Referenda Tracking
- Action Alerts for intervention (up to 36 days before scheduled payout)
- Milestone 3: Growth Community Adoption and Scaling
- Onboard Guardians
- Grow milestone-based scheduled payouts referenda usage
- Milestone 4: The Future Advanced Features and Ecosystem Integration
- Guardian Leaderboard UI (Reputation Tracking)
- Integration into existing OpenGov UIs/Long-Term Strategy
- Milestone 1: MVP Core Implementation and Reward Validation
- Added detailed deliverables.
- Integration with UIs: Milestone 4 now focuses on long-term strategy and potential UI integrations with Polkassembly/Subsquare.
- Updated Guardian Rewards: Milestone 1 includes finalisation on an appropriate Treasury Guardian Reward structure. Join the discussion here.
- Rescheduling: A 2 week holiday was included at the end of 2025, pushing back milestone delivery and payouts by 2 weeks post New Year.
Voters have become increasingly cautious, making it harder for projects to gain approval for their proposals. Our project introduces a clawback mechanism to significantly reduce risks to the Polkadot Treasury. By implementing this safeguard, we aim to lower financial exposure and provide voters with peace of mind to confidently approve funding for impactful projects.
With our tool, a group of decentralized treasury guardians is incentivized to oversee scheduled payouts and intervene when necessary to protect the Treasury.
Key features of our proposal:
- No upfront payments are requested.
All payouts are tied to milestone delivery, with sufficient time for the community to review and delay/ cancel disbursements if needed to ensure accountability on our behalf.
Milestone Delivery Deadlines:
Milestone 1 (MVP): Nov 22 2025 -> Scheduled Payout: Jan 11 2026
Milestone 2 (Refinement): Dec 20 2025 -> Scheduled Payout: Feb 8 2026
Christmas Holiday (Dec 20 2025 -> Jan 3 2026)
Milestone 3 (Growth): Jan 31 2026 -> Scheduled Payout: Mar 22 2026
Milestone 4 (The Future): Feb 28 2026 -> Scheduled Payout: Apr 19 2026
We are passionate about leading the charge to de-risk the Treasury, enhance its efficiency, and better align the interests of token holders and proposers. We eagerly look forward to collaborating with the Polkadot community and new + existing ecosystem teams to achieve these goals.
Read our full proposal here.
Comments (1)
I appreciate the intent, but I have significant concerns.
This feels like a band‑aid that addresses only a small slice of our governance problems. It introduces reputation tracking and concentrates selection in the hands of a few individuals... effectively creating a policing task force or entrenched “guardians”... which is not the way to drive broad, trustable change.
We should aim for a model where anyone with verifiable credentials can perform reviews and be compensated for the work, in a fully decentralized way that preserves privacy for proposers, voters, and curators (for example via sub‑treasury shielding and ZK attestations). Expertise, not gatekeeping, must be central: technical reviews should be done by domain experts, not by generalist devs judging business/marketing cases.
I support improving OpenGov mechanics to raise decision quality and reduce funding for non‑deliverables, but this proposal as written risks consolidating power rather than enabling scalable, accountable, and privacy‑preserving participation. There are many other mechanics we can use to achieve those goals... competitive procurement, rotating trusted reviewers, ZK expertise registries, funding categories, and transparent performance‑based payouts... and those deserve exploration instead.
We have been working for months to move this forward, we do have an MVP, ping me and will include you.
@Jose_TwoPebbles
Thank you for your comment.
There seems to be a misunderstanding on a key point.
Just like anyone can create a referendum in OpenGov, anyone can be a Treasury Guardian. It works in fact in the way you describe the ideal model. Anyone can perform reviews and be compensated for the work. No gatekeeping. You can prove this to yourself by playing around with the platform.
Kindly let me know which part of the proposal gave rise to this misunderstanding. I would be happy to clarify it.