IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability

Rationale highlights

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

• Yoroi W₳llet

  Yes584.2M ₳

  Summary Yoroi DRep votes YES on “IO & VacuumLabs: Enhancing Plutus — Performance, Correctness, and Usability”. This is a change from Yoroi’s earlier ABSTAIN position, with the reasoning for that change set out below. Rationale Plutus evaluator accuracy...

  Summary

  Yoroi DRep votes YES on “IO & VacuumLabs: Enhancing Plutus — Performance, Correctness, and Usability”. This is a change from Yoroi’s earlier ABSTAIN position, with the reasoning for that change set out below.

  Rationale

  Plutus evaluator accuracy cannot be deferred.
  The conformance testing framework and Agda formalization ensure that any node implementation executes smart contracts identically and correctly. Without them, alternative node teams have no authoritative specification to test against as they progress toward production. That gap becomes harder to close the longer it remains unfunded, and that risk now outweighs the timing concern behind our original position.

  Distributed stewardship tips the balance.
  The VacuumLabs partnership spreads Plutus maintenance expertise across organisations, reducing single-point-of-failure risk in a critical part of the stack. Combined with IO’s track record of returning unused funds within the Intersect framework, both factors give Yoroi confidence in delivery at the requested scale.

  Conclusion

  Yoroi’s earlier abstention reflected a cautious moment in the cycle rather than a substantive objection to this work. Having reassessed the broader funding landscape and considered the sequencing implications more carefully, Yoroi changes its vote to YES and supports this proposal as a well-timed and well-governed investment in the foundations Cardano’s smart contract ecosystem depends on.

• YUTA

  Yes435.8M ₳

  I am voting YES on "IO: Cardano Upgrades," "IO: Cardano High Assurance Technical Collaboration," and "IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability." Cardano Upgrades: I believe that "Account Address Enhancement" and "Babel...

  I am voting YES on "IO: Cardano Upgrades," "IO: Cardano High Assurance Technical Collaboration," and "IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability."

  Cardano Upgrades: I believe that "Account Address Enhancement" and "Babel Fees" are ultimately necessary for the Cardano ecosystem. These will enable progress toward micropayments (and the resulting strengthened sustainability of DApps and wallets), various features that are convenient under an account model, payment of transaction fees in tokens other than ADA (and—though this is outside the scope of this proposal—ultimately the removal of minimum UTXO ADA in native asset transactions). As for "Cardano Multi-Asset Treasury," I think it's likely not necessary right now, but in the future, when ADA's price improves, we may want to convert the treasury's ADA back into stablecoins. Preparing now so that this can be executed if and when we want to may be a good thing, since no one knows when prices will move.

  Cardano High Assurance Technical Collaboration: Various AI-powered hacks have been occurring across different ecosystems, with many tokens being stolen and sold by hackers. This tool can strengthen security, which is one of Cardano's strengths. If we can use 13,078,578 ADA to reduce the likelihood of hacks exceeding 13,078,578 ADA in value, this potentially makes sense.

  Enhancing Plutus: Improving the efficiency of Cardano's smart contract functionality, strengthening security features, and enhancing the developer experience are all necessary pieces.

  ーーー

  私は「IO: Cardano Upgrades」「IO: Cardano High Assurance Technical Collaboration」「IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability」にYESを投票します。

  Cardano Upgrades：
  私は「Account Address Enhancement」と「Babel Fees」は最終的にCardanoのエコシステムに必要だと考えています。これにより少額決済（とそれによるDAppsやウォレットの持続可能性強化）やアカウントモデルによれば便利である様々な機能、ADA以外でのトランザクションフィーの支払い、（そしてこれはこの提案書の範疇ではないですが、そして最終的にはネイティブアセットTxにおける最小UTXO ADAの削除）へ進むことができます。私は「Cardano Multi-Asset Treasury」に関しては今必要ではない可能性が高いと思っていますが、将来的にADAの価格が改善した際に、トレジャリーのADAをステーブルコインに返還しておきたいと私たちは思う可能性があります。そう思った場合にそれが実行できるように準備をしておくことは良いことかもしれません。価格はいつ変動するか誰にもわからないからです。

  Cardano High Assurance Technical Collaboration：
  AIを活用したさまざまなハッキングが種々のエコシステムで発生し、多くのトークンがハッカーに盗まれ、売られています。このツールにより、Cardanoの強みの１つのセキュリティを強化することができます。13,078,578ADAを使用して、13,078,578ADA以上のハッキングの可能性を下げることができるのであれば、これは理にかなっている可能性があります。

  Enhancing Plutus：
  Cardanoのスマートコントラクト機能の効率性の向上、セキュリティ機能の強化、開発者体験の強化はいずれも必要なピースです。

• Sebastien Guillemot セバ

  No174.6M ₳

  I've thought a lot about this proposal, and decided to vote no. I'll share my rationale below: First off, as everybody knows, treasury spending is limited and there are a lot of proposals. That means that we have to triage features we want to build this...

  I've thought a lot about this proposal, and decided to vote no. I'll share my rationale below:

  First off, as everybody knows, treasury spending is limited and there are a lot of proposals. That means that we have to triage features we want to build this year. In my mind, Plutus is very stable. It's extremely rare that I meet a developer that wants to onboard onto Cardano, and the main blocker ends up being the Plutus usability. Almost always it's a consensus feature, a ledger feature, or a feature that Plutus fundamentally cannot deliver since it wasn't built for it (ex: ZK)

  That being said, Plutus does need to be maintained in three important ways even if working on it is not a core bet for how we will grow Cardano:

  1. Ensuring correctness (esp. against growing AI threats to code)
  2. Performance improvements (Plutus still powers many contracts, so improving Plutus performance benefits every user)
  3. Adding new precompiles (ex: upcoming post-quantum primitives being added to Cardano)

  However, all three of these features are more "maintenance" than "enhancing Plutus". In fact, the "Cardano Maintenance" proposal by IOG even mentioned Plutus Core maintenance in relation specifically to these points (and post-quantum work is proposed as different treasury proposals, so the cost of adding these precompiles I believe will largely not need to be covered by this proposal)

  I think Cardano needs some bold bets right now over maintenance. For example, if you gave developers the choice between making Plutus 1.5x faster or having event support for Cardano, I think a large number of people would pick events (and I think it would have a much bigger effect on Cardano adoption that slightly faster Plutus). However, adding events to Plutus requires a lot of rethinking about how things work (outside the scope of what this proposal is trying to do). I really don't think any of the "Developer experience" improvements mentioned in the proposal will move the needle at all (I think almost everybody will just dismiss these) compared to some of bigger ideas.

  However, I'll be monitoring this proposal to see how others vote. If it gets close to passing and I end up being the blocker, I may change my vote to avoid me being the blocker on this passing. I'm voting no mostly to signal my feeling on this proposal, but if the rest of the ecosystem wants this to pass as-is I do feel the Plutus team will use the funding honestly and will try to do their best with the funds received

• 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