IO: Developer Experience Initiative

Rationale highlights

Why some of the largest DReps voted for and against, in their own words.

• Yoroi W₳llet

  Yes584.2M ₳

  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...

  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

  Yes435.8M ₳

  I vote YES for "IO: Developer Experience Initiative." Improving the developer experience is truly necessary, and I particularly appreciate the following four points: Based on demand research Defined targets for outcome KPIs (not process KPIs) A genuine...

  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に対応した施策
• Eternl DRep Committee

  No222.9M ₳

  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...

  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.

• Cardano Foundation

  No120.2M ₳

  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...

  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