DRepTalk
Sign in
Governance ActionsDiscussionsDRepsTreasury
Sign in
More ways to sign in

IO: Developer Experience Initiative

System 2mo ago1post
DReps 248 SPOs 0

248 DReps voted · 86 with a rationale

Open a row to read the rationale.

  • Yoroi W₳llet
    Yes 592.3M ₳ Rationale

    Summary

    Yoroi DRep revises its prior ABSTAIN to YES on “IO: Developer Experience Initiative”, following a reassessment of the balance between structural concerns and strategic urgency.

    Rationale

    The strategic case has become harder to set aside. Developer experience is time-sensitive, and the cost of a further delay to a well-motivated, empirically grounded programme is material. Yoroi now considers the delivery risks manageable relative to the importance of the goal, particularly given IO’s demonstrated capacity to execute at this scale.

    Monitoring will be our accountability mechanism. Since our structural concerns have not been formally resolved, Yoroi intends to hold IO to refining its success metrics and coordination approach through the oversight process. A YES vote is not an endorsement of every element of the delivery design.

    Conclusion

    Yoroi votes YES. We are making this revision openly, acknowledging that the proposal is unchanged and that our prior concerns remain live. Our judgement is that supporting this initiative now, with active oversight, is more responsible than deferring again on grounds that may not be resolvable before the vote closes.

  • YUTA
    Yes 428.5M ₳ Rationale

    I vote YES for "IO: Developer Experience Initiative."

    Improving the developer experience is truly necessary, and I particularly appreciate the following four points:

    1. Based on demand research
    2. Defined targets for outcome KPIs (not process KPIs)
    3. A genuine cross-ecosystem collaboration model
    4. AI-enabled initiatives

    ーーー

    私は「IO: Developer Experience Initiative」にYESを投票します。

    開発者体験の向上は本当に必要であり、次の４点を特に評価しています。

    1. 需要調査に基づいている
    2. 成果KPI（not プロセスKPI）のターゲットが定義されている
    3. エコシステム横断の本気の協業モデル
    4. AIに対応した施策
  • Blockdaemon
    Yes 328.3M ₳ No rationale
  • EMURGO
    Yes 297.4M ₳ Rationale

    Summary

    EMURGO as a DRep revises its prior ABSTAIN to YES on the treasury withdrawal titled “IO: Developer Experience Initiative”, with rationale outlined below.

    Rationale

    EMURGO previously abstained on this proposal, citing concerns around attribution methodology and the reliance on third-party coordination for key outcomes. We are revising that position to YES. The proposal has not changed, and we do not withdraw those concerns. What has changed is our assessment of their weight relative to the cost of continued inaction on one of the most important challenges facing the ecosystem.

    Developer experience is a direct determinant of builder adoption, and the empirical foundation of this proposal, grounded in developer survey data and cross-ecosystem growth analysis, remains stronger than is typical for initiatives of this kind. IO’s track record in delivering complex ecosystem programmes gives us sufficient confidence that the delivery risks flagged in our abstain are manageable in practice. We will monitor progress against the stated outcomes and expect IO to refine coordination and attribution commitments as the programme unfolds.

  • CryptoCrow
    Yes 240.8M ₳ No rationale
  • Eternl DRep Committee
    No 221.8M ₳ Rationale

    Overview of EDC vote on IO + Tweag proposals:

    ❌ IO: Developer Experience Initiative
    ✅ IO: Cardano Upgrades
    ✅ IO: Consensus Initiative
    ✅ IO & Ensurable Systems: Cardano Maintenance Initiative
    ❌ IO & Midgard Labs: L2 Scalability Initiative
    ➖ IO: Cardano High Assurance Technical Collaboration
    ✅ IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability
    ❌ Blockfrost: Maintenance and Next Generation Indexing
    ❌ Pogun: Capital Without Compromise
    ❌ Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028
    ✅ IO: Cardano Vision 2026: Human Centred, Scalable, Post Quantum Secure - IO Research

    Combined:

    ✅ YES: 147.7m ADA / 35.5m USD
    ❌ NO: 74.0m ADA / 17.7m USD
    ➖ ABSTAIN: 13.1m ADA / 3.1m USD

    All proposed initiatives sound like nice-to-haves for Cardano; some are essential for Cardano's momentum. The asks on almost all of the proposals are too high. That's why we had to triage and prioritize the essentials over the nice-to-haves, allow for a remainder on the NCL, and leave room for other vendors to enter the race for this year's budget.

    We want to make it clear that a NO does not mean we are against the proposed tech. Quite the opposite, for example we'd love to look into Midgard and Pogun for Eternl. We also appreciate the work Blockfrost is doing, trying to replace itself with decentralized tech.

    But we need to leave some part of the NCL for other vendors and initiatives.

  • Sebastien Guillemot セバ
    Abstain 174.4M ₳ Rationale

    I feel like this initiative is maybe a bit too vague in its current form.

    Some initiatives like the Developer HUB, Community Collaboration, Developer Outreach, etc. require a fairly different skill set and team than cardano-init and ContractsLibrary. Although I trust IOG to do both in a sense, I think Cardano needs some bold bets at the moment and I'd prefer to see some bold bet on a specific idea that the community can rally around for developer onboarding

    For example, I think "cardano-init" as described is not necessarily bad, but it won't really go deep enough to really solve some of the developer onboarding problems. In the pat few years, tools like yaci-devkit, dolos and utxorpc have made it much simpler to spin up node and start indexing, but how to make your Cardano project easy to index is still an unsolved problem. Other than some problems like Plutus not having events (making it hard to have a no-code way to index your app as you develop it, even with tools like utxorpc and dolos), even the orchestration about what transactions you need to make to setup your localhost testnet for your app are hard to specify. There have been attempts at this in Ethereum (ex: TheGraph, hardhat ignition), but they're hard to port to Cardano both because they're a bit old (use patterns and techniques that computer science in general can solve in better ways now), but also because Cardano doesn't have the same composability that people usually leverage when using an OpenZeppelin-like project to compose templates together. I think a more comprehensive solution would probably take some of these older ideas, some other attempts at this like EffectStream (fka Paima Engine), tx3, Starstream, etc. and try and figure out how to apply some of these ideas in the contract deployment setting (esp. in relation to what Cardano can do today, and possibly some upcoming features like nested transactions which may help with this)

    All that to say, I think some of these solutions are more complex to properly solve. Cleaning up tools like aiken-mdx so you can have an OpenZeppelin-like UI for seeing different contracts on Cardano to leverage any pre-existing tools to build your dApps is definitely a step in the right direction, but I think you would get more excitement from layout out a more comprehensive vision (even if your proposal cannot build the comprehensive vision in one shot, having a comprehensive vision would make it clearer for other developers, dReps, etc.. what you're trying to do, why this doesn't overlap with previously funded initiatives, and the background to decide if this is a good bet to make)

  • Everstake
    No 160.5M ₳ No rationale
  • Cardano Foundation
    No 135.1M ₳ Rationale

    This document includes the Cardano Foundation’s voting decisions and individual voting rationales for nine Treasury Withdrawal governance actions submitted by Input Output Global.

    A PDF version of this rationale is also made available.

    We have decided to create a unified document to record our votes as many of the initiatives are connected.

    We invite the proposers and anyone else from the Cardano Community to carefully review our individual rationales below per proposal, as well as the following table.

    Governance Action Title CF DRep Vote
    97. IO - Developer Experience Initiative NO
    98. IO - Cardano Upgrades YES
    99. IO - Consensus Initiative YES
    100. IO & Ensurable Systems - Cardano Maintenance Initiative ABSTAIN
    101. IO & Midgard Labs - L2 Scalability Initiative ABSTAIN
    102. IO - Cardano High Assurance Technical Collaboration YES
    103. IO & VacuumLabs - Enhancing Plutus - Performance, Correctness, and Usability NO
    104. Blockfrost - Maintenance and Next Generation Indexing NO
    105. Pogun - Capital Without Compromise YES

    Individual Rationales

    The following section contains all nine individual voting rationales for the above-mentioned proposals.

    97. IO - Developer Experience Initiative

    Summary

    The Cardano Foundation votes NO. We are eager to collaborate on DevX, but this proposal is expensive, lacks financial granularity, and risks duplicating ecosystem efforts. We encourage returning with a leaner, more detailed, and coordinated resubmission addressing the points as recommended below.

    Rationale Statement

    We recognize that developer onboarding is a critical vertical, and we appreciate the proposers targeting legitimate ecosystem pain points. While we fully support the overarching goals, we cannot approve this treasury withdrawal in its current form due to the following structural and financial concerns:

    1. Costs Lacking Granularity: The request for approximately 900k USD is exceptionally high for a 6-month timeframe. The budget lacks a meaningful Full-Time Equivalent (FTE) breakdown, allocating 81% to a broadly categorized "Development & Engineering" bucket. This makes it difficult to distinguish between community bounties, hackathon prizes, and administrative overhead, hindering our ability to evaluate financial proportionality.Creating CLI tooling, cleaning documentation, and building contract templates can be achieved in a cost-effective way which does not require a budget of this size.
    2. Overlap with Active CF and Intersect Initiatives: The proposal intends to restructure the "Developer HUB" using the Developer Portal as its primary entry point. The Developer Portal is already actively maintained, funded, and strategized by the Cardano Foundation alongside Intersect committees. While we are highly receptive to ecosystem contributions, requesting nearly 900k USD to duplicate or restructure ongoing work is inefficient. We would welcome collaboration on this workstream to improve cost efficiency.
    3. Severe Execution Risk: The proposal requests funding for only six months. The proposer indicates that the engineering team for these workstreams has not yet been established and will be hired using the funds released from this withdrawal. Setting up a new team and familiarizing them with the necessary ecosystem intricacies will conservatively consume a significant portion of this short timeframe, jeopardizing the delivery schedule. A future proposal would be significantly strengthened by establishing an upfront execution structure. Clearly identifying, aligning, and sharing ownership with ecosystem partners from the outset ensures precise accountability for all deliverables.
    4. Lack of Long-Term Ownership and Maintenance: There is no clear transition strategy for the resulting products (such as cardano-init or the contracts library) after the initial six-month funding period. The ecosystem requires continuous, ongoing feedback and maintenance for developer tools, rather than a highly expensive, short-term sprint that risks leaving behind abandoned infrastructure if subsequent funding is not secured.
    5. Open Source Fragmentation: While cardano-init is explicitly designed as an aggregation layer to unify and elevate existing ecosystem tools rather than replace them, its long-term value hinges heavily on sustained community buy-in. The proposal’s strategy for allocating bounties and incentives to existing tool maintainers is a strong step toward coordination. However, the primary risk shifts from community fragmentation to the execution of integrations: we must ensure that external toolmakers actively maintain these integrations over time so the aggregator remains a reliable, up-to-date entry point for new developers.
    Conclusion

    The Cardano Foundation votes NO. While the ambition to improve Cardano's developer experience is valued, this proposal's steep cost, execution risks, and overlapping scope prevent us from approving it in its current form. To secure approval, a resubmission must be leaner, more cost-effective and provide a granular FTE budget breakdown for financial transparency. It should also integrate with active Cardano Foundation and Intersect initiatives to avoid duplicating ongoing work, establish an execution structure with a pre-identified team to ensure delivery within the tight six-month window, and outline a strategy for long-term maintenance and community buy-in.

    98. IO - Cardano Upgrades

    Summary

    The Cardano Foundation votes YES. CIP-159, CPS-23, and Native Babel Fees have potential to improve L2 reserves, protect against volatility, and improve onboarding. Despite certain budget and execution concerns, we view the 13.1M ada ask as an acceptable investment.

    Rationale Statement

    We recognize the impact these three platform-level capabilities will have on Cardano’s economic models and ecosystem growth. We are voting YES based on the following technical and strategic assessments:

    1. Critical Infrastructure and Economic Resilience: The CIP-159 (Account Address Enhancements) upgrade bridges the gap between UTXO and Account models. By solving the minUTxO constraints, it enables micro-fee collection, cheaper DeFi batcher operations, and introduces new smart contract paradigms more familiar to EVM developers. Furthermore, it is a prerequisite for seamless L2 reserve management. CPS-23 (Multi-Asset Treasury) enables the Cardano Treasury to hold stablecoins or other native assets, which is a next step for long-term sustainability. It could protect the ecosystem's funding runway from ADA price volatility and introduce the potential for diverse treasury holdings.
    2. Native Babel Fees and Onboarding: While non-native (smart contract-based) Babel fees currently exist within the ecosystem, they have struggled to gain significant traction. Allowing users to interact with Cardano DApps using stablecoins or bridged assets without first acquiring ADA will hopefully be a driver for mainstream institutional and retail adoption.

    3. Feedback for Ongoing Alignment: While we support funding this initiative, there are elements of this proposal which raised concerns and we wish to offer feedback.

    Implementing CIP-159 fundamentally alters Cardano's accounting model. With alternative nodes like Amaru and Dingo actively in development, introducing such massive ledger changes requires careful coordination. Making frequent, significant modifications directly onto the Layer 1 core ledger introduces substantial maintenance fatigue for open-source builders, which can be lessened with coordination. We urge IO to collaborate to establish a clear framework for alignment with other node implementation and material downstream tooling teams to prevent consensus fragmentation.

    Workstream 2 allocates roughly $565,000 USD primarily to design and draft the Multi-Asset Treasury CIP. For a design-phase deliverable, this is a premium investment. We expect this effort to feature rigorous, high-quality deliverables, contributions to improvements to the overall CIP process and extensive community consultation to reflect the amount.

    Workstream 3 includes integration with the Lace wallet. Given the use of treasury funds, we expect the IO team to ensure that the underlying infrastructure for Native Babel Fees is open and easily accessible for all ecosystem wallets, Tx builders (e.g., Mesh, Lucid Evolution), and indexers, rather than focusing support solely on its own products.

    Although these concerns are valid, we appreciate the dialogue with IOG on this proposal which contributed to this voting decision.

    Conclusion

    The Cardano Foundation votes YES. The combination of Account Enhancements, a Multi-Asset Treasury, and Native Babel Fees represents a step forward for Cardano's scalability, developer experience, and economic sustainability.

    99. IO - Consensus Initiative

    Summary

    The Cardano Foundation votes YES. Leios is important for scaling Cardano and long-term competitiveness. Despite concerns over budget opacity and prior funding overlaps, delaying this upgrade risks ecosystem stagnation. We approve to ensure development continuity.

    Rationale Statement

    We recognize the impact that the Consensus Initiative (Leios) will have on the network’s capacity. We are voting YES based on the following technical and strategic assessments:

    1. Essential Base Layer Scaling: Scaling through Leios is fundamentally positive and provides Cardano with a massive upgrade. To ensure Cardano remains competitive with newer Layer 1 blockchains in terms of throughput, upgrading the base protocol is non-negotiable. This prevents the network from adopting unsustainable design patterns, such as forcing all high-volume activity to Layer 2 solutions.
    2. Core Infrastructure Investment: This proposal is a direct investment in the core protocol infrastructure. The Leios research phase has produced solid, academic-level work fully in the spirit of a peer-reviewed blockchain.
    3. Development Continuity: Leios development requires highly specialized knowledge. Voting NO at this critical juncture would risk halting momentum, meaning expert engineering teams would need to be replaced or re-assembled at a later date. Approving this proposal ensures the unbroken continuation of the roadmap toward the Dijkstra era.
    Conclusion

    The Cardano Foundation votes YES. We recognize that Leios is a credible path available to meet Cardano's 2030 scaling ambitions. While we have significant concerns regarding the insufficiently detailed, escalating budget, the risk of derailing base-layer scaling is too significant.

    100. IO & Ensurable Systems - Cardano Maintenance Initiative

    Summary

    The Cardano Foundation votes ABSTAIN. We appreciate the dialogue with IOG on this proposal, which contributed to our voting decision. While continuous maintenance is important for long-term network stability, this 62.1M ada proposal presents fiscal uncertainty and the scope appears to duplicate funding of other concurrent initiatives.

    Rationale Statement

    While the critical importance of keeping the network operating securely is undisputed, our evaluation reflects several material concerns regarding the current formulation of the proposal:

    1. Lack of Budget Detail/Potential Duplications: This proposal bundles nine maintenance workstreams into a single budget, grouping 74% (46M ada) of the funds into a broad "Development" category, which, without a granular Full-Time Equivalent (FTE) headcount breakdown, limits the capacity to verify cost efficiency. Additionally, given that the same development teams contribute across multiple initiatives, there appears to be a funding overlap with resources already requested in the Upgrades, Plutus, Consensus, and Developer Experience proposals. Providing a more detailed budget breakdown would help the community in conducting a clear cost-benefit analysis and ensure there is no duplication of funding.
    2. Lack of Quantifiable Deliverables: The proposal functions structurally as an open-ended funding commitment lacking defined technical boundaries, presenting a deficit of tangible deliverables, milestones, or open-source repository evidence mapping out the work. Without clear engineering baselines, it acts as an unquantifiable blanket retainer that challenges our ability to properly assess the proposal.
    3. Substantial Budget Inflation: The requested amount of 62.1M ada (approximately 14.9M USD) represents a high allocation of treasury resources. Industry baselines indicate that these costs are significantly inflated relative to the actual operational overhead required for equivalent DevOps and core maintenance tasks.
    4. Structural Preference for Targeted Initiatives: The Cardano Foundation maintains a clear structural preference for a modular funding framework wherever possible. Funding generalized blanket proposals introduces fiscal uncertainty, whereas smaller, targeted sub-proposals (such as specific consensus, developer experience, or scaling layer initiatives) feature transparent line-item budgets and clearly defined milestones that allow for rigorous milestone-based verification.
    5. Node Diversity Risks: To support a healthy multi-client ecosystem, overarching services such as global network monitoring and core documentation (e.g., the Cardano Blueprint) should be gradually decoupled from node-specific maintenance to ensure a completely product-agnostic and inclusive infrastructure landscape.
    Conclusion

    The Cardano Foundation votes ABSTAIN. We appreciate the critical nature of network maintenance and the expertise of the proposing teams. However, we require greater financial transparency, and a more node-agnostic approach to ecosystem tooling in order to properly assess this proposal. If this proposal does not reach the required approval threshold, we ask the proposers to refine and resubmit. A resubmission would greatly benefit from a decoupled structure, detailed FTE allocations, and an independent oversight mechanism to ensure verifiable and neutral delivery.

    101. IO & Midgard Labs - L2 Scalability Initiative

    Summary

    The Cardano Foundation votes ABSTAIN. While Layer 2 scaling is important for enterprise DApps, the proposal's lack of budget granularity, contested IP, and unresolved 2025 milestones introduce uncertainty. While we do not oppose this proposal, we urge a refined resubmission if it does not pass.

    Rationale Statement

    We support the technological objectives and the necessity of Layer 2 scaling, however we require further clarity regarding the following uncertainties before we are able to support:

    1. Unclear Scope and Structural Bundling: The proposal bundles two Layer 2 technologies at different stages of their respective product lifecycles into a single governance action. Furthermore, the financial distribution is skewed; despite being a titular focus of the initiative, the Midgard workstream receives only 9% of the allocated funding, while Hydra consumes approximately 73%.
    2. Milestone Accountability and Prior Deliverables: Midgard's 2025 funded milestones under contract EC-0001-25 were previously reported as past due and paused. While new evidence was submitted on May 19 to claim milestones 2–5, these submissions remain pending final verification. Committing additional treasury resources without a fully finalized reconciliation of past deliverables introduces significant fiscal uncertainty.
    3. Budget Granularity and Potential Overlaps: The 10.4M ada request lacks a granular breakdown. The technical scope for Workstream 2 (Hydra) closely mirrors the team's existing public roadmap and open pull requests, making it difficult to isolate net-new work from previously funded core engineering efforts. Additionally, the 1.8M ada requested for a bespoke Data Availability (DA) prototype does not sufficiently clarify why existing modular alternatives are unsuitable.
    4. Technical, IP, and Organizational Risks: The proposal contains contradictory timelines regarding the Midgard mainnet launch (end of 2026 versus Q1 2027). Subject Matter Experts (SMEs) also noted unresolved authorship and payment disputes (e.g., PR #434) that introduce contested-IP risks. Finally, the legal distinction and relationship between "Midgard Labs" and Anastasia Labs require clarification to ensure accountability.
    5. Unsubstantiated Metrics and Commercial Dependencies: Performance claims such as "10,000+ TPS" are presented without concrete benchmarking data or baseline metrics. Furthermore, the proposal relies heavily on specific commercial partners (like Delta DeFi and Masumi) continuing to build, without providing contingency plans. Ideally, commercial entities utilizing the stack for enterprise applications should contribute to the hardening of the infrastructure they rely upon.
    Conclusion

    The Cardano Foundation votes ABSTAIN. We appreciate the dialogue with IOG on this proposal which contributed to our voting decision. We value the technical ambition of this initiative and respect the engineering teams involved, but we cannot support this proposal in its current state without proper budget breakdowns, clarity on IP, and clear accountability for past milestones. If this proposal does not reach the required approval threshold, we ask the proposers to refine and resubmit their initiative.

    102. IO - Cardano High Assurance Technical Collaboration

    Summary

    The Cardano Foundation votes YES. Automating formal verification is a strategic public good that reinforces network security. Despite significant concerns regarding budget opacity and adoption risks, the ecosystem benefits outweigh the reservations.

    Rationale Statement

    We support this proposal because it aligns with Cardano's core value proposition of security, correctness, and determinism. Our YES vote is grounded in the following primary drivers:

    1. Strategic Digital Trust Infrastructure: Cardano’s underlying smart contract model, based on Lambda calculus and determinism, is uniquely positioned for formal mathematical verification. Recent high-profile vulnerabilities in EVM-based DeFi protocols, such as the ~$300M Kelp DAO exploit, highlight that verifiable security is a strict prerequisite for institutional adoption. This enables a shift away from high-risk environments toward highly secure, institutional-grade DeFi applications.
    2. Universal Ecosystem Support via UPLC: The proposed automated verification tool, Blaster, operates directly on Untyped Plutus Core (UPLC). This architectural choice is strategic, as it avoids siloed development and simultaneously supports developers across the ecosystem, regardless of whether they write in Aiken, Plutus, or other high-level smart contract languages.
    3. Lowering the Barrier to Entry: Historically, formal verification has been restricted to specialized experts. By providing a Lean4-based verification enabler, integrating it directly into native toolchains (e.g., VS Code), and offering extended "one-click" containerized developer environments, this initiative significantly democratizes access to production-ready, secure smart contract development.
    4. AI-Agentic Workflow Readiness: As software engineering transitions toward AI-assisted development, the emphasis on robust Command Line Interfaces (CLIs) within this proposal provides a strong, secure foundation for future integration with autonomous AI agents, ensuring Cardano's toolchain remains forward-looking.
    5. Reusable and Auditable Components: The initiative focuses on d
  • CardanoYoda (MANDA Pool)
    No 93.3M ₳ Rationale

    As a DRep, I have decided to vote NO on the proposal: IO: Developer Experience Initiative.

    My rationale:

    I have already approved the significantly larger proposal IO & Ensureable Systems: Cardano Maintenance Initiative, which includes a broad scope and substantial budget. In my view, that proposal should already cover a meaningful portion of the activities described here.

    As a result, I am concerned about potential overlap between initiatives.

    One example is the “Engagement & Ecosystem support” category, which appears in multiple IO proposals without a clear definition or breakdown. It is not sufficiently explained what specific activities are funded under this category, who is responsible for them, and how they differ across proposals.

    This lack of clarity raises concerns about duplication of effort and inefficient allocation of Treasury funds.

    While I agree that improving developer experience is important, I do not fully agree with the premise that fragmented tooling and scattered documentation are currently the primary bottlenecks to building on Cardano.

    Modern development workflows increasingly rely on AI-assisted tools and aggregated knowledge sources, significantly reducing friction when navigating documentation.

    However, this does not diminish the importance of having accurate, complete, and up-to-date documentation.

    Cardano already has an official developer portal maintained by the Cardano Foundation: https://developers.cardano.org/

    It is important to maintain a single, well-maintained source of truth rather than introducing additional parallel documentation efforts that risk fragmentation and eventual obsolescence.

    Documentation should be treated as a standard responsibility of product delivery, not as a separate, recurring funding request. When new tools or protocols are released, high-quality documentation should be included as part of that work.

    Additionally, many of the proposed activities, such as improving tooling, maintaining libraries, running hackathons, and supporting developers, can and should increasingly be handled by the community and independent teams, rather than being centralized within IO.

    As Cardano matures, it is important to gradually reduce dependency on founding entities and enable a more decentralized ecosystem of contributors. Foundational entities should support and collaborate with the community, not dominate all areas of ecosystem development.

    There are also concerns regarding coordination across proposals. For example, Intersect has requested a significant budget (₳25.4M) that includes elements related to Pentad integrations. When multiple entities request funding for related or overlapping initiatives, it becomes difficult for DReps to assess scope, ownership, and efficiency. A more coordinated approach, potentially through joint proposals, would improve clarity and accountability.

    Overall, while this proposal addresses a relevant area, it introduces additional spending in areas that are already partially covered elsewhere or could be more effectively handled by the broader ecosystem.

    Given the limited Treasury budget, it is important to prioritize carefully. Over-allocating funds to centralized initiatives risks ensuring the sustainability of a single entity, rather than fostering the long-term growth and diversity of the ecosystem.

    In my view, a better approach would be to:

    • strengthen coordination between existing initiatives
    • ensure documentation is delivered as part of core development work
    • empower community-led efforts through targeted funding mechanisms
    • and maintain a balanced allocation of resources across infrastructure, ecosystem growth, and decentralization

    For these reasons, I am voting NO on this proposal.

    If you'd like to support my work, consider delegating to the MANDA pool and backing me as a DRep. Your support is the only way I can get time for governance.

    MANDA Pool ID:
    pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

    My DRep ID:
    drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

  • JAZZ
    Yes 92.1M ₳ No rationale
  • SIPO
    Yes 89.8M ₳ Rationale

    SIPO DRep votes YES on IO: Developer Experience Initiative.

    Governance Action ID: gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3qqfu3vtv
    DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
    Date: 2026-05-09

    SIPO supports this proposal as a focused, time-boxed investment in Cardano's most measurable structural weakness: developer growth. With approximately 550 active Cardano developers compared to Ethereum's average gain of 1,940 developers per year and Solana's 884 per year, the developer-acquisition gap is the leading indicator of every downstream ecosystem metric — DApp count, TVL, MAU, and protocol revenue. This six-month, ₳3.6M program addresses the gap with a concrete 30%+ developer growth rate target, structured around five practical deliverables.

    Why SIPO votes YES

    1. The diagnosis is grounded in survey data, not speculation. The proposal cites a survey of 109 Cardano builders identifying the root causes of subpar developer experience: fragmented tooling, scattered documentation, no "blessed path" for newcomers, steep EUTXO/FP learning curve, and lack of ecosystem coordination. These are solvable problems, and the proposal addresses each with a specific deliverable. Survey-based diagnosis is the discipline SIPO expects from infrastructure proposals.

    2. The five deliverables are pragmatic and complementary. (i) Community alignment with bounties to incentivize ecosystem-wide tooling improvements. (ii) "cardano-init" — a starter CLI that takes a new developer from zero to working project in minutes regardless of preferred stack. (iii) ContractsLibrary — OpenZeppelin-style ready-to-use smart contracts for major DApp categories. (iv) Developer HUB — unified onboarding via the Developer Portal, coordinated with Cardano Foundation and Intersect. (v) Measurement hackathon — quantitative validation of progress and identification of next priorities. Each delivers standalone value; together they remove the developer-funnel friction at multiple stages.

    3. Stewardship is distributed, not centralized in IO. The proposal explicitly collaborates with Intersect's Developer Advocate Program and explores a technology partnership with TxPipe to broaden delivery capacity and sustain capabilities across multiple capable organizations. This is the same Pillar 5 stewardship-distribution pattern SIPO supported in HLabs Pebble + Gerolamo and the Ensurable Systems co-venture in IO Cardano Upgrades.

    Governance and oversight structure is identical to the standard SIPO has approved on Amaru, Dingo, HLabs Pebble + Gerolamo, DeFi Liquidity Budget, and Orion Fund (Sundae Labs treasury-contracts framework, Intersect administration, 5-entity Oversight Committee, multi-signature disbursement, refund clause). At ₳3.6M, this is one of the smaller IO Treasury withdrawals in this round, with 81% Development allocation and explicit milestone-gated deliverables.

    Expectations (YES with binding operational commitments)

    • Measurement hackathon baseline and methodology: The proposal commits to a 30%+ relative growth rate KPI but its proxy is the Q4 2026 measurement hackathon. SIPO expects publication of (a) the baseline measurement methodology before the program starts, (b) the specific datasets and metrics being tracked (GitHub commits, npm downloads, NPS, time-to-first-MVP), and (c) the contamination controls referenced in the proposal — so the KPI is not retrospectively redefined.

    • TxPipe partnership transparency: The proposal mentions exploring a technology partnership with TxPipe but does not commit to it. SIPO expects either confirmation of the partnership scope (deliverables, budget share, IP arrangement) by Q3 2026 milestone gate, or transparent reporting of why the partnership did not formalize.

    • Integration with the Cardano High Assurance Initiative: cardano-init is referenced as the integration point for the High Assurance toolkit (Blaster + CBDE) plugin architecture. SIPO expects coordination between the two teams such that cardano-init's plugin system is designed in time and interface to accept the High Assurance toolchain, avoiding parallel reinvention.

    • Aiken / Pebble / other ecosystem language teams non-fragmentation: The proposal names community alignment as an explicit deliverable. SIPO expects active collaboration with Aiken, Pebble (HLabs), Scalus (Lantr), Futura (SAIB), and other ecosystem language teams — not a top-down IO-defined "blessed path" that fragments the language community.

    • Quarterly reporting in stable format: SIPO expects the same reporting discipline already standard on Amaru, Dingo, and HLabs.

    Closing

    Developer growth is the leading indicator of every downstream Cardano ecosystem metric. At ₳3.6M for a focused six-month program with concrete, measurable deliverables and explicit stewardship distribution to Intersect and TxPipe, this proposal is the highest-leverage adoption investment in this round. With expectations above treated as binding operational commitments, SIPO DRep votes YES.

    For these reasons, SIPO DRep votes YES.

    SIPO DRepとして、本提案「IO: Developer Experience Initiative」に賛成（YES）を投じます。

    Governance Action ID: gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3qqfu3vtv
    DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
    Date: 2026-05-09

    SIPOは本提案を、Cardanoの最も測定可能な構造的弱点である「開発者成長」に対する集中的・期間限定の投資として支持します。Cardanoのアクティブ開発者は約550人、対するEthereumの平均年間獲得数は1,940人、Solanaは884人です。この開発者獲得ギャップはDApp数、TVL、MAU、プロトコル収益という全ての下流エコシステム指標の先行指標 (leading indicator) です。₳3.6M / 6ヶ月の本プログラムは、30%以上の開発者成長率という具体的ターゲットと5つの実用的成果物でこのギャップに対応します。

    SIPOがYESと判断する理由

    1. 診断は推測ではなく調査データに基づく。本提案は109人のCardano builderへの調査を引用し、subparな開発者体験の根本原因を特定しています：fragmented tooling、scattered documentation、初心者向けの「blessed path」不在、EUTXO/FPの急峻な学習曲線、エコシステム調整の欠如。これらは解決可能な問題であり、本提案は各々に具体的な成果物で対応します。調査ベースの診断は、SIPOがインフラ提案に期待する規律です。

    2. 5つの成果物は実用的かつ相補的。(i) Community alignment + bountyによるエコシステム全体ツール改善のインセンティブ。(ii) "cardano-init" — 新規開発者を数分で zero から動作するプロジェクトまで持っていく starter CLI（任意のスタック対応）。(iii) ContractsLibrary — 主要DAppカテゴリ向けの OpenZeppelin スタイル ready-to-use スマートコントラクト。(iv) Developer HUB — Developer Portal を中心とする統合 onboarding（Cardano Foundation・Intersect と協調）。(v) Measurement hackathon — 進捗と次の優先順位の定量的検証。各々が単独で価値を持ち、組み合わさって developer funnel の摩擦を複数段階で除去します。

    3. Stewardship はIO単独ではなく分散型。本提案はIntersectのDeveloper Advocate Programとの協業、およびTxPipeとの技術パートナーシップの探索を明示し、デリバリー能力と持続性を複数組織に分散することにコミットしています。これはSIPOがHLabs Pebble + GerolamoとIO Cardano UpgradesのEnsurable Systems co-ventureで支持したPillar 5 stewardship分散パターンと同じです。

    ガバナンス・監視構造はSIPOがAmaru、Dingo、HLabs Pebble + Gerolamo、DeFi Liquidity Budget、Orion Fundで承認した標準と同一です（Sundae Labs treasury-contractsフレームワーク、Intersect管理、5エンティティOversight Committee、マルチシグdisburse、refund clause）。₳3.6Mは本ラウンドの中でIO Treasury withdrawalsの中でも小規模、81% Development配分、明示的にmilestone-gateされたデリバリー。

    期待事項（YESには拘束力のある運用上のコミットメントを伴う）

    • Measurement hackathonのベースラインと方法論：本提案は30%以上の相対成長率KPIにコミットしていますが、その proxy はQ4 2026のmeasurement hackathonです。SIPOは(a) プログラム開始前のベースライン測定方法論、(b) 追跡される具体的データセットと指標（GitHubコミット、npmダウンロード、NPS、time-to-first-MVP）、(c) 提案書で参照されている contamination controls — の公開を期待します。KPIが事後的に再定義されないように。

    • TxPipeパートナーシップの透明性：本提案はTxPipeとの技術パートナーシップを「探索中」と述べているが確定はしていません。SIPOはQ3 2026マイルストーンゲートまでに、(a) パートナーシップのスコープ確認（成果物、予算配分、IP取り決め）、または (b) パートナーシップが成立しなかった場合の透明な報告 — のいずれかを期待します。

    • Cardano High Assurance Initiative との統合：cardano-initは High Assurance toolkit（Blaster + CBDE）プラグインアーキテクチャの統合点として参照されています。SIPOは両チーム間で、cardano-init のプラグインシステムが High Assurance toolchain を受け入れる時間的・interface 的整合性を持って設計されることを期待します。並行的な再発明を回避するために。

    • Aiken / Pebble / その他エコシステム言語チームとの非分断：本提案は Community alignment を明示的成果物として挙げています。SIPOはAiken、Pebble (HLabs)、Scalus (Lantr)、Futura (SAIB)、その他エコシステム言語チームとの能動的協業を期待します — 言語コミュニティを分断するトップダウンのIO定義「blessed path」ではなく。

    • 安定フォーマットでの四半期報告：Amaru、Dingo、HLabsで既に標準となっている報告規律を期待。

    結び

    開発者成長は全てのCardanoエコシステム指標の先行指標です。集中的な6ヶ月プログラムに対する₳3.6M、具体的で測定可能な成果物、IntersectとTxPipeへの明示的なstewardship分散 — 本提案は本ラウンドで最も高レバレッジな採用投資です。上記期待事項が拘束力のある運用上のコミットメントとして扱われることを前提として、SIPO DRep は本提案に賛成（YES）を投じます。

    以上の理由により、SIPO DRepとして本提案に賛成（YES）を投じます。

  • Army of Spies
    Yes 89.3M ₳ Rationale

    Cardano desperately needs to improve developer onboarding. At this price tag, I can get behind an initiative "directly targeting a 30%+ improvement in developer growth rate."

  • BTBF_XSP
    Yes 89.2M ₳ Rationale

    Cardano's future depends directly on the number of builders on it. Developer growth on Cardano is stagnant and trails other ecosystems. Improving developer experience is essential to making Cardano usable infrastructure, and this proposal addresses those barriers directly — so I vote YES.

  • Dumpling🥟
    No 77.3M ₳ Rationale

    并非当前要务。

  • drep1yg343cyuckg...
    Yes 76.1M ₳ Rationale

    Support DevEx that improves the actual path from idea to working Cardano transaction, especially documentation and reusable material that make LLM-assisted development effective. e, docs quality, bounty output, and whether the material helps builders ship.

    A PDF version of this rationale is also made available.

    Support DevEx that improves the actual path from idea to working Cardano transaction, especially documentation and reusable material that make LLM-assisted development effective. We recommend focusing on Youtube lectures and documentation for LLM-assisted development instead of hosting workshops, live classes, and hackathons. The value is not workshops for their own sake; it is reducing onboarding time and making serious builders productive without insider hand-holding. Must measure developer onboarding time, docs quality, bounty output, and whether the material helps builders ship.

  • ranket
    Yes 74.7M ₳ Rationale

    there is the practical issue that there is no developer that can fully absorb the risk of ADA price fluctuations. I am aware of concerns regarding the speed of development, etc. However, I believe that this would only be the case if an alternative development group with a proven track record were to propose it. In some cases, it is possible that the new group could negotiate with IO and Charles after the proposal is approved.

  • Dave
    No 71.3M ₳ Rationale

    I vote NO. Developer experience must be a standard deliverable, not a retrospective fix. Rapid AI advancements already multiply our talent pool, risking obsolescence. The KPIs misalign with actual on chain volume, whilst vague bounties risk favouritism. Outputs do not justify the opaque cost.

    A PDF version of this rationale is also made available.

    I am voting NO on the Developer Experience Treasury Withdrawal. As an active builder within the Cardano ecosystem, I intimately understand that a seamless developer experience is paramount. However, I fundamentally disagree with treating it as a costly, retrospective fix. Instead, I firmly believe that exceptional developer experience must be an inherent prerequisite, woven into the fabric of all future funded proposals. If we are deploying millions to construct core infrastructure, intuitive tooling and comprehensive documentation must be standard deliverables from the outset. If they are absent, I consider the development unfinished and of an unsatisfactory standard, and therefore cannot in good conscience support its funding via the Treasury.

    Furthermore, the technological landscape has shifted dramatically. With the rapid evolution of AI capabilities, navigating and building upon Cardano has become exponentially more efficient in a remarkably short timeframe. AI serves as a formidable force multiplier, meaning our historically constrained pool of developer talent now possesses the capacity to operate as a significantly larger workforce, priced highly competitively alongside established structures of expertise. Allocating capital to this specific tooling now risks discounting further AI innovation, which could quite easily render this proposal's deliverables obsolete and result in a regrettable misallocation of funds. Consequently, I do not consider this initiative a priority at this present juncture.

    Additionally, I hold significant reservations regarding the metrics and execution strategies outlined within the proposal. A thirty percent increase in sentiment or onboarding speed offers no guarantee of a corresponding rise in Total Value Locked, Daily Active Users, or indeed on chain transaction volume, which are the fundamental metrics that ultimately drive protocol revenue. Relying upon subjective barometers such as Net Promoter Scores is inherently precarious. Such metrics are easily skewed by positive bias environments, such as hackathons or incentivised surveys, potentially masking a stark lack of genuine technical adoption. Moreover, the proposed framework for community bounties lacks the necessary rigour. The absence of a transparent methodology or an independent board to select recipients inadvertently invites the risk of favouritism, whereby capital might be directed towards familiar entities rather than the most impactful innovators.

    Finally, my mandate for strict fiscal prudence applies equally to this request. The proposal seeks in excess of three million six hundred thousand ADA, with nearly three million swept broadly into an opaque development category, completely lacking a granular breakdown of headcount or hourly rates. Ultimately, in my opinion, I do not believe the anticipated outputs justify this immense financial outlay. Given the swift advancements in AI and our broader ecosystem budget requirements, the timing for this specific request is, in my assessment, fundamentally flawed.

  • Martin Lang
    Yes 70.8M ₳ No rationale
  • SASA_nagamaru_ながまる
    Yes 68M ₳ Rationale

    I have decided to vote YES on this proposal.

    While I initially had concerns regarding prioritization under the current Treasury environment, after further consideration I believe this proposal represents a reasonable long-term investment into Cardano’s ecosystem foundations.

    I still believe that expanding adoption, liquidity, real economic activity, and business opportunities remains one of Cardano’s highest priorities. However, sustainable ecosystem growth ultimately requires both demand-side expansion and a developer environment capable of efficiently onboarding and retaining builders.

    As initiatives such as Bitcoin DeFi, Midnight, stablecoins, interoperability, and institutional integrations continue to evolve, Cardano will increasingly need a smoother and more standardized development experience in order to fully capitalize on those opportunities.

    From that perspective, improving fragmented tooling, consolidating documentation, simplifying onboarding, and establishing clearer development pathways are all meaningful contributions toward Cardano’s long-term competitiveness.

    I also recognize that this proposal includes relatively concrete deliverables, milestone-based oversight, ecosystem coordination, measurable KPIs, and accountability structures, which gives the initiative a stronger level of execution credibility compared to many broader or less-defined ecosystem proposals.

    For these reasons, although I still believe prioritization discussions remain important under the current Treasury environment, I ultimately believe supporting this proposal is reasonable as part of strengthening Cardano’s long-term growth and developer ecosystem.

    僕は本提案に対してYESで投票します。

    当初は、現在のTreasury環境における優先順位の観点から慎重に考えていましたが、改めて検討した結果、本提案はCardanoの長期的な基盤強化として一定の合理性があると判断しました。

    僕自身、依然としてCardanoにおいて最優先で取り組むべきなのは、採用拡大、流動性、実需、経済活動、そしてビジネス機会を増やしていくことだと考えています。一方で、持続的なエコシステム成長のためには、需要側の拡大だけでなく、開発者をスムーズに受け入れ、定着させられる開発環境の整備も同時に重要であると感じています。

    特に、Bitcoin DeFi、Midnight、ステーブルコイン、相互運用性、機関導入などが今後本格化していく場合、Cardano側にもより整理され、標準化された開発体験が求められるようになると思います。

    その観点から見ると、分散したツール群の整理、ドキュメント統合、オンボーディングの簡素化、開発導線の明確化などは、Cardanoの長期的な競争力向上に繋がる重要な取り組みであると考えています。

    また、本提案は比較的具体的な成果物、マイルストーンベースの管理体制、エコシステム間の協調、測定可能なKPI、監査・説明責任構造などが明示されており、実行面についても一定の現実性がある提案だと感じています。

    そのため、Treasury環境における優先順位の議論は引き続き重要であると考えつつも、Cardanoの長期的成長と開発者エコシステム強化の観点から、最終的に本提案を支持する判断をしました。

  • Hermes Stakepool Germany (HRMS)
    Yes 65.7M ₳ Rationale

    I rather like more specific proposals and since I abstained on the maintenance budget, my yes goes here for lower barrier developer experience which will hopefully overall help the chain long term

  • Peter Bui
    Yes 62.7M ₳ No rationale
  • Dori
    No 53.8M ₳ Rationale

    I'm voting NO on IOG's Developer Experience Initiative proposal.

    I agree that the activities covered in this proposal address an important area, reducing the onboarding friction faced by new developers. Setting up environments through cardano-init, providing reusable contracts via the ContractsLibrary, organizing onboarding content through the Developer HUB, supporting developers on Discord and GitHub, and funding bounties for external tooling maintainers are all activities that can contribute to ecosystem growth.

    That said, I have reservations about whether these activities warrant being elevated into a separate Treasury funding request. IOG is a specialized organization responsible for Cardano's core research and development, and it has already been allocated significant Treasury resources through multiple large-scale infrastructure, protocol, and tooling proposals. In my view, the documentation, community support, onboarding content, and tooling integration covered in this proposal fall into the category of work that should naturally be handled as a complementary part of those ongoing core R&D projects, rather than as a standalone funded initiative.

    Furthermore, a meaningful portion of this scope can be reasonably carried out by community contributors, OSS maintainers, and the existing efforts of the Cardano Foundation.

    For these reasons, I am voting NO on this proposal. I fully agree with the broader direction of improving developer experience, and I would be supportive of approaches where documentation and onboarding are naturally included as part of the standard deliverables of core development work, or where community contributions are activated through more targeted mechanisms.

  • Goofycrisp
    Yes 51.1M ₳ Rationale

    This is a relatively modest and well-targeted proposal addressing a real bottleneck for Cardano: developer onboarding, tooling, and usability. Improving the builder experience can create compounding benefits across the ecosystem by making it easier for new developers and teams to build, launch, and contribute. The scope is concrete, the ask is reasonable, and I believe this is a valuable investment in Cardano’s long-term growth.

  • Chris-O
    No 50.5M ₳ No rationale
  • AdaStat
    Abstain 49.8M ₳ Rationale

    I'm going to revisit this proposal a bit later. For now, I'm voting Abstain just in case I don't manage to do that before the deadline.

  • hix_coffeepool
    No 49.7M ₳ Rationale

    I am voting No on this proposal. As a DRep, I evaluate all treasury withdrawal governance actions against my published voting framework, with a focus on the healthy development and long-term sustainability of the ecosystem. This proposal does not meet the framework's requirements, and I am voting No on that basis.

  • drep1ytjz60rgwhk...
    Abstain 42.9M ₳ No rationale
  • PoolTool
    No 42.4M ₳ No rationale
  • drep1ygm9wxzrrdq...
    No 40M ₳ Rationale

    I don't think this proposal is necessary at this time. And even if it was the costs are too high. Hire two good devrels for a year for 100k each and let them build a developer hub -> 250k USD.

  • drep1yffcjs0njfe...
    Yes 38.1M ₳ No rationale
  • Linda - Cryptofly
    Yes 36.8M ₳ No rationale
  • MUEN
    Yes 34.4M ₳ Rationale

    必要ではありますが、価格が上がってからでもおそくはありません。財政事情が厳しい中でも、ネットワークの競争力を維持するためには優先度の高いと思うます。

  • Socious
    Yes 34.3M ₳ Rationale

    Socious votes Yes. At 3,601,926 ADA this is the smallest of IO's requests in this cycle, and arguably the highest-leverage. Cardano has roughly 550 active developers and little growth, while Ethereum has added on the order of 2,000 developers a year over the past six years. Developer count is the leading indicator of an ecosystem's future: more builders mean more applications, more users, and more protocol revenue, which in turn attracts more builders.

    The proposal sets a measurable target — a 30%+ improvement in the developer growth rate within twelve months — and funds five concrete outcomes, including a one-command project setup tool, an OpenZeppelin-style library of ready-to-use contracts, a unified onboarding experience in the Developer Portal, and a bounty programme aimed at the tooling pain points builders actually report.

    Socious particularly values that the proposal commits to a quantified outcome rather than vague "ecosystem growth". A small, accountable, well-targeted investment in the top of the developer funnel is exactly the kind of spending the Treasury should favour. Socious supports it.

    ソーシャスは本提案に賛成します。3,601,926 ADAという金額は今サイクルのIOの要求のなかで最も小さく、それでいて投資効果は最も高い部類に入ります。Cardanoの活発な開発者はおよそ550人で伸び悩んでいる一方、Ethereumはこの6年間で年あたり2,000人規模の開発者を増やしてきました。開発者数はエコシステムの将来を映す先行指標です。作り手が増えればアプリケーションが増え、利用者とプロトコル収益が増え、それがさらに作り手を呼び込みます。

    本提案は測定可能な目標、すなわち12か月以内に開発者の増加率を30%以上改善することを掲げ、五つの具体的な成果に資金を充てます。そこにはコマンド一つで使えるプロジェクト初期設定ツール、OpenZeppelin型のすぐ使える契約ライブラリ、Developer Portalでの一貫したオンボーディング、そして開発者が実際に挙げるツールの不満点に的を絞ったバウンティプログラムが含まれます。

    ソーシャスが特に評価するのは、曖昧な「エコシステムの成長」ではなく、数値で示した成果に踏み込んでいる点です。開発者の入り口に対する、小規模で、説明責任が明確で、的の絞られた投資は、まさにトレジャリーが優先すべき支出です。ソーシャスは本提案を支持します。

  • drep1yf2jzhuc4f7...
    Yes 32.3M ₳ Rationale

    Yes. Smallest IO slate ask at ₳3.6M. Funds dev onboarding: cardano-init CLI, contracts library, Developer Portal. Bounties go to ecosystem teams. Self-reported KPI flagged.

    A PDF version of this rationale is also made available.

    Voting Yes. This is the only piece of the IO slate that goes hard at the Adoption pillar. The work is concrete. A cardano-init setup CLI. An OpenZeppelin-style contracts library. A consolidated Developer Portal. A bounty program that pays existing ecosystem teams (Aiken, Pebble, Scalus, Lucid Evolution maintainers) to do what they already do best. That's the right shape for the pillar. At ₳3.6M it's the smallest ask in the slate, milestone-gated via the Intersect 2025 TRSC, with anything unspent going back to Treasury. Two things to flag. The 30% dev-growth-rate target is IO's own number, so future reports need an independent verifier and a clear source dataset. And six months won't be the end of it: bounty continuity, Portal maintenance, and CLI upkeep all imply follow-on asks. None of that changes the call. Same logic as my Yes on Pebble (TS/Web2 devs) and Dingo (Go devs). Onboarding new builders is the lever. Slate aggregation across the seven IO actions sits at about ₳141.9M, but each action stands alone. Yes.

  • Liqwid DAO
    Yes 31.3M ₳ No rationale
  • drep1y2xacakh0g8...
    Yes 31M ₳ Rationale

    I initially opposed this due to concerns about overlap with existing tools and unclear cost effectiveness, but after reassessing the role of developer experience in Cardano’s growth, I decided to change my vote to Yes.

    Additional Note:
    I had already changed my vote from No to Yes, but I mistakenly forgot to update the voting message. To correct this, I temporarily switched to Abstain in order to revise the comment, and then restored my vote to Yes.
    The sequence is No → Yes → Abstain → Yes.

  • drep1ygxeadaklzz...
    Yes 30.5M ₳ No rationale
  • FIMI
    Yes 29.3M ₳ No rationale
  • Cerkoryn
    No 28.2M ₳ Rationale

    As much as I agree with the intent of this proposal, I think the deliverables mentioned are not necessarily the best approach. DevEx is definitely lacking, but I think the best way to improve that is to invest heavily in alternate nodes that condense the tool stack and often come with their own RPC, API, or Indexer built-in. Additionally as far as smart contracts are concerned, I think the Cardano ecosystem greatly struggles from a lack of composability. Most of our existing dApps and protocols were designed in isolation from each other and thus don't interoperate well or share liquidity. Furthermore, there are several other proposals in this category aiming to solve the tooling/DevEx gap such as the Intersect Paid Open Source Model, the dOSPO and OMF program, and the Cardano Tooling DAO. I think the best path forward here is for these groups to combine forces and put together a joint proposal that will solve Cardano's DevEx woes. For that reason I'm voting NO on this proposal as it currently stands.

  • Drep One
    Yes 27.9M ₳ No rationale
  • TERA DRep
    No 27.4M ₳ No rationale
  • Blockjock (James Meidinger)
    Yes 26.1M ₳ Rationale

    Rationale — Developer Experience Initiative
    Header
    You do not get users without apps. You do not get apps without developers.
    Constitutional Gate
    Assessment: Pass
    The proposal supports ecosystem growth, developer expansion, and long-term competitiveness.
    It includes clear deliverables, milestone-based delivery, and a measurable target of 30% developer growth improvement. Treasury use is justified as adoption-enabling infrastructure.
    Decision Declaration
    Vote: YES — High leverage, low cost, critical gap.
    This is one of the stronger ROI proposals relative to its size.
    Core Rationale
    Cardano remains harder to build on than many competing ecosystems. Tooling is fragmented, onboarding is slow, and developer growth is not where it needs to be.
    This proposal addresses that gap through practical DevX improvements: faster project setup, reusable contract libraries, portal unification, bounties, and developer measurement.
    Strategic Alignment
    The proposal aligns with adoption, ecosystem growth, DeFi expansion, builder retention, and long-term competitiveness.
    Developer experience is not optional tooling. It is the beginning of the ecosystem flywheel.
    Economic Impact
    More developers can lead to more applications, more users, more transactions, and more protocol revenue.
    The proposal is relatively low cost at ₳3.6M and targets a high-leverage constraint: builder onboarding.
    Execution Risk
    Key risks include weak ecosystem coordination, poor adoption of new tools, continued tooling fragmentation, and hiring or contributor delays.
    These risks are mitigated by bounty incentives, collaboration with Intersect and TxPipe, direct developer feedback, and an open contribution model.
    Accountability
    The proposal includes 5 clear deliverables: bounty-driven improvements, cardano-init, a reusable contracts library, Developer Portal unification, and a measurement hackathon.
    The measurable 30% developer growth target gives this proposal a clear success benchmark.
    Stablecoin Utilization
    The proposal does not appear to include an explicit stablecoin treasury strategy.
    This is a neutral but still missed optimization. Bounty payouts, contributor payments, and delivery costs would benefit from stable budgeting.
    The proposer should consider converting an appropriate portion of received ADA into stablecoins to protect execution against downside volatility.
    The treasury disbursement process should also support stablecoin conversion where predictable payout amounts are needed.
    Hoping ADA remains at a certain price is not a strategy.
    End-User Lens
    For builders, this means faster onboarding, better tooling, reusable contracts, and lower friction to launch.
    For users, this means more applications and better product quality.
    For capital providers, a stronger developer base creates more places to deploy capital.
    Conditions to Change Vote
    This rationale would materially change if developer onboarding does not improve, tooling is not adopted, DevX remains fragmented, or ecosystem coordination breaks down.

  • drep1yguh6dsgx0g...
    Yes 25.9M ₳ Rationale

    This is a quick win for the developers on Cardano and with a reasonable budget.

  • Kyle Solomon
    Yes 25.2M ₳ No rationale
  • wolf31o2 (Chris Gianelloni)
    Yes 22.7M ₳ Rationale

    Deeper integration not only on day 1, but throughout development is necessary. However, we have to start somewhere. Let's go get those developers.

  • DINO
    No 22M ₳ No rationale
  • Duc Tiger
    Abstain 22M ₳ Rationale

    I do not agree with this GA, but I will vote Abstain instead of No because it conflicts with a GA that I am participating in.
    The developer experience problem this proposal addresses is real and well-documented. The underlying public strategy document draws on Electric Capital's Open Dev Data and the Cardano Foundation's 2025 Developer Survey of 109 builders, and proposes a difference-in-differences measurement design that is methodologically sound. I also accept that a use-case-level contracts library is technically distinct from Anastasia Labs's design-patterns (which provide on-chain generic patterns rather than full use-case implementations) and from the Maestro marketplace (which is a metadata registry). The need is genuine and the technical framing is defensible.

    My objection is to the proposal as a treasury instrument, on four grounds:

    • Budget opacity. Development at 81% (₳2.93M) is presented without any FTE-by-role breakdown, hourly rate, or split between IO personnel and the named external collaborators. For a ₳3.6M IOG ask, this falls short of the itemization expected of even standard Catalyst proposals.

    • Hidden bounty and hackathon flows. Community Bounties and Hackathon prize pools are explicitly merged into the personnel line. There is no separate budget line and no minimum guarantee, making it impossible to audit how much treasury funding actually reaches external contributors and hackathon participants.

    • Implausible audit allocation. The Security & Audits line of ₳36k (~$8.6k at proposal rate) cannot fund an independent third-party audit of five "ready-to-audit" smart contracts. The proposal defers real audit to a separate Cardano High Assurance governance action, which means these contracts may ship without independent audit if that action does not pass — undermining the OpenZeppelin-style positioning the proposal invokes.

    • Unbounded Reactive scope. The Reactive workstream covers "currently unidentified tooling" with no cap and no selection criteria committed in advance. This pattern is incompatible with the budget-discipline expectations of Constitution v2.4 and the 2030 Vision, and an unexplained "Others" line further compounds the opacity.

    I also note that the partnership with TxPipe is described as "exploring," not signed, and that the strategy document lists only three supporting teams. Several core deliverables — cardano-init (overlapping TxPipe's Trix CLI), the Developer HUB (Cardano Foundation's existing portal), and the contracts library itself (overlapping with work Anastasia Labs and MeshJS already maintain) — could plausibly be delivered through distributed grants to teams with existing codebases and proven specialization, at lower cost and with stronger ecosystem alignment.

    This is not a vote against DevX work or against IO's engineering capacity. I encourage IO to resubmit with itemized FTE costs and rates, separate budget lines for community bounties and hackathon prizes, a named external auditor with adequate audit funding, a capped or removed Reactive line, and explicit MoUs with the partner teams whose work this initiative builds upon. I will support a revised version.

  • Hephaestus Stake Pool [HEPHY]
    Abstain 21.2M ₳ No rationale
  • SIDAN Lab
    Yes 21.1M ₳ No rationale