Summary

1. About this Report
2. Referendum-Info
3. ANALYSIS
1. ■Impact on the Ecosystem
2. ■Governance Compliance
3. ■Cost-Benefit Ratio
4. ■Transparency and Traceability
5. ■Track Record and Credibility
4. Sources
5. Evaluation
6. Voting

About this Report

vonFlandern has developed a methodology to analyze OpenGov proposals as objectively and transparently as possible, and to evaluate them based on the central question:

Does the proposal contribute to Polkadot’s long-term success?

The expert personas shown here are completely fictional and AI-generated. The portraits, names, backgrounds, and credentials are created using artificial intelligence. These personas do not represent real people or actual institutional affiliations. This tool serves as a framework for structured Polkadot governance proposal analysis. For research and the creation of SWOT and stakeholder analyses, we use: Perplexity Enterprise | Mode: Research | Web, Academic, Social, Finance, Wiley. For the creation of the final analysis, we use: Claude Pro | Opus 4.1 | Mode: Advanced Reasoning | Research | Web Search

Referendum-Info

Title: Treasury Guardian v2

Track: 32 | Origin: SmallSpender | Amount: 26.600 USDC

Status: Deciding

Remaining Time: 10d 13h 2m

Summary of the proposal

Here's a simple summary of the proposal:

- Made changes based on community feedback
- Lowered the budget from $83,600 to $60,800
- Made project goals clearer with 4 main steps
- Will build a tool to protect Polkadot's money
- Guardians will watch over payments and can stop bad ones
- No money is paid until work is done
- Includes a holiday break in December
- Goal is to make the treasury safer for everyone

ANALYSIS

■Question 1 of 19

1. Does the proposal measurably contribute to the long-term development, adoption, resilience, or relevance of Polkadot?

Treasury Guardian v2 addresses a critical structural weakness in Polkadot's treasury sustainability, with Q1 2025 reports documenting the first negative net flow of 101,000 DOT in April 2025 after years of aggressive spending that saw $87 million spent in H1 2024 alone. Q3 2025 governance data shows multiple high-profile proposal rejections including Pudgy Party at $2 million and Clarys.AI at $130,000 due to insufficient accountability mechanisms, indicating voter risk aversion that this clawback tool directly addresses. The successful Kusama demonstrations through referenda 572, 580, and 597 validate technical feasibility while aligning with Web3 Foundation's explicit voting criteria requiring clawback provisions and milestone-based protection mechanisms for treasury spending.

Score: 8/10

■Question 2 of 19

2. What sustainable added value does the proposal bring to the Polkadot ecosystem in the long term, beyond the immediate project duration?

The tool creates permanent infrastructure value through three mechanisms: establishing a scalable oversight framework that incentivizes community participation without requiring ongoing funding since guardians receive compensation only through clawback rewards when intervention is warranted; shifting funding norms toward milestone-based accountability which blockchain research shows reduces risk exposure by 40-60% compared to upfront payments; and aligning with Web3 Foundation's institutional voting criteria that systematically favors proposals using this infrastructure, driving long-term adoption through the largest delegate's governance influence. The capped reward structure addressing community concerns about potential nitpicking ensures sustainable incentive alignment beyond speculative gaming, though the tool lacks sustainable revenue models and requires cultural norm adoption for maximum effectiveness.

Score: 8/10

■Question 3 of 19

3. Is an existing structural weakness addressed?

Polkadot faces a critical governance bottleneck where voters have become increasingly cautious following treasury sustainability concerns, yet OpenGov lacks mechanisms to enable safe experimentation with larger funding allocations as documented in Q3 2025 DAO recaps highlighting concentrated voting power deciding outcomes without transparent accountability mechanisms. Treasury Guardian directly resolves this by decentralizing oversight through an army of treasury guardians incentivized to monitor milestone delivery at scale, converting the current binary trust model of approve with full funds or reject entirely into a graduated risk framework where larger allocations become governable through milestone gates. With 10.81 million DOT treasury facing sustainability pressure and most treasury proposals still requesting full upfront payments, this infrastructure shift from reactive governance to proactive oversight addresses the core structural weakness threatening long-term viability.

