Threshold
PolkaWorld votes NAY.
We recommend completing the development first and applying for retroactive funding once the tool has seen real adoption.
Right now, we’re seeing far too many proposals in the Polkadot Treasury claiming to “lower the barrier for developers.” But in reality—have any of these tools actually led to exponential developer growth? Many tool-focused proposals do not treat user growth as a core KPI. Instead, they justify funding based on “what features were built,” “how many features were delivered on time,” or “how many tutorials were written.” As a result, significant resources are spent on feature accumulation rather than on shifting user behavior, improving retention, or integrating meaningfully into the ecosystem. We believe this is a major problem.
This proposal requests $170,000 USDC, yet currently has only 30 monthly active users (with a goal of reaching 90 by year-end). That’s nearly $2,000 per new user. Is that truly necessary?
For proposals like this, we strongly suggest applying via retroactive funding in the future.
You can view the full feedback here.
Dear Proposer,
Thank you for your proposal. Our first vote on this proposal is NAY.
The Medium Spender track requires 50% quorum (at least 5 aye votes) and simple majority of non-abstain votes according to our voting policy v0.2, and any referendum in which the majority of members vote abstain receives an abstain vote. This proposal has received zero aye and five nay votes from ten available members, with one member abstaining. Below is a summary of our members' comments:
Comments indicated doubts over the tool’s necessity and its ability to deliver measurable value for developers. Critics questioned whether the budget was justified, citing an unsatisfactory first delivery and technical issues such as recurring errors in various tool sections. Several remarks pointed out that a clear return on investment had not been demonstrated, and potential traction among both individual and enterprise users remained unverified. While one voter abstained due to limited technical insight, the overall sentiment focused on the lack of compelling evidence and technical robustness, leading to a negative consensus on the proposal.
The full discussion can be found in our internal voting.
Please feel free to contact us through the links below for further discussion.
Kind regards,
Permanence DAO
Decentralized Voices Cohort IV Delegate
📅 Book Office Hours
💬 Public Telegram
🌐️ Web
🐦 Twitter
🗳️ Delegate
TruthDAO voted NAY ❌
Redundancy risk: 45% of the budget goes to building a real-time collaborative IDE—but with only 90 target users, the ROI just doesn’t add up.
Tech path dependency: The JAM SCALE codec hasn’t passed the RFC process yet. Integrating it now could lead to costly rework later.
See more feedback here!
📖Truth DAO Governance Statement
🗳️ Delegate
JAM Implementers DAO votes NAY on this proposal
Many of the JAM DAO members have concerns with this proposal in its current form:
Redundancy & Ecosystem Fit: Creating a new IDE focused on the PAPI introduces potential redundancy given existing tooling and broader developer language preferences in the ecosystem. It’s unclear whether this direction aligns with actual developer demand.
Accountability & Metrics: The proposal lacks concrete metrics for success. There is no clear framework for evaluating adoption, usage, or impact, especially given the $170K USDC budget request.
Cost Justification: The budget appears disproportionate to the current and projected usage. Without a clear path to significant developer adoption, the cost per anticipated user is difficult to justify.
JAM DAO is broadly aligned to improve developer experience, but proposals of this scale should demonstrate validated need, community engagement, and a clear adoption path.
OG Tracker Rating 3/3
Clear display of deliverables✅
Clear display of a valid direct point of contact ✅
Clear display of proposal’s duration✅
OGT Rating aims to help voters make better informed decisions and direct proposers towards certain common-good practices. We are providing feedback based on 3 simple yet crucial criteria which we believe should be included in every OpenGov referenda.