IO: Developer Experience Initiative
248 DReps voted · 86 with a rationale
Open a row to read the rationale.
- Yes 2.4M ₳ No rationale
- Yes 2.3M ₳ No rationale
- Yes 2.1M ₳ No rationale
- Yes 2.1M ₳ Rationale
- Abstain 2.1M ₳ No rationale
- Yes 2.1M ₳ No rationale
- Yes 2.1M ₳ Rationale
I support this proposal because improving Cardano’s developer experience is a high-leverage investment in adoption, utility, and ecosystem growth. The current builder journey remains fragmented, with tooling, documentation, onboarding, and reusable contract patterns spread across the ecosystem. This initiative addresses those issues through practical deliverables including cardano-init, an OpenZeppelin-style contracts library, Developer Portal improvements, bounties, outreach, and measurable DevX assessment. The ask of ₳3.6M is modest relative to the Net Change Limit, and the proposal includes milestone-based disbursement, Intersect administration, independent assurance, auditable treasury contracts, refund conditions, and prior treasury disclosure. While I recognise concerns about the wider IO funding package and potential overlap with other initiatives, this specific proposal is well aligned with long-term Cardano adoption and builder growth.
- Yes 2.1M ₳ No rationale
- Yes 2M ₳ Rationale
The long-term success of the Cardano network fundamentally depends on attracting and retaining developers, which in turn drives the number of DApps and monthly active users (MAU). Currently, the ecosystem is facing a major bottleneck with only about 550 active developers (growth rate is nearly 0) – lagging far behind competitors like Ethereum or Solana. We identify that the main cause stems from a poor developer experience (DevX): fragmented tools, scattered documentation, and a learning curve that is initially too steep.
This proposal directly addresses these painful challenges with a comprehensive suite of solutions: creating a rapid project initialization tool ('cardano-init'), building a template smart contract library (similar to OpenZeppelin), and unifying the Developer Portal. We evaluate that allocating 3.6 million ADA from the Treasury is a strategic investment that is fully justified, aiming to accelerate developer growth by at least 30% within 12 months.
Removing technical barriers will create a powerful development 'flywheel' for the entire ecosystem. Therefore, we believe that voting YES is essential to support the vision of expanding real-world utility and solidifying Cardano's position
- Yes 2M ₳ No rationale
- Yes 2M ₳ No rationale
- Abstain 1.9M ₳ No rationale
- Yes 1.8M ₳ No rationale
- No 1.8M ₳ Rationale
These initiatives are worthwhile but the ask is significant for what is being proposed. Looking across all the IO proposals this is not one I feel is a top priority for this budget cycle.
- Yes 1.7M ₳ No rationale
- Yes 1.7M ₳ No rationale
- Yes 1.7M ₳ Rationale
When new innovations are developed, it is difficult to know how to properly document for future utility. Some things you think are important end up being obvious, while others are not. I understand that this feels like a self inflicted problem, however it represents a growing pain rather than negligence.
- Yes 1.7M ₳ No rationale
- Yes 1.5M ₳ Rationale
I support this proposal because improving Cardano’s developer experience is a high-leverage investment that directly strengthens ecosystem adoption, utility, and long-term competitiveness. The proposal identifies well-known pain points such as fragmented tooling, weak onboarding, poor documentation, and lack of coordination, and presents a pragmatic, ecosystem-oriented plan to address them through shared infrastructure, canonical tooling, developer onboarding, and reusable contract libraries.
The initiative is also outcome-oriented, with measurable targets tied to developer growth, onboarding efficiency, and ecosystem expansion. I particularly support the focus on reducing time-to-MVP, improving onboarding for both Web2 and EVM developers, and consolidating existing community efforts instead of duplicating them.
While the treasury ask is substantial, the proposal includes milestone-based oversight, third-party assurance, and transparent delivery mechanisms. Given the strategic importance of attracting and retaining builders, I believe this is a reasonable and timely investment in Cardano’s long-term growth.
As a note, having met Robertino personally, I can vouch for his commitment, professionalism, and genuine passion for Cardano and its long-term success.
- Yes 1.5M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- No 1.3M ₳ No rationale
- Yes 1.2M ₳ Rationale
I vote YES because improving Cardano's developer experience is important for both technical progress and ecosystem growth. Developer activity is also part of Cardano's broader market signal: it matters to builders, users, and investors whether the ecosystem looks easy and attractive to build on. This proposal targets real friction points such as project setup, reusable contract libraries, developer documentation, onboarding, and bounty-funded tooling improvements, and the ask is relatively modest compared with the rest of the IO slate. I do note that the proposal can be confusing because it describes a six-month execution program while targeting improvement over a twelve-month horizon, and I cannot fully assess overlap with the other IO proposals until they are reviewed. My YES therefore comes with an expectation of clear public reporting on delivered tools, developer adoption metrics, overlap with other funded work, and maintenance ownership after the initial program.
- Yes 1.2M ₳ Rationale
IOG certainly asks for a lot, although some of the proposals are collaborations with other companies. I will go over the different proposals separately.
✅ Developer Experience
It’s important that developers who want to build on Cardano can do so as easily as possible. While I think this proposal could be done more cheaply, not getting it done would be much worse.✅ Cardano Upgrades
These upgrades will be beneficial for Cardano.✅ Consensus
Implementing Leios is important to handle the transaction volume we’ll have once Cardano is used for many use cases. I would have preferred to see Simple Leios implemented directly (with a longer time frame), though, rather than first spending time and resources on Linear Leios.✅ L2 Scalability
We need solid L2 solutions for high transaction volume applications that would be too expensive on L1 (in terms of resources and fees).❌ Cardano High Assurance
I like this proposal, but unfortunately, under the current available NCL and taking other proposals into account, difficult choices need to be made. I will approve this proposal if it is resubmitted under a new NCL.✅ Cardano Maintenance
This proposal is too expensive for what it delivers, but alternative nodes are not yet mature enough to risk stalling the development of cardano-node.✅ Plutus
Further improvements and extensions of smart contract capabilities are important.➖ Blockfrost
I think the free tier should be subsidized by the revenue Blockfrost generates from its paid tiers, like any other company using a freemium model. I do recognize the decentralization efforts made, although funding for this was already received in the past; hence I will abstain.➖ Pogun
There are multiple alternatives for Bitcoin DeFi on Cardano being developed, and it remains to be seen which one will perform best and attract the most users. The treasury should not provide a grant for this, but since the earnings would be used to repay the funds, it is essentially a loan. Given that additional revenue would later be shared with the treasury, it could even be considered an investment. However, I am not sure whether the current NCL allows for this kind of investment at the moment. If a higher NCL becomes available, I would vote in favor of this proposal, but for now I will abstain. - No 1.1M ₳ No rationale
- Yes 1.1M ₳ No rationale
- No 1M ₳ Rationale
Cardano’s developer experience is a strategic bottleneck; after 30+ years in technology-market environments, I also know that **developer growth is not purchased by slogans, coordination workshops, or another branded umbrella.
**
We all know that Cardano onboarding remains fragmented, the EUTXO learning curve is real, and the proposal’s own figures — roughly 550 Cardano developers versus Ethereum adding 1940 developers/year and Solana 884/year — describe an adoption gap we cannot ignore. On that basis, my issue is not necessity; my issue is investability. **I can accept that ₳3.6M may be plausible for serious engineering, but I cannot accept that size of ask when the central ROI claim of an overestimated 30%+ developer growth merely rests on asserted causality rather than hard proof and tangible successes. **Cardano already has the Developer Portal, Intersect programs, Cardano Foundation involvement, TxPipe expertise, and so forth, which makes supporting this proposal a high risk of paying a large prime contractor to integrate what should first be openly mapped, competitively tendered, and funded through targeted maintainer bounties. I also, frankly, worry that whoever owns the “canonical” onboarding path can shape developer defaults, standards, and mindshare. I've been burnt before with similar situations in my professional career, and I'm not comfortable handing that role to any single large incumbent without stronger proof of neutrality, open governance over content, and anti-duplication discipline.
- Yes 985.7K ₳ Rationale
Critical Infrastructure: Essential for maintaining the CLI, SDKs, and core tooling necessary to attract and retain dApp developers.
- Yes 955.2K ₳ No rationale
- Yes 947.9K ₳ No rationale
- Yes 941.2K ₳ No rationale
- Yes 922.9K ₳ No rationale
- Yes 920K ₳ No rationale
- Yes 860.4K ₳ No rationale
- Yes 818K ₳ Rationale
Reduces Technical Friction: Upgrading SDKs and compiler efficiency directly improves the building experience, aligning with our core objective to prioritize the accessibility of the blockchain.
Fosters LatAm Builder Ecosystem: Lowering the barrier to entry with better developer tools helps drive Latin American growth by encouraging local builders and increasing regional on-chain transactions.
Strengthens Core Resilience: Enhancing developer tooling directly impacts the scalability, security, and long-term viability of the global ecosystem.
Open-Source Tooling Continuity: Ensures maintenance of essential infrastructure components that the entire developer community relies upon daily.
- Yes 804.1K ₳ Rationale
This proposal tackles the concrete reasons developers do not stick around: fragmented tooling, poor documentation, and a slow path from zero to working project. Unified onboarding, a setup CLI, a contracts library, and ecosystem bounties are practical fixes to known problems. Small ask relative to the impact if it works.
- No 793K ₳ Rationale
Sounds great, but I don't care. IO was funded during the last major Intersect budget cycle with a long list of deliverables. Why wasn't all of this in competition for funding at that time if it was so bloody important. I'm not interested in cutting any more big checks from the Treasury with ADA at these price levels. Get your shit together and tell us what you want to accomplish as part of the primary budget cycle.
- Yes 785.2K ₳ Rationale
DevX is the primary bottleneck for Cardano; fixing it has first-order impact on adoption and revenue.
Proposal targets the right levers: tooling, onboarding, standard libraries, and coordination.
The “cardano-init” + OpenZeppelin-style contracts directly reduce time-to-MVP → highest ROI change.
Budget is modest relative to potential upside; milestone-based disbursement limits downside risk.
Main risk is execution/alignment, but structure with Intersect + bounties partially mitigates this. - Yes 765.1K ₳ Rationale
Relatively modest ask, practical DevX improvements, and clear potential to reduce builder friction
- Yes 762.8K ₳ No rationale
- Yes 762.6K ₳ No rationale
- Yes 738.5K ₳ No rationale
- Yes 733.1K ₳ Rationale
Reducing developer friction is essential for long-term ecosystem adoption and innovation. I vote YES.
- Yes 670.2K ₳ Rationale
Yes- this proposal focuses on improving the core developer experience on Cardano during a critical 6-month period for crypto adoption. At roughly ₳600k ADA per month (₳3.6M total over 6 months), the cost is relatively modest compared to many treasury proposals, while the upside could be significant
A PDF version of this rationale is also made available.
I’m voting yes because this proposal focuses on improving the core developer experience on Cardano during a critical 6-month period for crypto adoption. At roughly ₳600k ADA per month (₳3.6M total over 6 months), the cost is relatively modest compared to many treasury proposals, while the upside could be significant if easier tooling and onboarding attract more builders to Cardano. If the CLARITY Act and broader U.S. crypto regulation progress this year, ecosystems that are easiest to build on could see major growth in developers, apps, users, and institutional interest. This proposal directly targets Cardano’s biggest weakness today: onboarding and developer friction. Improving tooling, documentation, starter kits, and reusable smart contracts could help Cardano compete more effectively with Ethereum and Solana during an important adoption window.
- No 654.5K ₳ Rationale
no
- Yes 624.8K ₳ Rationale
Fiscal Responsibility Budget breakdown is 81% development and engineering, 1% legal, 1% infrastructure, 1% security/audits. Strategic Value & Ecosystem Fit, The problem is real and quantified: 550 Cardano developers growing at 82/year against Ethereum's 1,940/year
A PDF version of this rationale is also made available.
I'm voting yes because developer experience is where Cardano's flywheel either starts or stalls — and right now it isn't starting. Cardano has 550 active developers growing at 82 per year while Ethereum adds 1,940 per year. That's not a protocol quality gap. It's a friction gap between "curious developer" and "deployed DApp," and this proposal attacks that friction with tools, documentation, and coordination that no single ecosystem entity would build on their own.
Three specific deliverables align directly with priorities I've stated publicly. The cardano-init CLI, it meets builders where they are and removes the first-hour barrier that turns away Web2 and EVM developers before they ever see what the eUTxO model can do. The ContractsLibrary, built open-source and explicitly designed to ground LLMs and AI coding assistants on Cardano-native patterns, advances the CIP and schema normalization work that makes the ecosystem machine-readable and future-proof. The Developer HUB restructuring is optimized for both human onboarding paths and LLM agent access, this is a standard for infrastructure I believe is prerequisite to any serious adoption curve.
At ₳3,601,926 (~$864K at the proposal's stated $0.24/ADA reference rate), with 81% allocated directly to development and engineering. The implied team cost runs roughly $140K–$200K annualized per specialist across the stated disciplines, expensive? Yes, but competitive without being at a premium. Unspent funds return to the treasury under standard milestone-based Intersect governance. The disclosed execution risk, in the team not yet fully assembled, TxPipe partnership still exploratory is real, but it's precisely the kind of risk the milestone structure is designed to catch and correct before full disbursement. The data-driven diagnosis behind this proposal, 109 developer surveys and GitHub activity analysis, gives me confidence the team knows what they're building and why. - Yes 589.2K ₳ Rationale
Bears are for building. Voting yes to allow IO to level up Cardano through this proposal. We're going for #1