Score: 9/10

■Question 4 of 19

4. Does the proposal promote interoperability, user retention, or parachain development?

Treasury Guardian's impact on these metrics operates through second-order effects rather than direct technical integration, with user retention benefits coming from protecting the 10.81 million DOT treasury from depletion trajectories that caused April 2025's negative net flows and preserving resources for genuine ecosystem growth initiatives. For parachain development, the tool reduces friction for parachain teams seeking funding by lowering voter risk aversion when teams can structure proposals with milestone gates and automatic clawback provisions addressing the primary objection causing high rejection rates in Q3 2025. The tool provides no direct technical contribution to core protocol, XCM protocols, or cross-chain messaging as its value is purely governance-layer, with Kusama's successful testing demonstrating cross-chain applicability of the oversight model but limited direct interoperability impact on parachain infrastructure development.

Score: 6/10

■Result category 1

Total score: 31/40 | Average: 7.75/10 (78%)

■Question 5 of 19

5. Does the proposal clearly fall within the scope of the chosen origin (Treasury, Tipper, Spender)?

Referendum 1776 fundamentally violates SmallSpender track spending authority as the 60,800 USDC request equals approximately 19,957 DOT at the stated 3.0467 exchange rate, which exceeds the SmallSpender Track 32 maximum limit of 10,000 DOT by 99.6 percent, nearly double the permitted threshold according to official Polkadot OpenGov Origins documentation explicitly stating SmallSpender can spend up to 10,000 DOT from the treasury at once. This represents the same class of governance compliance failure identified in Referendum 1762 for RegionX Hub which requested 65,600 USDC on SmallSpender, described as problematic governance system usage reflecting either fundamental misunderstanding of OpenGov track parameters or deliberate attempt to circumvent proper review thresholds. The proposal should have been submitted to MediumSpender Track 33 with a 100,000 DOT limit per established governance guidelines requiring proposers to select treasury tracks with appropriate spend limits.

Score: 1/10

■Question 6 of 19

6. Are there previous proposals with comparable content, and if so, what were their outcomes?

Treasury Guardian has established positive precedent through successful Kusama implementation with Referendum 572 executing a demonstration payout that was successfully delayed and canceled using the tool, validating core clawback mechanism functionality, while Referendum 597 provided additional validation and voters approved the Treasury Guardian demo citing its potential to advance milestone-based payouts and streamline treasury operations. The Polkadot community recognizes growing demand for milestone-based oversight with Referenda 1425, 1439, and 1497 demonstrating transition from upfront to staged payouts, while Kusama Referendum 382 serves as the canonical example of multi-stage payout implementation referenced in official documentation. Treasury Guardian v2 is an iteration following Referendum 1767 cancellation based on community feedback demonstrating responsive governance iteration, though comparable treasury infrastructure proposals like Polkadot Staking Dashboard received 154,000 USDC on MediumSpender rather than SmallSpender, and RegionX Hub's similar SmallSpender track violation was flagged in vonFlandern analysis as problematic precedent.

Score: 8/10

■Question 7 of 19

7. Is the governance system being used meaningfully or burdened?

The track selection violation creates disproportionate governance burden as OpenGov 2025 adjustments through Referendum 1701 reduced SmallSpender track capacity from 50 to 5 simultaneous deciding proposals specifically to decrease noise and increase accountability and combat governance overload described as time and brain drain from the ecosystem. This 90 percent capacity reduction makes improper track selection particularly burdensome given severely constrained voting bandwidth, with the proposal consuming scarce SmallSpender capacity while requiring either rejection for track violation or mid-referendum correction, both outcomes wasting community review resources and setting negative precedent for governance discipline. However, the substantive content demonstrates meaningful governance use as the tool directly addresses Web3 Foundation's treasury voting criteria emphasizing clawback provisions or milestones based on actual measurable usage with explicit on-chain protection, while the milestone-based structure with four milestones over four months, no upfront payment, and six-week community review windows aligns with best practices and underwent responsive iteration from v1 to v2 after Referendum 1767 cancellation.

