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

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

System 2mo ago1post
DReps 234 SPOs 0

234 DReps voted · 80 with a rationale

Open a row to read the rationale.

  • Yoroi W₳llet
    Yes 592.3M ₳ Rationale

    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
    Yes 428.5M ₳ Rationale

    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のスマートコントラクト機能の効率性の向上、セキュリティ機能の強化、開発者体験の強化はいずれも必要なピースです。

  • Blockdaemon
    Yes 328.3M ₳ No rationale
  • EMURGO
    Yes 297.4M ₳ Rationale

    Summary

    EMURGO as a DRep votes YES on the treasury withdrawal titled “IO & VacuumLabs: Enhancing Plutus — Performance, Correctness, and Usability”, with rationale outlined below. This represents a change from our earlier ABSTAIN position.

    Rationale

    EMURGO previously abstained on this proposal, citing caution around the volume of treasury commitments being considered in the current cycle. Having since assessed the aggregate spend across approved and pending proposals, we are satisfied that this proposal fits within responsible treasury limits and that the prioritisation concern that drove our earlier position no longer holds.

    On further reflection, the conformance testing framework and Agda formalization delivered here are not supplementary infrastructure. They are a prerequisite for alternative node implementations to verify their Plutus evaluators ahead of Dijkstra. Deferring this work creates a gap that compounds the longer it remains unfunded, and the sequencing risk of waiting now outweighs the timing concern that informed our abstention.

    The VacuumLabs co-venture further reinforces this position. Distributing Plutus maintenance expertise across multiple expert organisations reduces a single-point-of-failure risk in one of the most critical parts of the stack, and that structural benefit is time-sensitive as node diversity becomes a practical reality. Combined with IO’s demonstrated accountability within the treasury framework, EMURGO is satisfied this is a well-governed proposal that serves the ecosystem’s foundational interests. For these reasons, EMURGO changes its vote to YES.

  • CryptoCrow
    Yes 240.8M ₳ No rationale
  • Eternl DRep Committee
    Yes 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 セバ
    No 174.4M ₳ Rationale

    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

  • 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)
    Yes 93.3M ₳ Rationale

    As a DRep, I decided to vote YES on the proposal: IO & VacuumLabs: Enhancing Plutus – Performance, Correctness, and Usability

    My rationale:

    I support this proposal because it addresses real technical bottlenecks in Cardano's smart contract stack: execution costs, tooling friction, and formal correctness. These are fundamental issues that directly impact developer adoption, DeFi competitiveness, and long-term support for alternative node implementations.

    The most tangible part of this proposal is reducing Plutus execution costs.

    CIP-0156 (multiIndexArray) and CIP-0168 (BuiltinValue functions) introduce new built-ins that can reduce script complexity and lower execution costs for many common use cases.

    This matters because Cardano smart contracts are frequently criticized for high execution costs, transaction constraints, inefficient handling of multi-assets, and unnecessary complexity for common DeFi operations.

    These inefficiencies directly affect DEXs, lending protocols, stablecoins, and other on-chain applications that need to operate efficiently at scale.

    Formal correctness and alternative node support may be even more important over the long term.

    Without implementation-independent specifications, conformance testing, and stronger formal guarantees, alternative clients become significantly riskier to develop and maintain. Cardano cannot realistically pursue node diversity while lacking the tooling and specifications required to support multiple implementations safely.

    At the same time, Cardano has marketed formal methods as a major differentiator for years. This proposal suggests that some important parts of Plutus formalization still require further maturation. The IO should clearly explain what formal specifications already exist, what gaps remain, and why those gaps were not addressed earlier.

    This proposal must be considered in a broader context.

    The blockchain industry has repeatedly demonstrated how expensive weak smart contract tooling and insufficient verification can become. Major exploits across EVM ecosystems have resulted in billions of dollars in losses due to contract vulnerabilities, implementation mistakes, and weak security assumptions.

    While no system can eliminate risk, Cardano has consistently positioned itself as a platform built on higher assurance standards. Strengthening formal specifications, conformance testing, and smart contract correctness helps preserve that competitive advantage as the ecosystem grows and more value moves on-chain.

    However, this proposal is not perfect.

    I continue to see unnecessary fragmentation across IO proposals. Related work is often split across multiple proposals, while vague budget categories such as "Engagement & Ecosystem Support" continue to appear without sufficient breakdown. Future proposals should provide clearer boundaries between maintenance, developer tooling, and protocol upgrades.

    Despite these concerns, this proposal addresses important infrastructure gaps, improves Cardano's long-term competitiveness, and the requested budget is relatively reasonable compared with other IO requests.

    For these reasons, I support it.

    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 & VacuumLabs: Enhancing Plutus — Performance, Correctness, and Usability.

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

    SIPO supports this proposal as a coherent investment in the foundation that every Cardano smart contract depends on. Plutus is the compilation target of Aiken, Pebble, Scalus, Futura, and Plinth — its quality and capabilities directly determine what developers can build, how cheap their contracts execute, and how confident the ecosystem can be in correctness as alt-clients and DApps proliferate. Three workstreams advance Plutus across performance (UPLC capabilities and primitives), correctness (formal specification, conformance, security audit), and usability (compiler architecture, dependency simplification). The co-venture with VacuumLabs distributes Plutus stewardship across organizations rather than concentrating it in IO.

    Why SIPO votes YES

    1. Plutus improvements compound across every smart-contract language and DApp on Cardano. Built-in casing on Data, multiIndexArray (CIP-156, already ratified), additional BuiltinValue functions (CIP-168), and scope-check investigation directly reduce execution costs for every Cardano DApp regardless of source language, since all compile to UPLC. Cheaper on-chain execution improves capital efficiency for DeFi, opens up application designs that are currently uneconomical, and translates directly into competitive parity with execution layers that today win on cost.

    2. Property-based conformance testing is structural infrastructure for the node-diversity doctrine. The current Plutus conformance suite has 1,982 hand-written test cases. Property-based conformance extends this by generating test cases from formal specifications, giving alternative Plutus evaluator implementations far higher confidence that they agree with the canonical implementation across the entire program space. SIPO has voted YES on Amaru and Dingo on the basis that alternative full-node implementations are essential infrastructure insurance — those alt-clients require this property-based conformance framework to evolve safely as Plutus evolves.

    3. Continuous security auditing of the Plutus evaluator is non-discretionary at Cardano's scale. As DeFi and high-value DApps deploy on Cardano, the cost of any evaluator or costing bug grows in proportion to TVL. Investing in structured manual review of the evaluator and costing code, plus formalization of programmatic built-in types and functions in the Plutus metatheory, prevents incidents that would otherwise be expensive both financially and in trust. Catching a subtle costing bug before deployment is orders of magnitude cheaper than responding to one in production.

    4. VacuumLabs co-venture distributes Plutus stewardship beyond IO. Plutus has historically been near-exclusively maintained by IO. The VacuumLabs co-venture brings a specialist team with deep expertise in formal methods, security-critical Haskell development, and Cardano infrastructure to share maintenance responsibility. This is the same Pillar 5 stewardship-distribution pattern SIPO supported in HLabs Pebble + Gerolamo, IO Cardano Upgrades co-venture with Ensurable, IO Cardano Maintenance co-venture with Ensurable, and Cardano High Assurance with seven organizations. Plutus becoming maintained by a multi-org consortium is a structural improvement to ecosystem resilience.

    5. Workstream 3 developer experience improvements are immediately actionable. Eliminating the GHC plugin requirement, multi-version GHC support, removing native C library dependencies (blst, secp256k1) from Plinth, and clearer source-level error messages reduce setup friction without requiring a hard fork. These ship and benefit developers immediately upon delivery — complementary to CBDE (under SIPO YES vote in this round) which addresses the same friction at the toolchain level.

    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). 86% Development allocation. Net Change Limit compliant.

    Expectations (YES with binding operational commitments)

    • CIP-168 ratification dependency reporting: CIP-0168 (BuiltinValue functions) is not yet ratified at the time of submission. SIPO expects monthly reporting on CIP-168 ratification progress as a hard dependency for Workstream 1 deliverables, with a clear path if material specification changes occur post-implementation start.

    • Property-based conformance framework external alt-client adoption: The framework's value depends on alt-client (Amaru, Dingo, future implementations) adoption. SIPO expects publication of which alt-client teams are actively running the framework, with quarterly updates on test coverage and any alt-client / canonical disagreements surfaced.

    • Security audit findings transparency: The systematic audit of Plutus evaluator and costing code is one of the most valuable deliverables. SIPO expects the Q1 2027 final audit report to be published publicly with all findings, risk assessments, and remediation status — not an executive-summary-only release.

    • VacuumLabs responsibility split disclosure: The co-venture distributes work across IO and VacuumLabs. SIPO expects the responsibility split published by Q3 2026 milestone gate, including which workstreams VacuumLabs leads versus shares with IO.

    • Hard-fork-dependent vs hard-fork-independent deliverable separation: Workstream 1 features (casing on Data, multiIndexArray, BuiltinValue functions) require Dijkstra HF activation; Workstream 2 conformance and audits are hard-fork-independent; Workstream 3 developer experience improvements ship without hard fork. SIPO expects clear separation in milestone reporting so the community can evaluate progress on each track independently.

    Closing

    Plutus is the foundation of every Cardano smart contract and the verification target of the High Assurance Initiative. Investing in Plutus performance, correctness, and usability improvements compounds across every language, every DApp, and every alt-client implementation. The VacuumLabs co-venture adds the structural improvement that Plutus stewardship is no longer concentrated in IO. With expectations above treated as binding operational commitments, SIPO DRep votes YES.

    For these reasons, SIPO DRep votes YES.

    SIPO DRepとして、本提案「IO & VacuumLabs: Enhancing Plutus — Performance, Correctness, and Usability」に賛成（YES）を投じます。

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

    SIPOは本提案を、全Cardano smart contractsが依拠する基盤への一貫した投資として支持します。PlutusはAiken、Pebble、Scalus、Futura、Plinthのコンパイル先であり、その品質と機能は開発者が何を構築できるか、契約がどれほど安価に実行できるか、そしてalt-clientsとDAppsが普及する中でエコシステムが正確性にどれほど自信を持てるかを直接決定します。3つのワークストリームがPlutusをperformance（UPLC capabilities and primitives）、correctness（formal specification、conformance、security audit）、usability（compiler architecture、dependency simplification）で前進させます。VacuumLabsとのco-ventureは、Plutus stewardshipをIOに集中させるのではなく組織間に分散します。

    SIPOがYESと判断する理由

    1. Plutus改善は全smart-contract言語と全Cardano DAppに対して複利的に効く。Builtin casing on Data、multiIndexArray（CIP-156、既批准）、追加BuiltinValue functions（CIP-168）、scope-check investigationは、ソース言語に関わらず全Cardano DAppの実行コストを直接削減します（全てUPLCにコンパイルされるため）。安価なオンチェーン実行はDeFiの資本効率を改善し、現在経済的に成立しないアプリケーション設計を可能にし、現状コストで勝つ実行レイヤーとの競争パリティに直結します。

    2. Property-based conformance testingはノード多様性ドクトリンのための構造的インフラ。現在のPlutus conformance suiteは1,982の手書きテストケースを持ちます。Property-based conformanceはformal specificationsからテストケースを生成することでこれを拡張し、代替Plutus evaluator実装がプログラム空間全体にわたってcanonical実装と一致することへの遥かに高い信頼度を提供します。SIPOは代替フルノード実装が essential infrastructure insurance であるという基準でAmaruとDingoにYESを投じてきました — それらのalt-clientsは Plutus が進化する中で安全に進化するために本property-based conformance frameworkを必要とします。

    3. Plutus evaluatorの継続的security auditingはCardanoの規模では非裁量的。DeFiと高価値DAppがCardanoにデプロイされる中で、evaluator や costing バグのコストはTVLに比例して成長します。evaluatorとcosting codeの構造化された手動レビュー、およびprogrammatic built-in typesとfunctionsのPlutus metatheoryへの formalization に投資することは、財務的にも信頼面でも高コストとなるインシデントを防ぎます。微妙なcostingバグをデプロイ前に捕捉することは、プロダクションで対応するより桁違いに安価です。

    4. VacuumLabs co-ventureはIOを超えてPlutus stewardshipを分散する。PlutusはこれまでIOによってほぼ独占的に維持されてきました。VacuumLabs co-ventureは、formal methods、security-critical Haskell開発、Cardanoインフラの深い専門性を持つチームを maintenance 責任の共有に導入します。これはSIPOがHLabs Pebble + Gerolamo、Ensurable Systemsとの IO Cardano Upgrades co-venture、Ensurable Systemsとの IO Cardano Maintenance co-venture、7組織の Cardano High Assurance で支持したPillar 5 stewardship分散パターンと同じです。Plutusがmulti-org consortiumによって維持されるようになることは、エコシステムレジリエンスへの構造的改善です。

    5. Workstream 3 developer experience改善は即座にactionable。GHC plugin要件の撤廃、multi-version GHC support、Plinthからnative C library依存（blst、secp256k1）の除去、source-level error messagesの明確化は、hard forkを必要とせずにセットアップ摩擦を減らします。これらはデリバリー時に即座にship・開発者に benefit します — 本ラウンドでSIPOがYESを投じるCBDEと相補的（toolchain levelで同じ摩擦に対応）。

    ガバナンス・監視構造はSIPOがAmaru、Dingo、HLabs Pebble + Gerolamo、DeFi Liquidity Budget、Orion Fundで承認した標準と同一です。86% Development配分、Net Change Limit準拠。

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

    • CIP-168批准依存性の報告：CIP-0168（BuiltinValue functions）は提出時点で未批准。SIPOはWorkstream 1デリバリーのhard dependencyとしてCIP-168批准進捗の月次報告を期待します。実装開始後に大きな仕様変更が発生した場合の明確なパスを含めて。

    • Property-based conformance frameworkの外部alt-client採用：フレームワークの価値はalt-client（Amaru、Dingo、将来の実装）採用に依存します。SIPOはどのalt-clientチームがフレームワークを能動的に実行しているかの公開、テストカバレッジとalt-client/canonicalの不一致が表面化した場合の四半期更新を期待します。

    • Security audit findingsの透明性：Plutus evaluatorとcosting codeの系統的監査は最も価値のあるデリバリーの1つです。SIPOはQ1 2027最終監査レポートの全findings、リスク評価、remediation statusを伴う公開を期待します — executive summary のみのリリースではなく。

    • VacuumLabs責任分担の開示：co-ventureはIOとVacuumLa

  • Army of Spies
    No 89.3M ₳ Rationale

    Unfortunately, we cannot fund every single proposal that we would with infinite money. I am not yet persuaded this is the best use of funds at this time.

  • BTBF_XSP
    Abstain 89.2M ₳ Rationale

    The direction — lower script costs and stronger formal verification — is sound. However, the scope overlaps with and sits adjacent to other proposals in the same round (the Maintenance Initiative, High Assurance Collaboration, and Developer Experience Initiative), and there is insufficient basis to independently judge this proposal's incremental necessity and value for money. Unable to actively support either side, I abstain.

  • Dumpling🥟
    No 77.3M ₳ No rationale
  • drep1yg343cyuckg...
    Yes 76.1M ₳ Rationale

    Support deployable Plutus improvements: execution-layer robustness, modules and imports, events, standard interfaces, performance, correctness, and usability that reduce real smart-contract cost and risk.

    A PDF version of this rationale is also made available.

    Support deployable Plutus improvements: execution-layer robustness, modules and imports, events, standard interfaces, performance, correctness, and usability that reduce real smart-contract cost and risk. The caution is not the category; it is formal compiler-certifier work or academic assurance that drifts away from the actual production toolchain.

    I note, specifically, that my advice is that the current formal compiler-certifier workstream be thrown away in its entirety and the staff repurposed to either create a formal model of the actual implementation of the compiler (as opposed to their own definition of it from the specification) or to just working on improving the compiler / uplc itself.

  • 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
    Abstain 71.3M ₳ Rationale

    I ABSTAIN. I will not block community consensus, but cannot allocate 11.8M ADA here today. Many features await a future hard fork. Rather than funding heavy Plutus-specific refinements, I prefer directing capital toward driving adoption across Cardano's diverse alternative languages.

    A PDF version of this rationale is also made available.

    I am formally registering an ABSTAIN vote on the Plutus Language Capabilities and Developer Experience Treasury Withdrawal. I readily acknowledge the technical merit of this initiative, particularly the drive to enhance Plutus expressiveness, eliminate complex Nix dependencies, and integrate VacuumLabs as a strategic co-venture. However, I fundamentally do not feel this specific programme of work is an immediate requirement.

    Governance of a finite Treasury demands ruthless prioritisation and a keen awareness of opportunity cost. Whilst the deliverables outlined are undeniably valuable network optimisations, they are not existential necessities for the blockchain today. Indeed, the proposal explicitly notes that several core enhancements are contingent upon the future Dijkstra hard fork before they can even be activated on mainnet. Furthermore, from a strategic standpoint, I would prefer to direct our capital towards initiatives that drive immediate smart contract adoption by supporting the diverse array of alternative languages currently flourishing on our blockchain. Concentrating nearly twelve million ADA so heavily on Plutus-specific refinements feels misaligned.

    My decision is therefore rooted in optimal capital allocation rather than outright opposition. I firmly believe the substantial Treasury allowance consumed by a YES vote could achieve a far greater, more immediate impact elsewhere within our ecosystem. Nevertheless, I have no desire to stand in the way of broader community consensus, nor will I actively obstruct an initiative that many builders view as beneficial. By abstaining, I entrust the final decision to the electorate, preserving my principled stance on strategic prioritisation.

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

    I highly value this proposal’s direct focus on practical challenges currently facing Cardano, including Plutus performance improvements, developer experience enhancements, execution cost reductions, and stronger conformance testing in preparation for a future with alternative node clients. In particular, improvements such as execution cost reduction, the scope check investigation, removing the need for Nix, and compiler improvements could have a meaningful impact on both developer experience and real-world usability, making Cardano more competitive as a smart contract platform.

    I also support the collaboration with VacuumLabs and the broader direction of strengthening the Plutus ecosystem through a more distributed stewardship model rather than relying on a single organization. As Cardano continues to mature, improving core infrastructure and developer onboarding should remain an important priority.

    At the same time, given the current treasury environment, I believe some of the more research-oriented workstreams should continue to be evaluated carefully in terms of prioritization and scope. However, overall, I believe the proposal delivers substantial practical value and addresses areas of genuine importance for Cardano at this stage.

    For these reasons, I support this proposal.

    本提案は、Plutusの性能改善、Developer Experience改善、実行コスト削減、alternative node client時代を見据えたconformance testing強化など、現在のCardanoが抱える実用的課題へ直接アプローチしている点を高く評価しています。特に、execution cost削減、scope check調査、Nix不要化、compiler改善などは、開発者体験や実利用に与える影響が大きく、Cardanoの競争力向上に繋がる重要な取り組みだと考えています。

    また、VacuumLabsとの共同体制や、単一組織依存を減らしながらPlutus基盤を強化していく方向性にも賛同しています。Cardanoが今後さらに拡大していく上で、基盤改善と開発者体験向上は重要な優先事項の一つだと考えています。

    一方で、現在のトレジャリー状況を踏まえると、一部の研究寄り項目については優先順位やスコープを慎重に見る必要があるとも感じています。しかし、全体としては実装・実用寄りの価値が大きく、現在のCardanoにとって必要性の高い提案だと判断しています。

    そのため、本提案には賛成します。

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

    I am voting Yes on the Enhancing Plutus proposal.

    If improvements to the consensus algorithm and network are about the protocol's performance and security, then Plutus is about improving the foundational infrastructure layer that allows various products to be born on the Cardano network.

    In that sense, this proposal is just as important as protocol-level upgrades themselves, especially for enabling diverse products in the ecosystem to emerge and evolve.

    To me, Plutus is a truly special contract language in the smart contract space.

    We've been seeing a lot of hacks lately stemming from contract vulnerabilities, and a big part of why this happens is that most smart contracts dynamically change state at execution time. In that kind of structure, it's hard to fully predict what a transaction will actually do once it runs, so vulnerabilities end up being structurally baked in.

    Cardano, on the other hand, is built around declarative validation on the eUTXO model, which means you can verify all outcomes before execution. That gives it a fundamental edge in terms of security. Especially now, when AI is accelerating automated vulnerability discovery and exploitation, I believe that continuing to strengthen Cardano's structural security advantage is exactly what will drive broader product adoption.

    This proposal will lower transaction fees, open the door for a wider range of DApps, lower the barrier to entry for developers, and make it possible to build more efficient and sophisticated contracts. In particular, it lays the groundwork for new node implementations like Amaru to safely enter mainnet, and the transition of stewardship to VacuumLabs is, in my view, a real step toward reducing single-organization dependency on IOG and moving toward a structure where multiple specialist partners contribute to the core infrastructure.

    That said, the proposal lacks line-item budget breakdowns and FTE figures, and the transparency around VacuumLabs's share also needs improvement.

    I recognize that IO is a key organization driving this ecosystem forward, but I don't think its influence should serve as grounds for exempting it from the transparency and accountability standards that apply to every other proposer. If the opportunity arises, I'd appreciate it if more details on these points could be provided.

  • Goofycrisp
    Yes 51.1M ₳ Rationale

    Plutus and smart contract capabilities are central to Cardano’s developer ecosystem. While the technical details are difficult for non-developers to fully assess, this proposal appears to improve not only Plutus but also the broader smart contract environment, including other languages and tooling. In a highly competitive industry where chains are fighting for builders and users, improving Cardano’s smart contract stack is important enough to support.

  • Chris-O
    Yes 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
    Abstain 49.7M ₳ Rationale

    I am abstaining on "IO & VacuumLabs: Enhancing Plutus — Performance, Correctness, and Usability". Plutus execution cost reductions, formal specification, and conformance testing are legitimate Tier 2a work that directly affects smart contract economics for all Cardano users. IO and VacuumLabs are credible deliverers with relevant expertise. The technical content is sound. However, the current NCL has no category-based budget allocation, and this epoch already concentrates significant NCL consumption across multiple IO-related proposals, with Leios and CIP-159/Babel Fees already receiving Yes votes. Prioritizing consensus-critical and ledger-critical upgrades first, I abstain rather than vote Yes at this time. This is a judgment call under constrained conditions, not a rejection of the technical merit. I would support reconsideration of this proposal in the next cycle when NCL pressure is lower. Reference: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem/ [Japanese version follows] 私は、「IO & VacuumLabs: Enhancing Plutus — Performance, Correctness, and Usability」に棄権票を投じます。Plutus実行コスト削減・形式仕様・適合性テストはTier 2aのコアインフラ作業として正当であり、全DAppユーザーのスクリプト実行コストに直接影響する重要な改善です。IO・VacuumLabsは適切な実施主体です。技術内容そのものは評価しています。ただし現在のNCLに財源別予算配分がなく、同エポックのIO関連提案（Leios・CIP-159）にすでに賛成票を投じており、単一提案者へのNCL消費集中リスクが高まっています。コンセンサスおよびレジャー層の改善を優先する判断として、今回は賛成ではなく棄権とします。これは技術的評価の否定ではなく、現在の制約下での優先順位付けです。NCLの余裕が生まれる次サイクルでの再提案を支持します。参照: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem-jp/

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

    I believe this is a strong proposal. My only concern is that I do not understand from the provided documentation if this would then also be introduced to Cardano as an upgrade or if the funding of "IO & Ensurable Systems: Cardano Maintenance Initiative" is necessary for that.

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

    マイルストーンごとにIntersectが監査を行うため、進捗が悪い場合は支払いが止まる仕組みになっていて開発者成長率30%増という具体的なKPIを掲げている点は、他の提案に比べて「成果」を検証しやすいと言えます。

  • Socious
    Yes 34.3M ₳ Rationale

    Socious votes Yes. This 11,877,575 ADA proposal strengthens Plutus, Cardano's smart contract platform, across three connected fronts: language capabilities (new syntactic forms and primitives that lower script costs and unlock more efficient contract patterns), formal correctness (specification, conformance testing, and structured security review), and developer experience (a better compiler, lower setup friction, and clearer error reporting).

    These are the right priorities. Script cost and developer friction are concrete, recurring complaints from teams building on Cardano, and correctness work matters more — not less — as node diversity grows and alternative implementations appear. Funding all three together rather than in isolation is sensible, because they reinforce each other: cheaper scripts are only safe if correctness keeps pace.

    Structuring the work as a collaboration between IO and VacuumLabs distributes Plutus stewardship across expert teams rather than concentrating it, which is healthy for the platform's long-term resilience. With Intersect administering funds on milestones and unspent balances returning to the Treasury, Socious supports this proposal.

    ソーシャスは本提案に賛成します。本提案は11,877,575 ADAを投じ、Cardanoのスマートコントラクト基盤であるPlutusを、相互に関連する三つの側面から強化します。すなわち、言語機能の拡張（スクリプトコストを下げ、より効率的な契約パターンを可能にする新しい構文と組み込み関数）、形式的な正しさ（仕様策定、適合性テスト、体系的なセキュリティレビュー）、そして開発体験の改善（コンパイラの向上、導入時の手間の削減、より分かりやすいエラー表示）です。

    これらは妥当な優先順位です。スクリプトコストと開発者の負担は、Cardano上で開発するチームから繰り返し挙がる具体的な不満です。また正しさの検証は、ノード実装の多様化と代替実装の登場に伴い、重要性をむしろ増しています。三つを個別にではなくまとめて手当てするのは理にかなっています。スクリプトを安く動かせても、正しさが追いついていなければ安全とは言えないからです。

    この作業をIOとVacuumLabsの共同体制とすることで、Plutusの維持管理を一つのチームに集中させず、専門チームに分散できます。これは基盤の長期的な堅牢性にとって望ましい形です。Intersectがマイルストーンに基づき資金を管理し、未使用分はトレジャリーに返還されることも踏まえ、ソーシャスは本提案を支持します。

  • drep1yf2jzhuc4f7...
    Yes 32.3M ₳ Rationale

    Yes. ₳11.88M for Plutus: language capabilities (CIP-0156, CIP-0168, Data casing), Agda metatheory + property-based conformance enabling alternative node clients, and a standalone Plinth compiler removing Nix and C deps. Foundational L1 work that pays back to every DApp on Cardano.

    A PDF version of this rationale is also made available.

    Voting Yes. ₳11.88M for three workstreams on the Plutus smart-contract platform: language capabilities and primitives, formal verification and conformance, and developer experience. Plutus is the execution layer for every DApp on Cardano. Strong fit across the Cardano First framework:

    Scalability: Lead pillar. Cheaper execution per script means more transactions fit into the same block, the L1 throughput lever that does not require a hard fork or an L2. Casing on Data and the new built-ins (already-ratified CIP-0156 multiIndexArray, CIP-0168 BuiltinValue) replace verbose on-chain loops with single primitive calls. Scope-check removal (subject to Dijkstra hard-fork timing) recovers about 25% of script preparation overhead with no security cost.
    Decentralization: Workstream 2 extends the Plutus metatheory in Agda and builds a property-based conformance framework. This is what lets alternative node clients verify their Plutus evaluator agrees with the canonical one on edge cases. Compounds as Cardano's node diversity grows. Same logic as my Yes on Amaru, Dingo, Pebble + Gerolamo.
    Adoption: Workstream 3 replaces the GHC-plugin-based Plinth compiler with a standalone toolchain that does not require Nix or hand-installed C libraries. That has been the first-day stumbling block for developers coming from EVM or Web2 ecosystems. Single-command installation removes the friction.
    Governance Transparency: Standard Intersect 2025 TRSC pattern: milestone-gated disbursement, third-party Assurer, unspent funds return to Treasury.

    The VacuumLabs co-venture distributes Plutus maintenance across two expert teams rather than concentrating it in one. CIP-0156 and CIP-0168 are already community-ratified; this funds the implementation that closes those governance decisions.
    Risks I'm accepting with this Yes:

    Hard-fork-gated deliverables. Scope-check removal and new cost-model built-ins need Dijkstra to land. If Dijkstra slips, those deliverables are complete but economically inert until activation. The funded engineering still has standalone value.
    Workstream 2 overlaps the Maintenance Initiative. The Plutus evaluator security audit and conformance maintenance also appear in the ₳62.1M IO & Ensurable Systems scope. The boundary is not perfectly clean.
    Self-reported impact metrics. Cost-reduction and node-diversity claims need community measurement; the structural deliverables (CIP implementations, Agda formalization, standalone compiler) are independently verifiable.
    Slate aggregation. Part of the ~₳141.9M IO slate across seven actions. Each action stands alone.

    Foundational L1 work. Yes.

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

    I support this proposal because improving Plutus performance is critical for dApp growth, developer adoption, and Cardano’s competitiveness as a smart‑contract platform.

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

    One of Cardano's greatest strength is the research and formal verification that goes into Plutus scripts, especially in the age of AI where creating an exploit is easier than ever. The added efficiency and developer experience benefits are also worth the cost. This proposal is a YES from me.

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

    Rationale — Plutus Platform Expansion
    Header
    If the smart contract layer is expensive, hard to use, or unreliable, nothing built on top of it scales.
    Constitutional Gate
    Assessment: Pass
    The proposal supports sustainable ecosystem growth through developer enablement, smart contract efficiency, security, and tooling improvements.
    It includes defined workstreams, milestones, audits, formal verification, and milestone tracking. Treasury use is justified as core protocol infrastructure investment.
    Decision Declaration
    Vote: YES — Foundational, high necessity.
    This is base-layer infrastructure work needed for Cardano to remain competitive.
    Core Rationale
    This proposal funds improvements to Plutus capabilities, cost efficiency, formal correctness, security guarantees, and developer tooling.
    Plutus determines what can be built on Cardano, how quickly it can be built, and how expensive it is to operate. Improving this layer directly improves the entire builder and user experience.
    Strategic Alignment
    The proposal aligns with developer growth, DeFi expansion, node diversity, smart contract reliability, and better builder onboarding.
    This is not an optional enhancement. It is layer-1 competitiveness work.
    Economic Impact
    The economic impact is indirect but foundational.
    Lower execution costs can make more applications viable, improve DeFi capital efficiency, increase transaction activity, and support greater TVL growth over time.
    There is no direct revenue model, but cheaper execution can lead to more usage, more fees, and stronger ecosystem activity.
    Execution Risk
    Key risks include exploratory deliverables, hard fork dependency, formal methods complexity, and potential developer adoption lag.
    These risks are mitigated by time-boxed research outputs, clear fallback deliverables, multi-team collaboration, and structured workstreams.
    Accountability
    The proposal includes three defined workstreams: language and primitives, formal verification and audits, and developer tooling.
    The use of formal specification, property-based testing, and independent audit work adds a strong accountability and quality layer. The IO and VacuumLabs co-venture model also reduces single-team dependency.
    Stablecoin Utilization
    The proposal does not appear to include an explicit stablecoin treasury management strategy.
    That is a neutral to weak point. Infrastructure work has staffing, audit, and delivery costs that benefit from predictable purchasing power. Converting an appropriate portion of received ADA into stablecoins would help protect delivery capacity against ADA downside volatility.
    The treasury disbursement process should also consider staged stablecoin conversion for milestone-based operating expenses.
    Infrastructure funding should not rely on market timing. Hoping ADA remains at a certain price is not a treasury strategy.
    End-User Lens
    For builders, this means easier onboarding, better tooling, lower contract costs, and faster iteration.
    For users, this means cheaper transactions, more reliable applications, and a broader dApp ecosystem.
    For capital providers, stronger smart contract safety reduces perceived technical risk.
    Conditions to Change Vote
    This rationale would materially change if the proposal fails to deliver measurable execution cost improvements, developer onboarding does not improve, new tooling is not adopted, or hard fork readiness milestones are missed.

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

    Plutus is cool and all, so I don't want to stop it. However, I would like to see a more concrete showing of what features are missing, what use cases they empower, and why we need them.

  • 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.
    I want to be clear about what this vote is and is not. This is not a vote against the technical merits. The three workstreams target real gaps in Cardano's smart-contract platform: built-in casing on Data; a property-based conformance framework that materially supports node diversity and alternative evaluators; Agda formalization of programmatic built-ins; and a standalone GHC Plinth backend that removes Nix and native C dependencies. These are core-protocol items that only a team with deep Plutus stewardship can deliver, and IO and VacuumLabs are unquestionably capable of executing them. The timing relative to the post–Van Rossem window is also defensible.
    My objection is to budget transparency, which falls short of the standard the Cardano Constitution v2.4 and the 2030 Vision call for in treasury withdrawals of this scale.

    • First, the ₳10.21M Development line (86% of the ask) contains no FTE breakdown, no hourly or monthly rate, and no split between IO and VacuumLabs personnel. For an ₳11.88M request, this opacity is not acceptable.
    • Second, ₳950k sits in vaguely defined buckets — "Engagement & Ecosystem support" (₳712k), "Governance" (₳118k), and an unexplained "Others" (₳118k). An "Others" line in a treasury proposal is a structural red flag.
    • Third, the Security & Audits allocation of ₳118k (~$28.5k) is implausibly low for a claimed systematic audit of the Plutus evaluator and costing logic, and the proposal does not name an independent external auditor. A credible third-party audit of consensus-critical code typically costs multiples of this figure.

    I encourage IO and VacuumLabs to resubmit with itemized personnel costs, a named external auditor, and the "Others" line removed or justified. I will support a revised version.

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