IO: Developer Experience Initiative
248 DReps voted · 86 with a rationale
Open a row to read the rationale.
- No 536.5K ₳ Rationale
I Have seen the Cardano documentation degrade in quality since 2019, IOG has demonstrated a complete inability to foster an intuitive and easy to onboard development ecosystem.
Giving them more money to continue working on something they are demonstrated an inability to do well is like to throwing ADA down a well.
- Yes 534.3K ₳ Rationale
All IO request IMO at non-negotiable at the point, No other team in the world can deliver the results at a cheaper rate.
- Yes 525.8K ₳ No rationale
- Yes 487.1K ₳ No rationale
- No 481.5K ₳ Rationale
- Yes 473.6K ₳ No rationale
- Yes 467.4K ₳ Rationale
My Rationale for Voting “Yes”
I am voting YES on this proposal because I trust Robertino Martinez’s leadership. His experience with the Cardano Education Team gives him a clear understanding of where developers face challenges. This plan is not just theoretical; it directly addresses feedback from more than 100 active builders who pointed out that fragmented tools and poor onboarding are our main obstacles to growth.
Strategic Value & Alignment
The data shows that our developer growth rate is much lower than Ethereum’s and Solana’s. I believe this initiative is the missing piece we need. By aiming for a 30% increase in developer growth, we are not just supporting code; we are helping the whole ecosystem grow. More builders will create more DApps, boosting utility and economic stability.
Harmonizing the Community
I especially appreciate the focus on Community Alignment. Instead of starting from scratch, this project will:
- Align and Map Tooling: List all current ecosystem tools to set a baseline and cut down on duplication across teams.
- Incentivize Existing Maintainers: Offer bounties to encourage open-source contributors to improve their libraries, focusing on issues like hard-fork readiness and on- and off-chain interactions.
- Collaborate with Leaders: Work with Intersect and TxPipe so that several strong organizations help maintain these improvements.
Practical Deliverables
I am excited about the cardano-init CLI and the OpenZeppelin-style Contracts Library. These tools help new builders get started quickly, letting them go from nothing to a testnet MVP in less than two weeks. By bringing all the documentation together in the Developer Portal, we make it easier for people to follow a clear path, with support for modern AI tools.
Accountability
I trust this team to deliver because the proposal sets clear 2030 KPIs, uses milestone-based payments managed by Intersect, and ends with a hackathon to measure real improvements in the developer experience. This investment is needed to make Cardano the top choice for the next generation of builders.
- Yes 466.2K ₳ No rationale
- Yes 445.1K ₳ No rationale
- Yes 443.5K ₳ Rationale
I support all IO projects.
- Yes 441.7K ₳ No rationale
- No 438.7K ₳ No rationale
- No 426.2K ₳ Rationale
I’m a big fan of IO and everything they’ve accomplished over these nearly 10 years regarding Cardano. I believe it’s a top-tier company in terms of research, implementation, and blockchain, and I don’t question their capabilities at all.
However, as an observer—since I’m not deeply involved, but would still like to share my perspective. I feel that IO owes the community a clear, solid, and concise explanation of what has been achieved in previous governance actions. From my point of view, it’s very confusing; it feels like there are overlaps between this year’s proposals and last year’s, and it’s not clear at all.
It creates a lot of confusion, raising questions like: “Didn’t we already pay for this last year?” or “Why are we paying again if this was supposed to have been implemented already?” This starts to generate distrust across the community.I would like to see clear, measurable frameworks and informative checkpoints for all these governance actions something like a “Messari-style” State of Cardano report. I understand that a report like that isn’t cheap, but considering that we are about to spend nearly $40 million, the minimum expectation would be a clear report outlining what is intended to be achieved and what was accomplished last year.
This is a humongous amount of money, and it’s unreasonable for there to be so much confusion especially knowing that IO does very good work, yet their efforts start to be questioned. I wouldn’t like to see that happen. If producing such a report costs $50,000 or $100,000, then include it in the budget it doesn’t matter. There needs to be clarity and a formal way to track the return on what is being done. It’s simply too much money for this to remain so informal.
This time, I won't support this proposal. Market conditions do not allow me to do that.
- Abstain 385.6K ₳ Rationale
Abstaining, as I’m part of the Cardano Constitution Committee Tingvard.
Reading proposals and staying updated, just like you.
Thanks to all fellow DReps who are also doing the hard work.
Follow and DM me on X: @kenerik if you have any questions. - Yes 382.6K ₳ No rationale
- No 377.3K ₳ No rationale
- No 365.3K ₳ No rationale
- Yes 328.9K ₳ No rationale
- Yes 327.1K ₳ No rationale
- No 321.1K ₳ No rationale
- Yes 314.4K ₳ Rationale
I am voting YES. While I have serious concerns about IOG's budget opacity and the lack of a long-term maintenance plan, lowering the barrier to entry for developers is an absolute must-have. Tools like cardano-init and a battle-tested smart contract library are critical for ecosystem growth.
A PDF version of this rationale is also made available.
My initial inclination was to vote "NO" on this proposal, but after deeper reflection and past conversations with developers building on Cardano, I have decided to vote YES.
Cardano cannot thrive solely on theoretical capabilities; without an ecosystem of amazing DApps, having smart contract capability means very little. Right now, our main issue is a lack of users and real-world demand, and DApps are the vehicle to drive that demand. However, to get those DApps, we must attract more developers, and our current builders suffer from fragmented, outdated documentation.
Lowering the barrier to entry is no longer a "nice-to-have" - it is an absolute "must-have". Features like the cardano-init CLI, which allows developers to spin up a project in minutes (similar to a React app), alongside a battle-tested smart contract library, will vastly reduce the time from a developer's start to their MVP.However, my support comes with significant reservations that haven't been addressed so far:
- Budget Opacity: I am highly disappointed by how IOG presents its budget details, just like the rest of their proposals. A staggering 81% of the total requested amount is hidden behind a black box labeled "Development & Engineering teams", providing us with zero granular visibility.
- Entity Responsibilities: Ideally, an initiative focused on foundational developer experience and documentation should be spearheaded and funded by the Cardano Foundation (CF), as I believe this falls under their mandate. Since they haven't initiated this, I am glad IOG stepped in, but we need better alignment on responsibilities moving forward.
- Future Maintenance: The proposal lacks a clear post-completion maintenance plan. Who will maintain this code and documentation once this is finished and these funds are depleted? Without a dedicated strategy, we risk falling right back to where we are today with outdated resources.
Despite these serious concerns, the sheer utility of improving the developer experience outweighs the negatives. I am voting YES because we must equip our builders with the tools they desperately need to succeed.
- Yes 313.1K ₳ No rationale
- Yes 298.6K ₳ Rationale
Voting YES on ALL IOG Withdrawals
May 20th 2026
Summery
Nine treasury withdrawals from IOG totalling around 162M ada ($40M USD)
Important Citation
https://x.com/EdnStuff/status/2051321214728118360
EdnStuff said the following on May 4th 2026
I see the IO proposals as a package deal. But by all accounts I see most dreps only voting yes on a small selection of the 9. This is going to lead to some extremely lopsided, fragmented, and piecemeal results that will fall short of what we need on #Cardano $ADA.Charles quote tweeted saying
https://x.com/IOHK_Charles/status/2051376829949464792
Sadly, this is the end result of a piecemeal roadmap. It's an iPhone by committee, with people deciding whether they prefer the fingerprint sensor to wireless charging. You end up with a bizarre, useless product.Statement
There are a handful of people who, when they speak, I think it unwise not to listen to. Charles is one such person. His statement above makes this choice pretty easy.
While we need to foster a wide ecosystem of R&D firms, we cannot afford to jeopardize our relationship with our biggest contributor. It is obvious and undeniable that the long-term success of Cardano remains dependent on the continued efforts of IO.
I am voting for all of these IO proposals because Charles has made it clear that he does not believe Cardano can be successful without each of them, and it would be unwise to disregard his intuition.
Signed,
William DoyleYour friendly neighbourhood DRep!
$computerman
drep1yfpgzfymq6tt9c684e7vzata8r5pl4w84fmrjqeztdqw0sgpzw3nt
https://x.com/william00000010 - Yes 295.2K ₳ No rationale
- No 279.5K ₳ No rationale
- Yes 271.5K ₳ No rationale
- Yes 261.3K ₳ No rationale
- No 258.6K ₳ Rationale
Governance Action Review [EN]
1. Introduction
The Developer Experience Initiative is a Treasury Withdrawal proposal requesting ₳3,601,926 to fund a focused six-month program led by Input Output’s Cardano Business Unit. The proposal aims to improve Cardano’s developer tooling, documentation, onboarding experience, and ecosystem coordination, with a stated target of achieving a 30%+ improvement in developer growth rate. Its stated objective is to help a builder new to Cardano move from zero to an MVP on testnet in under two weeks, reducing the initial time investment needed to validate Cardano as a platform choice.
The initiative includes workstreams such as community alignment, developer outreach, cardano-init, Developer HUB, ContractsLibrary, community collaboration, measurement through a hackathon, and reactive work addressing high-ROI DevX opportunities. The proposal identifies fragmented tooling, poor documentation, steep learning curve, subpar developer experience, and lack of ecosystem coordination as the main problems affecting Cardano developer adoption and retention.
The proposed funding distribution allocates ₳2,929,680, or 81%, to Development & Engineering teams, ₳432,231, or 12%, to Engagement & Ecosystem support, and smaller allocations to infrastructure, security and audits, legal and compliance, operations and delivery, governance, and other costs. The proposal also states that a written off-chain legal contract will be created between Input Output and Cardano Development Holdings, administered by Intersect, with milestone-based delivery, third-party assurance, treasury reserve smart contract management, refund conditions, and public reconciliation of unused funds.
2. Governance Action Analysis
Positive aspects
The proposal addresses a real and relevant problem for Cardano. Developer experience remains an important bottleneck in the ecosystem, especially for new builders trying to move from zero to a functional MVP on testnet without spending weeks navigating fragmented documentation, inconsistent tooling, and a steep learning curve. In that sense, the general objective of the initiative is legitimate: improving onboarding, tooling, documentation, reusable patterns, and coordination around developer experience.
The proposal structures this objective around deliverables such as cardano-init, Developer HUB, ContractsLibrary, community collaboration, outreach, and DevX measurement mechanisms. These are potentially useful deliverables, and the proposal identifies an important need within the ecosystem.
The proposal also mentions collaboration with Intersect, Cardano Foundation, TxPipe, and community members, and states that the Developer Portal will be the main entry point for developers. This is positive and reduces part of the concern around institutional concentration.
Negative aspects
Recognizing that the problem is real does not mean accepting that this is the best structure to solve it. The main concern remains the budget. For a ₳3,601,926 withdrawal in a program lasting only six months, the level of financial detail is insufficient.
The proposal provides an aggregated distribution, with 81% allocated to “Development & Engineering” and 12% to “Engagement & Ecosystem support,” along with smaller categories such as infrastructure, security, legal, governance, and operations. However, this structure does not allow a clear evaluation of which amounts fund which deliverables, how many people will be involved, which roles will be hired, which rates or FTEs were assumed, how much will be allocated to bounties, how much will remain with IO, how much may go to external partners, and how each portion connects to verifiable milestones.
This point alone is sufficient to justify a vote against. The larger the Treasury withdrawal, the greater the required budget granularity should be. A multi-million-ADA budget should not depend on broad categories that make it difficult to evaluate proportionality, efficiency, and lower-cost alternatives.
The issue is not to presume bad faith or deny the team’s technical capability. The issue is that DReps must decide on the allocation of public ecosystem resources based on verifiable information, not generic institutional trust. Trust is great for friendships, not Treasury budgeting.
The proposal also appears to underestimate the current economic context of the ecosystem. Improving DevX may reduce technical friction for new developers, but it does not answer the most important question by itself: what will those developers find after being onboarded? The ecosystem is currently facing greater financial restriction, with several projects shutting down, funding becoming scarcer, Catalyst in transition or absent as a broad funding mechanism, and intense competition for available Treasury resources.
In this context, the ability to attract new builders depends not only on documentation and tooling, but also on real funding opportunities, liquidity, sustainability, and clear paths for projects to survive after the initial stage.
There is also a relevant strategic tension. The proposal aims to make it easier for new developers to enter the ecosystem, but at the same time it represents another significant Treasury withdrawal by an already established entity, in a cycle where a large portion of available resources is already being disputed or absorbed by major initiatives and consolidated actors.
This creates a practical contradiction: improving the ecosystem’s entry point is positive, but if the resources that could sustain new projects become increasingly concentrated in large institutional programs, onboarding may become only a partial solution to a broader problem. Cardano may have a better developer experience, but that does not guarantee retention if the economic environment remains unattractive for new teams.
Risks and concerns
There is an institutional centralization risk. Developer experience is not merely a neutral technical layer. It influences which tools are seen as standard, which workflows are recommended, which examples new builders follow, which libraries gain traction, which patterns become canonical, and which actors gain more influence over the formation of the next generation of Cardano developers. For that reason, governance of this layer matters.
Although the proposal mentions collaboration with Intersect, Cardano Foundation, TxPipe, and community members, the general structure of the initiative remains strongly led by IO. For an area as sensitive as onboarding, documentation, tooling direction, and canonical developer experience, a more neutral, open, and community-led approach would be more appropriate. Cardano Foundation, Intersect, Tooling DAO, dOSPO/OMF, targeted bounty programs, and community initiatives could play this role with lower institutional concentration risk.
This should not be read as a criticism of IO’s technical competence. The issue is different: the more strategic functions remain under the direct influence of founding entities, the harder it becomes to develop a broad, decentralized, and competitive execution layer in the ecosystem. In many cases, community or independent teams could deliver relevant parts of this work at lower cost, with greater proximity to active builders and greater diversity of approaches.
In the long term, practical decentralization requires critical functions to be distributed, not merely coordinated by large incumbents.
There is also a coordination concern with other initiatives. Multiple programs and proposals relate to tooling, open source, documentation, developer support, and developer experience improvements. The proposal itself includes broad items such as “Community Alignment,” “Developer Outreach,” “Community Collaboration,” and “Reactive” work. These may be useful, but they also make the scope elastic and potentially overlapping.
An initiative of this size should present more clearly how it differs from other workstreams, which responsibilities belong to IO, which would be executed by partners or the community, which specific gaps are not covered by existing initiatives, and why a centralized six-month proposal is preferable to a combination of bounties, RFPs, smaller grants, and open coordination.
3. Vote and Rationale
Vote: NO
The problem is not the existence of a proposal for DevX. The problem is the form. The proposal has merits, identifies a real need, and includes potentially useful deliverables, but it does not provide a sufficiently detailed budget, does not convincingly address the economic context of contraction and scarce funding for new builders, and concentrates an overly strategic layer under IO’s leadership.
The budget concern is the primary decision point. For a ₳3,601,926 Treasury withdrawal over six months, the proposal does not provide enough financial granularity to evaluate proportionality, efficiency, staffing assumptions, allocation between internal and external work, bounty amounts, partner distribution, or the relationship between each budget portion and verifiable milestones.
The current economic context further weakens the case for approval. Improving onboarding and tooling can help developers start building, but it does not solve the funding, liquidity, sustainability, and retention problem that new teams will face after entering the ecosystem.
The institutional structure also raises concerns. Developer experience shapes canonical tooling, documentation, workflows, libraries, and developer norms. Concentrating this layer under the leadership of an already established founding entity increases the risk of institutional centralization, even if the team is technically competent and even if collaboration with other actors is included.
The vote could be reconsidered if a future version presented substantially greater budget granularity, clearer separation of responsibilities among IO, partners, and community actors, stronger justification for why this centralized structure is preferable to bounties, RFPs, or smaller grants, and a more convincing response to the current funding constraints faced by new builders.
4. Conclusion
Developer experience is a legitimate priority for Cardano, and the proposal identifies a real ecosystem bottleneck. However, the current structure does not provide sufficient budget transparency, does not adequately address the broader economic constraints affecting builder retention, and concentrates a strategic developer layer too heavily under IO leadership. For these reasons, the appropriate vote is NO.
Revisão de Ação de Governança [PT]
1. Introdução
A Developer Experience Initiative é uma proposta de Retirada do Tesouro que solicita ₳3.601.926 para financiar um programa focado de seis meses liderado pela Cardano Business Unit da Input Output. A proposta busca melhorar o tooling, a documentação, a experiência de onboarding de desenvolvedores e a coordenação do ecossistema Cardano, com uma meta declarada de alcançar uma melhoria de mais de 30% na taxa de crescimento de desenvolvedores. Seu objetivo declarado é permitir que um builder novo na Cardano saia do zero e chegue a um MVP em testnet em menos de duas semanas, reduzindo o investimento inicial de tempo necessário para validar a Cardano como plataforma. :contentReference[oaicite:3]{index=3}
A iniciativa inclui frentes como alinhamento comunitário, developer outreach, cardano-init, Developer HUB, ContractsLibrary, colaboração comunitária, medição por meio de hackathon e trabalho reativo sobre oportunidades de alto ROI em DevX. A proposta identifica tooling fragmentado, documentação ruim, curva de aprendizado elevada, experiência de desenvolvimento abaixo do ideal e falta de coordenação no ecossistema como os principais problemas que afetam a adoção e retenção de desenvolvedores na Cardano. :contentReference[oaicite:4]{index=4}
A distribuição de recursos proposta aloca ₳2.929.680, ou 81%, para equipes de Development & Engineering, ₳432.231, ou 12%, para Engagement & Ecosystem support, e valores menores para infraestrutura, segurança e auditorias, legal e compliance, operações e entrega, governança e outros custos. A proposta também afirma que será criado um contrato legal off-chain entre a Input Output e a Cardano Development Holdings, administrado pela Intersect, com entrega baseada em marcos, garantia por terceiro, gestão via Treasury Reserve Smart Contract, condições de reembolso e reconciliação pública de fundos não utilizados. :contentReference[oaicite:5]{index=5}
2. Análise da Ação de Governança
Aspectos positivos
A proposta endereça um problema real e relevante para a Cardano. A experiência de desenvolvedores ainda é um gargalo importante do ecossistema, especialmente para novos builders que tentam sair do zero e chegar a um MVP funcional em testnet sem precisar atravessar semanas de documentação fragmentada, tooling inconsistente e curva de aprendizado elevada. Nesse sentido, o objetivo geral da iniciativa é legítimo: melhorar onboarding, tooling, documentação, padrões reutilizáveis e coordenação em torno da experiência de desenvolvimento.
A proposta estrutura esse objetivo em torno de entregáveis como cardano-init, Developer HUB, ContractsLibrary, colaboração comunitária, outreach e mecanismos de medição de DevX. Esses entregáveis são potencialmente úteis, e a proposta identifica uma necessidade importante dentro do ecossistema.
A proposta também menciona colaboração com Intersect, Cardano Foundation, TxPipe e membros da comunidade, e afirma que o Developer Portal será o ponto principal de entrada para desenvolvedores. Esse é um ponto positivo e reduz parte da preocupação com concentração institucional.
Aspectos negativos
Reconhecer que o problema é real não significa aceitar que esta seja a melhor estrutura para resolvê-lo. A principal preocupação continua sendo o orçamento. Para uma retirada de ₳3.601.926 em um programa de apenas seis meses, o nível de detalhamento financeiro é insuficiente.
A proposta informa uma distribuição agregada, com 81% para “Development & Engineering” e 12% para “Engagement & Ecosystem support”, além de categorias menores como infraestrutura, segurança, legal, governança e operações. Porém, essa estrutura não permite avaliar com clareza quais valores financiam quais entregáveis, quantas pessoas estarão envolvidas, quais funções serão contratadas, quais taxas ou FTEs foram assumidos, quanto será destinado a bounties, quanto ficará com IO, quanto poderá ir para parceiros externos, e como cada parcela se conecta a marcos verificáveis.
Esse ponto, por si só, já é suficiente para justificar um voto contrário. Quanto maior o saque do Tesouro, maior deve ser a granularidade exigida. Um orçamento multi-milionário não deveria depender de categorias amplas que dificultam a avaliação de proporcionalidade, eficiência e alternativas de menor custo.
A questão não é presumir má-fé ou negar a capacidade técnica da equipe. A questão é que DReps precisam decidir sobre alocação de recursos públicos do ecossistema com base em informações verificáveis, não em confiança institucional genérica. Confiança é ótimo para amizades, não para orçamento de Tesouro.
A proposta também parece subestimar o contexto econômico atual do ecossistema. Melhorar DevX pode reduzir a fricção técnica para novos desenvolvedores, mas isso não resolve sozinho a pergunta mais importante: o que esses desenvolvedores encontrarão depois de onboardados? O ecossistema está em um período de maior restrição financeira, com vários projetos fechando, funding mais escasso, Catalyst em transição ou ausente como mecanismo amplo de financiamento, e uma disputa intensa pelos recursos disponíveis no Tesouro.
Nesse cenário, a capacidade de atrair novos builders depende não apenas de documentação e tooling, mas também de oportunidades reais de financiamento, liquidez, sustentabilidade e caminhos claros para que projetos sobrevivam depois da fase inicial.
Há também uma tensão estratégica relevante. A proposta pretende facilitar a entrada de novos desenvolvedores no ecossistema, mas ao mesmo tempo representa mais uma retirada significativa do Tesouro por uma entidade já estabelecida, em um ciclo no qual boa parte dos recursos disponíveis já está sendo disputada ou absorvida por grandes iniciativas e atores consolidados.
Isso cria uma contradição prática: melhorar a porta de entrada do ecossistema é positivo, mas se os recursos que poderiam sustentar novos projetos forem cada vez mais concentrados em grandes programas institucionais, o onboarding pode se tornar apenas uma solução parcial para um problema mais amplo. A Cardano pode ter uma experiência de desenvolvimento melhor, mas isso não garante retenção se o ambiente econômico continuar pouco convidativo para novos times.
Riscos e preocupações
Existe um risco institucional de centralização. A experiência de desenvolvedor não é apenas uma camada técnica neutra. Ela influencia quais ferramentas são vistas como padrão, quais fluxos de trabalho são recomendados, quais exemplos os novos builders seguem, quais bibliotecas ganham tração, quais padrões se tornam canônicos e quais atores passam a ter maior influência sobre a formação da próxima geração de desenvolvedores Cardano. Por isso, a governança dessa camada importa.
Embora a proposta mencione colaboração com Intersect, Cardano Foundation, TxPipe e membros da comunidade, a estrutura geral da iniciativa permanece fortemente liderada por IO. Para uma área tão sensível quanto onboarding, documentação, tooling direction e experiência canônica de desenvolvedor, uma abordagem mais neutra, aberta e comunitária parece mais adequada. Cardano Foundation, Intersect, Tooling DAO, dOSPO/OMF, programas de bounties direcionados e iniciativas comunitárias poderiam exercer esse papel com menor risco de concentração institucional.
Esse ponto não deve ser lido como uma crítica à competência técnica da IO. A questão é outra: quanto mais funções estratégicas permanecem sob influência direta das entidades fundadoras, mais difícil se torna desenvolver uma camada ampla, descentralizada e competitiva de execução no ecossistema. Em muitos casos, equipes comunitárias ou independentes poderiam entregar partes relevantes desse trabalho com menor custo, maior proximidade com builders ativos e maior diversidade de abordagens.
A longo prazo, a descentralização prática exige que funções críticas sejam distribuídas, não apenas coordenadas por grandes incumbentes.
Também existe uma preocupação de coordenação com outras iniciativas. Há múltiplos programas e propostas relacionados a tooling, open source, documentação, developer support e melhoria da experiência de desenvolvedores. A própria proposta inclui itens amplos como “Community Alignment”, “Developer Outreach”, “Community Collaboration” e trabalho “Reactive”. Esses itens podem ser úteis, mas também tornam o escopo elástico e potencialmente sobreposto.
Uma iniciativa desse porte deveria apresentar com mais clareza como se diferencia de outras frentes, quais responsabilidades pertencem a IO, quais seriam executadas por parceiros ou comunidade, quais lacunas específicas não estão cobertas por iniciativas existentes, e por que uma proposta centralizada de seis meses é preferível a uma combinação de bounties, RFPs, grants menores e coordenação aberta.
3. Voto e Justificativa
Voto: NÃO
O problema não é a existência de uma proposta para DevX. O problema é a forma. A proposta tem méritos, identifica uma necessidade real e inclui entregáveis potencialmente úteis, mas não oferece orçamento suficientemente detalhado, não enfrenta de modo convincente o contexto econômico de retração e escassez de funding para novos builders, e concentra uma camada estratégica demais sob a liderança de IO.
A preocupação orçamentária é o principal ponto decisório. Para uma retirada de ₳3.601.926 do Tesouro ao longo de seis meses,
- Yes 257K ₳ Rationale
I am voting YES on “IO: Developer Experience Initiative” at 3,601,926 ADA. This is a focused, six‑month program aimed squarely at one of Cardano’s clearest bottlenecks: developer onboarding and retention. The proposal funds concrete deliverables—a stack‑agnostic “cardano‑init” starter CLI, an OpenZeppelin‑style contracts library with at least five ready‑to‑audit smart contracts, a unified Developer Portal “hub” optimized for key personas, a targeted bounty program for existing tooling, and a measurement‑oriented hackathon—all driven by prior survey data from 109 Cardano builders and the Cardano Foundation’s developer ecosystem findings. These outputs directly support a 20–30% uplift in developer onboarding and a ≥30% improvement in relative developer growth rate, which should translate into more DApps, higher MAU, and more transactions over time, aligning closely with Pillar 2 (Adoption & Utility) and Pillar 4 (Community & Ecosystem Growth) in the Cardano 2030 strategy.
The scope is well bounded and the budget is proportionate for the work: roughly 81% of the 3.6M ADA request goes to development and engineering, with the remainder covering ecosystem support, bounties, the measurement hackathon, and standard audit/oversight costs. Governance and constitutional compliance are strong—the withdrawal is denominated in ADA, sits within the 350M NCL, and is administered via Intersect’s audited TRSC/PSSC framework with auto‑abstain delegation, multi‑sig oversight, third‑party assurance, and a commitment to return unspent funds. Compared to many larger, less targeted proposals this epoch, this initiative offers a clear link between cost and ecosystem utility. My support comes with the expectation that IO keeps the work collaborative and upstream‑oriented (so it strengthens, rather than replaces, existing community tools) and that it publishes concrete DevX metrics—such as time‑to‑MVP, NPS, and adoption of the CLI, contracts library, and Developer Portal flows—so that any future DevX‑related asks can be evaluated against demonstrable impact. - Yes 253.3K ₳ No rationale
- Yes 245K ₳ Rationale
I find this to be a very fair value-per-ADA proposal from the IO portfolio at only 3.6M ADA. The cardano-init scaffolding CLI, OpenZeppelin-style ContractsLibrary, unified Developer HUB, community bounties, and controlled hackathon with a built-in quantitative baseline collectively address the leading causes of developer attrition from Cardano as identified by a survey of 109 active developers. The measurable KPI (30%+ improvement in developer growth rate benchmarked against a hackathon baseline) makes this one of the few proposals in the entire portfolio with genuine accountability built in.
- No 238.2K ₳ No rationale
- Yes 237.5K ₳ No rationale
- Yes 234.1K ₳ No rationale
- Abstain 215.5K ₳ No rationale
- Yes 212.5K ₳ No rationale
- No 208.6K ₳ Rationale
I'm increasingly concerned about Cardano's overall treasury spend rate, especially following the recent approval of the Draper/Dragon Orion Fund. To provide a necessary counter-balance, I am defaulting to NO on treasury withdrawals at this time.
This proposal (₳3.6 M) is important SDK improvement work, but it does not meet my strict criteria for approval right now. It is not core/critical infrastructure such as IO Hydra L2 production hardening or deliverables directly required to advance the Midnight partnership.
I will continue voting YES only on the highest-priority items that directly strengthen essential scaling and partnership infrastructure. - Yes 207.3K ₳ No rationale
- Yes 206.4K ₳ No rationale
- Yes 203.6K ₳ No rationale
- Yes 190.2K ₳ No rationale
- No 183.7K ₳ No rationale
- Yes 182K ₳ No rationale
- Yes 181.9K ₳ No rationale
- Yes 180.9K ₳ No rationale
- Yes 142.3K ₳ Rationale
I vote in favor of this proposal because it addresses a structural bottleneck in the ecosystem documented with quantitative evidence: the stagnation around 550 active developers
- Yes 137.3K ₳ No rationale
- Abstain 131.7K ₳ No rationale
- Abstain 131.6K ₳ No rationale
- Yes 127.9K ₳ No rationale