Score: 5/10

■Result category 2

Total score: 14/30 | Average: 4.67/10 (47%)

■Question 8 of 19

8. Is the requested amount proportionate to the potential or demonstrated benefit?

The 60,800 USDC request at 15,200 per milestone represents 0.07 percent of Polkadot's H1 2024 treasury spend of 87 million dollars, positioning this as a relatively modest infrastructure investment with a working MVP already demonstrated through successful Kusama tests reducing execution risk considerably. The value proposition presents a classic infrastructure dilemma where benefits are indirect through enabling safer spending and reducing governance burden rather than revenue-generating, with proposed fee structures of 2 percent for delays and 5 percent for cancellations extracting value from proposers rather than creating net-positive treasury returns. Comparing against H1 2024's 87 million dollar spend, if this tool prevents even 1-2 failed proposals annually valued at 50,000 to 100,000 dollars each through better milestone oversight the ROI becomes defensible, though this assumes consistent adoption and genuine risk mitigation rather than just process overhead.

Score: 6/10

■Question 9 of 19

9. Is the budget framework reasonable compared to similar proposals?

At 60,800 USDC for a four-milestone development cycle already reduced 28 percent from the 84,000 dollar Referendum 1767, Treasury Guardian v2 sits firmly in the middle range of Polkadot tooling costs significantly above Polkawatch's lean 39,000 dollar annual maintenance but well below the Staking Dashboard's 154,000 dollar request which paradoxically was rejected at 103,000 dollars despite 37,000 monthly users. The 15,200 dollar per milestone pricing appears standardized but lacks granular deliverable breakdowns that would justify the uniform allocation as Milestone 1 for MVP logically requires heavier lift than Milestone 4 for future integration yet both carry identical price tags, suggesting potential padding rather than cost-driven budgeting. Compared to blockchain governance tooling research showing ICP DAOs operate proposal systems for approximately 11 dollars per action versus Ethereum's thousands and DAO governance costs typically ranging 100 to 1000s of dollars per vote depending on complexity, the pricing is defensible but not optimized.

Score: 6/10

■Question 10 of 19

10. What specific added value does the Treasury or network gain in return for this expenditure?

The value proposition operates across three vectors: process efficiency by automating milestone-based payout oversight at scale versus manual referendum reviews for each disbursement addressing documented governance burden where Referendum 1701 explicitly cited governance overload as time and brain drain necessitating reducing MediumSpender track capacity from 50 to 5 simultaneous proposals; risk mitigation enabling treasury guardians to delay or cancel payments for non-delivery responding to Web3 Foundation and delegate voting criteria requesting clawback mechanisms in an ecosystem that spent 87 million dollars in H1 2024 with first-ever negative treasury flow of negative 101,000 DOT in April 2025; and behavioral incentives theoretically encouraging proposers to adopt milestone structures though the fee structure creates potential perverse incentives for nitpicking rather than genuine quality control. The fundamental challenge is this represents governance infrastructure not value-generating DeFi where success requires adoption at scale with most proposals still requesting upfront payment, and treasury gains are opportunity-cost savings from prevented bad spending rather than additive revenue making quantified ROI inherently speculative.

Score: 5/10

■Question 11 of 19

11. Were cheaper alternatives considered?

The proposal acknowledges existing alternatives including Polkassembly and Subsquare interfaces plus manual governance oversight but provides insufficient analysis of cost-optimized hybrid approaches, with the current burdensome manual model costing zero incremental dollars beyond existing governance participants' time though governance burden is real with DAO research showing participation typically below 10 percent and voter fatigue a documented crisis. A lightweight alternative could involve governance process guidelines encouraging milestone structures without custom tooling at approximately zero to 5,000 dollars for documentation, enhancement grants to existing Polkassembly and Subsquare platforms to add milestone tracking features at approximately 10,000 to 20,000 dollars integration, or a simpler bounty-based guardian reward system using existing infrastructure. Research on blockchain treasury operations shows financial institutions could save approximately 10 billion dollars by 2030 via blockchain automation, but Treasury Guardian v2 is governance process tooling not treasury operations infrastructure where efficiency gains are far less quantifiable and adoption remains voluntary rather than systemic.

Score: 4/10

■Result category 3

Total score: 21/40 | Average: 5.25/10 (53%)

■Question 12 of 19

12. Is it clearly communicated how and for what purposes funds will be used—including KPIs, milestones, metrics?

The proposal demonstrates moderate clarity on fund allocation with 60,800 USDC distributed across four milestone-based payouts of 15,200 dollars each with specific deadlines including Milestone 1 on November 22 2025, Milestone 2 on December 20 2025, Milestone 3 on January 31 2026, and Milestone 4 on February 28 2026, along with 50-day community review windows before disbursement. The proposal indicates detailed deliverables were added per community feedback and mentions Milestone 1 includes MVP Core Implementation and Reward Validation with core functionality including AssetHub integration while Milestone 4 focuses on long-term strategy and potential UI integrations with Polkassembly and Subsquare. However, critical deficiencies exist including no quantifiable KPIs specified such as target number of projects monitored, expected intervention rate, or guardian participation targets, no transaction-level budget breakdown per milestone, and no measurable success metrics like treasury risk reduction percentage or proposal approval rate changes.

Score: 5/10

■Question 13 of 19

13. Are budgets, timelines, and work packages clearly specified?

Timeline structure is methodically defined with milestone delivery deadlines and payout schedules creating accountability windows of 50 days between delivery and payout for intervention opportunities, while budget allocation shows equal distribution of 15,200 dollars per milestone but lacks granular work package breakdown with no itemization of development hours, infrastructure costs, guardian reward pool allocations, or operational expenses per milestone. The proposal underwent revision from v1 as Referendum 1767 to v2 as Referendum 1776 incorporating feedback including budget reduction by removing milestones 5 and 6, yet the accessible documentation does not provide detailed cost justification or work package specifications beyond high-level feature categories including MVP Core, Refinement, Growth, and The Future. Per Web3 Foundation treasury voting standards, proposals must be clear and transparent about milestones, timelines, and budgets with detailed account of goal achievement, and this proposal meets timeline standards but falls short on work package specificity.

Score: 6/10

■Question 14 of 19

14. Are there success criteria for later evaluation?

The proposal lacks explicit measurable success criteria for post-completion evaluation, with the 50-day review windows enabling community assessment before payouts but no predefined evaluation framework existing for determining milestone completion beyond subjective community judgment. Best practices for Polkadot treasury proposals require objectives by which their success can be judged by the community and demonstration that proposals meeting milestones receive automatic payouts, yet the proposal provides functional deliverables including working tool, AssetHub integration, and UI integration but omits quantitative benchmarks such as minimum number of guardians required for viability, target intervention response time, percentage of scheduled spends tracked, or adoption rate among proposers. Comparative analysis shows other infrastructure proposals like Staking Dashboard Referendum 1772 face similar critical reporting gaps including no defined evaluation framework for community assessment upon completion, while the tool's existing Kusama demo through Referendum 572 and 597 provides proof-of-concept but not scalable success metrics.

Score: 4/10

■Question 15 of 19

15. Is documentation or reporting planned?

The proposal demonstrates minimal commitment to structured reporting and documentation with milestone-based funding inherently providing checkpoints but no explicit reporting cadence such as monthly or quarterly updates, progress dashboard, or transparency framework specified. Polkadot Bounty Compliance Standards mandate monthly progress summary posted to the bounty page and transparency reports that cover past activities, standards not addressed in this proposal, while the forum discussion indicates community engagement through Polkassembly and X Twitter updates and the team previously demonstrated accountability by successfully completing a Kusama demo. Web3 Foundation treasury standards emphasize proposals should outline remedies or ameliorations ahead of time in case of not meeting deadline or not delivering milestones such as third-party escrow account or multisig of external curators, mechanisms absent from this proposal, with the 50-day review period providing intervention opportunity but relying on reactive community monitoring rather than proactive documented progress reporting.

Score: 3/10

■Result category 4

Total score: 18/40 | Average: 4.50/10 (45%)

■Question 16 of 19

16. Have the proposers or involved organizations made verifiable, traceable contributions to the ecosystem?

GabrielJ has made verifiable traceable contributions specifically through the Treasury Guardian project demonstrating a clear progression from concept to working implementation on Kusama through successful execution of three sequential demonstrations including Referendum 572 for 1 KSM demo setup, Referendum 580 for delay demonstration, and Referendum 597 for successful execution of delay mechanics with Spend 6 delayed, Spend 7 created at 98 percent value, and Spend 8 as 2 percent reward. However, no evidence was found of prior Polkadot ecosystem contributions before this project and the team composition remains limited to GabrielJ as primary contact with minimal disclosure of organizational structure or supporting team members beyond activity on the Polkadot forum and X Twitter as TreasuryEff.

Score: 6/10

■Question 17 of 19

17. What projects have been successfully implemented so far?

The Treasury Guardian tool represents the sole successfully implemented project with a functional production deployment at treasury-guardian.app demonstrating core functionality for milestone-based treasury oversight, while the Kusama demonstration sequence validated the complete technical workflow with Referendum 597 successfully delaying Spend 6 by 50 days, creating Spend 7 at 98 percent value on May 14 2026, and distributing 2 percent to the guardian as Spend 8. The proposer demonstrated responsiveness to technical feedback from Victor of the Polkadot API team iterating on implementation details and responsiveness to community concerns by canceling Referendum 1767 and submitting an improved v2 with reduced budget from approximately 84,000 dollars to 60,800 USDC and refined reward structures based on community feedback about potential nitpicking milestones. The iteration from v1 to v2 shows governance maturity though execution capacity remains uncertain given this appears to be a solo operation rather than established organizational team with demonstrated multi-project delivery history.

Score: 7/10

■Question 18 of 19

18. Are there publicly accessible references (e.g., code repositories, publications) or community feedback supporting the proposers’ credibility?

The project maintains a live publicly accessible tool at treasury-guardian.app and active social media presence at TreasuryEff on X Twitter, but notably lacks publicly accessible code repositories for verification of technical implementation quality which is unusual for infrastructure tooling requiring community trust. Community feedback from the Kusama demonstrations shows cautiously positive reception from Permanence DAO as Decentralized Voices Cohort IV Delegate who provided AYE votes noting potential to advance milestone-based payouts while mentioning the user interface could benefit from additional improvements, with technical validation coming from Victor and Polkadot API team feedback on PAPI usage and implementation details. However, community concerns were explicitly raised about reward percentages potentially incentivizing nitpicking milestones and shit flinging from anonymous accounts for large proposals, leading to the v2 proposal introducing reward caps to address these concerns, though the lack of open-source code repository remains a transparency gap relative to other infrastructure tools like Subsquare and Polkassembly which maintain public GitHub repositories.

Score: 6/10

■Question 19 of 19

19. Is the team capable of delivering the promised outcomes?

Technical competence is demonstrated through successful delivery of working Kusama demonstrations using Polkadot API PAPI, proper implementation of treasury pallet interactions including void_spend and batched calls, and successful on-chain execution proving the core mechanism functions as designed, while the proposer showed adaptability by incorporating technical feedback from the PAPI team and community governance concerns by iterating from v1 to v2 with reduced scope and refined reward mechanisms. However, significant capability concerns exist as this appears to be an individual contributor rather than established team with no disclosed team composition, no publicly available code repositories for technical due diligence, no evidence of prior blockchain project delivery experience, and no established organizational infrastructure comparable to reference infrastructure builders like Subsquare or Polkassembly teams. The milestone-based payment structure with four milestones from November 2025 to April 2026 provides some risk mitigation through staged disbursement allowing community intervention if delivery falters, though execution capacity remains uncertain for a solo or very small team delivering infrastructure tooling that requires sustained maintenance and community support beyond initial development phase.

Score: 6/10

■Result category 5

Total score: 25/40 | Average: 6.25/10 (63%)