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

System 2mo ago1post

234 DReps voted · 80 with a rationale

Open a row to read the rationale.

  • Yes 20.3M ₳ No rationale
  • Yes 19.9M ₳ Rationale

    I like to see this joint effort by IO and Vaccumlabs, two very trusted vendors in our ecosystem.
    Cardano is nothing without smart contract capability, Plutus is our smart contract core. Every other smart contract language like Aiken compile to Untyped Plutus Core (UPLC), and upgrading this base to keep up with rising demands, like node diversity, is essential.

  • Yes 17.1M ₳ Rationale

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

  • No 16.7M ₳ Rationale

    I’m voting NO because ₳ 12 million is a major treasury allocation, and the proposal still does not provide an auditable cost model and acceptance-evidence structure commensurate with that size. The work may be valuable, but public funding at this scale should include explicit staffing/FTE counts and rate assumptions per workstream, clear deliverable ownership, and artifact-driven milestone acceptance evidence (what will be published, how it will be tested, and what constitutes completion) so governance can judge cost efficiency and delivery quality. As a governance principle, core roadmap-class work from founding entities was expected to be funded primarily from their long-standing resources (including genesis allocation), and the treasury should not become the default completion fund unless proposals meet an exceptionally high standard of transparency and price discovery. Finally, we are giving a process penalty for bypassing the Intersect Budget Process, which was specifically designed to address the gap in the process between proposers and Dreps. Bypassing the Intersect budget mechanism undermines comparability and price discovery for a major protocol spend, and founding entities should set the example by using the improved process rather than routing around it.

  • No 16.4M ₳ Rationale

    IO has been funded by a significant amount of premine tokens.

  • Yes 14.2M ₳ No rationale
  • Yes 14.1M ₳ No rationale
  • Yes 13.3M ₳ Rationale

    RCADA Rationale

    RCADA votes YES on the IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability Treasury Withdrawal proposal.

    We support this proposal because Plutus is foundational to Cardano’s smart contract ecosystem. The cost, expressiveness, correctness, and usability of Plutus directly affect what developers can build, how safely they can build it, and whether Cardano can remain competitive as a serious platform for DeFi, high-assurance applications, zero-knowledge use cases, and broader on-chain utility.

    This proposal addresses three connected areas: improving Plutus capabilities and execution efficiency, strengthening formal specification and conformance testing, and improving developer experience. RCADA sees these as mutually reinforcing rather than unrelated workstreams. A smart contract platform should be cheaper to use, easier to build with, and more rigorously specified as the ecosystem matures.

    The performance and capability work is important because execution costs remain a practical constraint for Cardano applications. Features such as built-in casing on Data, implementation of multiIndexArray from CIP-0156, additional BuiltinValue functions from CIP-0168, and investigation into scope-check removal, laziness, and memoization could reduce script size, lower execution budgets, and unlock more efficient contract patterns. These improvements can make Cardano more attractive to developers and improve the user experience of applications that depend on Plutus.

    RCADA also values the formal specification, correctness, and security work. As alternative node implementations and independent Plutus evaluators become more realistic, Cardano needs stronger implementation-independent specifications and conformance testing. A property-based conformance framework, Agda formalisation of built-in semantics, and structured security review of evaluator and costing logic all help reduce the risk of subtle consensus or execution differences. This is exactly the type of foundational work that supports a safer multi-client future.

    The developer-experience work is also welcome. Cardano smart contract development has a reputation for being powerful but difficult to approach. Better compiler architecture, clearer source-level error messages, reduced boilerplate, broader GHC support, and simpler setup without heavy Nix or native dependency friction could help more developers move from experimentation to production. RCADA has consistently encouraged practical documentation, tooling, and onboarding improvements, and this proposal includes meaningful steps in that direction.

    We also view the collaboration with VacuumLabs positively. RCADA does not want Cardano’s core infrastructure to depend indefinitely on a single organisation. At the same time, the answer is not simply to replace one dominant provider with another. The healthier path is progressive multi-party stewardship, where specialist teams contribute to shared public infrastructure according to their strengths. The IO and VacuumLabs co-venture is a constructive example of that model for Plutus.

    However, our YES vote should not be read as unconditional endorsement of every future protocol change described in this proposal.

    Some of the benefits depend on future hard-fork activation. The proposal states that language and built-in extensions require a hard fork for activation on mainnet, with Dijkstra as the target. RCADA views this vote as support for development readiness, formalisation, testing, and implementation work. Any future hard-fork activation should remain subject to separate technical, governance, ecosystem, and constitutional review.

    We also note the familiar concern around budget transparency. The proposal requests ₳11,877,575, with a large share grouped under development. While specialist compiler, language, formal-methods, and security work is expensive and requires rare expertise, future proposals would benefit from clearer partner-level cost attribution, staffing assumptions, and milestone-level payment detail. Treasury-funded technical work should be understandable and auditable by the wider community, not only by insiders.

    RCADA also encourages early and continuous coordination with downstream tooling teams. Plutus changes can affect compilers, wallets, indexers, auditors, alternative evaluators, DApp developers, and educational resources. To avoid unnecessary disruption, these improvements should be accompanied by strong documentation, migration guidance, conformance tests, examples, and public communication.

    Overall, RCADA believes this proposal is well aligned with Cardano’s strategic needs. It strengthens the smart contract foundation, supports formal correctness, improves performance, improves developer usability, and helps distribute Plutus stewardship across expert teams. It is a broad proposal, but the workstreams are connected by a coherent goal: making Plutus cheaper, safer, and easier to use.

    For these reasons, RCADA votes YES, while emphasising the importance of downstream coordination, clear documentation, separate scrutiny for future hard-fork activation, measurable delivery, and improved cost transparency in future Plutus funding requests.

    RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/".

  • Yes 12.8M ₳ Rationale

    I am voting YES on governance action 73e171a4c0730b4b59ecae271ab89f12a9d56360b02920e1f95107dbdc1d6762#6.

    I came very close to voting NO on this proposal, as I believe many of the things outlined in the roadmap to be a misallocation of resources.

    Continuing to evolve Plutus, the underlying runtime and execution model on which all dApps rely, is essential in the long term. It has come a long way since 2021, but still has many glaring gaps, and this proposal does include several of those.

    However, it also continues to invest resources in things that I think are superfluous or distractions. Plinth is (through no fault of the team) not a serious contender for the construction of most dApps that have yet to be built. Those serious about performance will reach for lower level primitives like Plutarch or hand-rolled UPLC. And the vast majority will be written in Aiken, Pebble, Opshin, or others.

    Additionally, another team has formalized the CEK machine and ledger rules in Lean. Agda is the less-approachable cousin, and to me represents redundant and duplicated work.

    Overall, I want to see the new builtins described in the proposal, and they alone (barely) justify the cost. My hope is they will unlock a new era of efficiency, much as reference inputs and inline datums did in the past. I want to see the underlying execution framework evolve and reduce fees for users. And it's clear to me, from looking at the advocacy on social media, this is where the teams head is really at.

    My hope is that, if this proposal passes (as seems likely right now), the team has liberty to evaluate and restructure their roadmap. Stay flexible to the needs of the developers, rather than locking in a full years roadmap up front. If these work items finish faster than expected, devote those resources to the things Phil called for here, instead.

    You can find a larger writeup justifying my vote here.

  • Yes 12.2M ₳ Rationale

    This proposal addresses several foundational weaknesses and long-standing friction points within the Plutus ecosystem that materially affect developer productivity, smart contract efficiency, protocol safety, and Cardano’s long-term competitiveness as a programmable blockchain platform. The identified issues around execution inefficiencies, tooling complexity, incomplete formal specification coverage, and limitations in expressiveness are legitimate technical concerns that have been acknowledged by developers and infrastructure contributors across the ecosystem. As Cardano adoption expands and smart contract usage becomes increasingly sophisticated, improving the underlying Plutus infrastructure is no longer optional but necessary to sustain growth, reliability, and developer retention.

    We believe that the proposed workstreams collectively strengthen multiple layers of the smart contract stack. The implementation of new built-in functions such as CIP-0156 and CIP-0168 directly improves execution efficiency by reducing the need for expensive on-chain looping and repetitive script patterns. Improvements such as built-in casing on Data and investigations into reducing unnecessary interpreter overhead could lower execution costs, reduce script sizes, and improve throughput efficiency across decentralized applications. These are meaningful infrastructure enhancements that can benefit virtually every Plutus-based application deployed on Cardano.

    The proposal also delivers important long-term ecosystem value through its emphasis on formal verification, conformance testing, and security auditing. As node diversity becomes increasingly important to Cardano’s decentralization strategy, having stronger implementation-independent specifications and property-based conformance testing becomes critical for preventing consensus inconsistencies across future node clients and evaluators. Expanding the Plutus metatheory and formalizing built-in semantics in Agda strengthens Cardano’s research-driven foundations and reinforces the network’s reputation for correctness and high assurance engineering.

    Equally important are the developer experience improvements outlined within the proposal. The current onboarding and tooling experience for Plutus developers remains significantly more complex than competing ecosystems, particularly due to dependency management, compiler friction, and difficult setup requirements. Efforts to simplify installation, reduce reliance on Nix, improve compiler ergonomics, and deliver clearer source-level error messaging represent practical improvements that can lower barriers to entry and improve developer adoption over time.

  • Yes 11M ₳ No rationale
  • Yes 10.8M ₳ No rationale
  • No 10.5M ₳ Rationale

    So far this year Cardano governance is approved

    137 million ADA expenditure + 116 million ADA IOG proposals, so far

    That is already 253 million ADA expenditure. I will be voting NO/ABSTAIN on all other proposals because imo the yearly spend should be between maximum 200-250 million.

  • No 9.6M ₳ No rationale
  • Yes 8.8M ₳ Rationale

    私はこの提案に賛成します。Cardanoの長期的な競争力を維持するためには、単なる機能追加だけでなく、スマートコントラクト基盤そのものの正確性・安全性・開発体験を継続的に強化していくことが重要だと考えています。特に、形式仕様、適合性テスト、プロパティベーステスト、Agdaを用いた形式仕様の整備などを通じて、Plutusの形式的正確性を強化しようとしている点を高く評価しています。また、今後代替ノードクライアントやノード多様性が進んでいく中で、実装間の仕様差異やスクリプト実行結果の不一致を防ぐための形式仕様や適合性フレームワークは、Cardanoエコシステム全体の信頼性向上にとって重要だと考えています。さらに、Nix依存や定型コード削減、エラーメッセージ改善などの開発者体験改善も、新規開発者の参入障壁を下げるうえで重要です。短期的な指標や普及への直接的効果には不確実性もありますが、Cardanoの強みである「高保証性」をさらに発展させていくうえで、このようなプロトコルおよびスマートコントラクト基盤への中長期的投資は重要だと考えており、本提案を支持します。\n\nI support this proposal. To maintain Cardano’s long-term competitiveness, I believe it is important not only to add new features, but also to continuously strengthen the accuracy, security, and developer experience of the smart contract foundation itself. In particular, I highly value the proposal’s efforts to improve the formal correctness of Plutus through formal specifications, conformance testing, property-based testing, and the development of formal specifications using Agda. In addition, as alternative node clients and node diversity continue to expand in the future, I believe that formal specifications and conformance frameworks to prevent specification inconsistencies between implementations and discrepancies in script execution results will become increasingly important for improving the reliability of the overall Cardano ecosystem. Furthermore, developer experience improvements such as reducing Nix dependency requirements, minimizing boilerplate code, and improving error messages are also important for lowering the barriers to entry for new developers. While there is uncertainty regarding the direct short-term impact on metrics and adoption, I believe that medium- to long-term investment in the protocol and smart contract foundation is important for further strengthening Cardano’s core advantage of high assurance, and for that reason I support this proposal.

  • Yes 8.1M ₳ No rationale
  • Yes 7.8M ₳ No rationale
  • No 7.8M ₳ No rationale
  • Yes 7.3M ₳ No rationale
  • Yes 7.1M ₳ Rationale

    First, if you are considering voting No on this proposal because this is "Plutus", think again. This proposal is not aimed at improving the standard PlutusTx language (the word Plutus is used interchangeably in Cardano lore, so you might be misunderstanding which Plutus this proposal is referring to). No, this is not the Plutus language that you heard about - that was overtaken in usability and dev-friendliness by new languages such as Aiken et al.

    So, this proposal is about improving the unsexy brain of Cardano - Untyped Plutus Core (UPLC). UPLC is pretty-much as low-level as you can get when it comes to Cardano smart contracts (stole this definition from the Aiken website). So, in my view, this type of proposal is literally one of the reasons why the Treasury exists. We have a smart Cardano, but we want a smarter Cardano that is easier and safer to use with more capabilities.

    We need to improve the smart contract platform if we want to stay competitive. Cardano is a proof of stake Bitcoin version with much more expressiveness than Bitcoin, but still not enough expressiveness as some of our competition. This proposal does not aim to improve the higher level PlutusTx, it aims to improve the UPLC base for all the higher level languages such as Aiken, Pebble, OpShin, Scalus, etc. UPLC is the low-level bytecode that actually runs on the Cardano blockchain.

    For more context, do not read only the proposal on-chain, but there is a pretty good higher-level explanation on: https://momentum.cardano.iog.io/proposals/plutus . Read that first.

    Also, keep in mind that I am not a developer, so I might have made a technical error or misspoken on something, but I have no intention to mislead. Still - this is the pulsing mind of Cardano that needs a new chip implant. Yes for me.

  • No 6.2M ₳ Rationale
    • 이미 현재 수준의 플루터스로도 양질의 디앱들이 충분히 구축을 되고 있으며, 최적화라는 우선순위는 지금 시점에서는 높지 않다고 판단함
  • Abstain 6M ₳ Rationale

    I am voting Abstain.

    Vacuumlabs has a solid track record and I don’t question the technical value of improving Plutus across performance, correctness, and usability. These are meaningful enhancements to the underlying platform.

    My hesitation is around the degree to which these improvements translate into near-term ecosystem outcomes. While it’s fair to say they can support multiple long-term KPIs, the connection to actual user growth, adoption, and economic activity remains indirect and dependent on additional factors that are not addressed here.

    We’ve spent years improving the technical foundation of Cardano with the expectation that adoption would follow, and that hasn’t consistently materialized. I don’t view this as unnecessary work, but from a prioritization standpoint, I’m not convinced it meaningfully addresses the most immediate constraints facing the ecosystem today.

  • Yes 5.5M ₳ No rationale
  • Yes 5.3M ₳ Rationale

    Voting YES. Plutus is the foundation of every smart contract on Cardano, and this proposal strengthens it across the three dimensions that matter most: cheaper and more expressive on-chain execution, formal correctness guarantees that scale with node diversity, and a developer toolchain that no longer requires Nix or specialist setup knowledge. Implementing the already-ratified CIP-0156 multiIndexArray and the forthcoming CIP-0168 BuiltinValue functions turns common multi-asset operations into single cheap built-ins rather than verbose on-chain loops - a direct cost reduction for every DeFi protocol on Cardano. The property-based conformance testing framework is the honest infrastructure investment that makes alternative node clients viable in practice, not just in principle.

    The VacuumLabs co-venture is the structural feature that elevates this proposal. Plutus stewardship transitions to VacuumLabs by end of 2026, distributing maintenance of Cardano's core smart contract platform across expert teams rather than concentrating it within IO. This pattern - shared public infrastructure maintained by a consortium - is repeated across the IO 2026 batch (Midgard Labs on L2, Ensurable Systems on maintenance and platform, the High Assurance consortium, VacuumLabs on Plutus), and it is precisely the distributed-ownership outcome the Cardano 2030 Vision is designed to produce. Same gold-standard treasury safeguards as the rest of the batch. Seven named risks with likelihood and severity, including the honest disclosure that CIP-0168 ratification (PR #1090) is still in flight - the kind of self-disclosure that signals a well-prepared proposal rather than a polished pitch.

    Peter Horsfall - Independent DRep, Oceania.

  • Yes 5.3M ₳ Rationale

    STORM Partners votes YES on IO & VacuumLabs: Enhancing Plutus.
    Plutus remains the core smart contract infrastructure for Cardano. Improving performance, safety, and developer usability directly affects the ecosystem’s ability to support production-grade applications.
    We also view the collaboration with VacuumLabs positively, as critical infrastructure should not depend too heavily on a single organization. We support this proposal while expecting clear reporting on how the work improves the actual developer experience and application readiness.

  • Yes 4.8M ₳ No rationale
  • Yes 4.8M ₳ No rationale
  • Yes 4.5M ₳ No rationale
  • Yes 4.4M ₳ No rationale
  • Yes 4.2M ₳ Rationale

    [Portuguese]
    Optamos por votar "SIM" nesta ação de governança "IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability" (gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3qvczhx6t), pois entendemos que ela atua em pontos centrais para a evolução da Cardano: melhoria de desempenho e redução de custos em scripts Plutus, fortalecimento da correção formal e da segurança, além de avanços importantes na experiência dos desenvolvedores. A proposta é tecnicamente relevante porque impacta diretamente a capacidade da rede de atrair mais aplicações, aumentar a confiança em contratos inteligentes e preparar melhor o ecossistema para maior diversidade de nós e ferramentas. Embora o valor solicitado, de ₳11.877.575, seja significativo, consideramos que o custo-benefício é justificável pela abrangência dos entregáveis e pelo potencial impacto estrutural no ecossistema. Além disso, os mecanismos de controle e transparência — contratos por marcos, supervisão da Intersect, validação por terceiros, prestação de contas pública e devolução de valores não utilizados ao Tesouro — reforçam a segurança no uso dos recursos.
    [English]
    We chose to vote "YES" on this governance action "IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability" (gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3qvczhx6t), because we understand that it addresses central areas for Cardano’s evolution: improving performance and reducing costs in Plutus scripts, strengthening formal correctness and security, and delivering important improvements to the developer experience. The proposal is technically relevant because it directly impacts the network’s ability to attract more applications, increase confidence in smart contracts, and better prepare the ecosystem for greater diversity of nodes and tools. Although the requested amount, ₳11,877,575, is significant, we consider the cost-benefit ratio justified by the breadth of the deliverables and the potential structural impact on the ecosystem. In addition, the control and transparency mechanisms — milestone-based contracts, Intersect supervision, third-party validation, public reporting, and the return of unused funds to the Treasury — reinforce the safety of the use of resources.

  • Yes 4.2M ₳ No rationale
  • Yes 4M ₳ No rationale
  • Yes 3.8M ₳ Rationale

    Plutus is both one of Cardano's biggest strengths, but also one of the items helping to block developer adoption. I see this project as worth the cost to help lower that barrier.

    A PDF version of this rationale is also made available.

    I support this proposal with reservations.

    This is one of the stronger examples of legitimate treasury-funded public infrastructure in the current governance cycle. Plutus is effectively shared ecosystem substrate: improvements to execution efficiency, correctness infrastructure, and developer tooling compound across every smart-contract language and every DApp built on Cardano.

    The proposal addresses several strategically important areas simultaneously:

    • reducing execution costs,
    • strengthening formal correctness and conformance testing,
    • improving alternative-client reliability,
    • and materially reducing developer onboarding friction.

    I view the property-based conformance framework and formal specification work as particularly important for long-term node diversity and implementation resilience. Ecosystem decentralization requires more than governance distribution; it also requires multiple implementations to safely evolve against shared semantic expectations.

    The developer experience workstream is also more important than many discussions acknowledge. Cardano’s tooling complexity and setup friction have been persistent ecosystem weaknesses, and reducing those barriers likely has ecosystem-wide compounding effects.

    I also view the VacuumLabs co-venture directionally positively. Moving stewardship of critical infrastructure beyond a single organization is healthier than permanent concentration inside IO alone.

    That said, I do not think the decentralization claims should be overstated. The proposal still centers heavily around IO-originated architecture, semantic authority, and roadmap direction. Governance should continue pushing for clearer long-term stewardship independence and operational ownership across the broader Plutus stack.

    I also remain concerned about proposal bundling and procurement visibility. This proposal combines runtime evolution, compiler changes, audits, formal specification work, and developer tooling into a single governance action, reducing voting precision and accountability. Additionally, DReps still lack sufficient line-item transparency to confidently evaluate efficiency at treasury scale.

    More broadly, proposals like this represent an important institutional transition: treasury is increasingly becoming a funding mechanism for ongoing protocol and smart-contract platform evolution. That may ultimately be appropriate, but governance frameworks and procurement oversight mechanisms are not yet fully mature for that responsibility.

    Overall, however, I believe the strategic infrastructure value outweighs the governance concerns, and I support funding the work.

  • Yes 3.7M ₳ Rationale

    I support the three proposed workstreams, as they are essential for enhancing Plutus capabilities, strengthening its security and developing the new compiler.
    I also endorse IOG’s joint venture with VacuumLabs.

    ==========================================

    In general (and this applies to all IOG proposals), I firmly believe Charles is the most capable leader to guide Cardano into its next phase. With his experience, resources, technical knowledge, his army of developers, researchers and strong personal incentive for Cardano’s long term success, I will vote in favor of everything his company proposes. I wish we had even better alternatives, but we don't, cause there aren't any.
    Since I am not a technical expert (particularly in this AI driven era), I will not pretend to fully evaluate the cost of these initiatives. That said, for a blockchain with a $10 billion market cap, an annual investment of approximately $40 million in core development does not seem excessive, especially in such a fast moving and highly competitive industry. Ultimately, this level of funding only makes sense if one trusts the incentives and capabilities of the person responsible for managing these resources.
    I have also carefully reviewed the arguments circulating on X against funding IOG and find them unconvincing, as they never offer any viable alternative path forward. This includes the so called “conflict of interest” concerns regarding Midnight Ambassadors who are also DReps.
    For transparency, I maintain close and regular communication with my 240 delegators through our Greek DAO Discord channel and update them via YouTube videos. They fully understand and expect me to ignore the social media noise, chaos and paranoia, and instead follow common sense and what is genuinely best for Cardano.

  • Abstain 3.5M ₳ No rationale
  • Yes 3.1M ₳ No rationale
  • Yes 2.8M ₳ Rationale

    I'm happy to vote YES for this proposal. All three workstreams are necessary functionality improvements for Cardano to continue to grow as #1 in blockchain security. Continued development of Plutus is essential as it is the current programming core of Cardano and until alternative full nodes in other programming languages are on par with Plutus for Cardano, continued support of Plutus is needed.

    I’m also happy to see that there is a focused goal on simplifying Plutus coding workflows, and a focus on cross-implementation conformance so that alternative nodes can be deployed with the same level of security that is expected across the Cardano ecosystem.

    Also, in no way should any founding entity, like IOG or its founder Charles Hoskinson publicly attack and pressure Cardano community members and DReps into voting Yes for their proposals. This dishonorable and disrespectful behavior is unbecoming of any leader who wishes to be taken seriously and in turn granted respect.

    If this behavior continues in the future, I will be downvoting every proposal by such entities who behave this way as a consequence. Please keep in mind that actions have repercussions.

    I also do not appreciate IOG frontrunning the entire Intersect budget process with the intent of claiming the entire NCL for 2026 and leaving nothing for community builders.

    I expect this proposal to complete all deliverables as stated, and if this is not done, IOG will receive no further Yes votes from me in the future.

  • 42
    Yes 2.7M ₳ No rationale
  • Yes 2.7M ₳ No rationale
  • Yes 2.6M ₳ No rationale
  • Yes 2.5M ₳ No rationale
  • Yes 2.5M ₳ Rationale

    yes please

  • Yes 2.5M ₳ Rationale

    本提案は、Plutus上で動作するDAppを「低コスト・高信頼・開発容易」にするための基盤強化である。具体的には、スマートコントラクト内で頻繁に行われるデータ処理やトークン操作をより効率的に実行できる仕組みを導入することで、手数料の削減と処理効率の向上を実現する。これにより、DeFiや複数トークンを扱うアプリケーションの実用性が高まる。
    また、プログラムの挙動を形式的に定義し、それに基づいて異なる実装間でも同一の結果が得られることを検証する仕組みを強化することで、ノード多様化が進む中でも一貫した動作と高い信頼性を確保する。さらに、開発ツールやコンパイラの改善により、エラーの可視性や開発環境の整備が進み、新規開発者の参入障壁も低下する。
    一部の機能はハードフォークやCIPの確定に依存するが、Cardanoのスマートコントラクト基盤を次の段階へ引き上げる重要な投資であり、長期的なエコシステム成長に不可欠と判断し、強く賛成する。


    This proposal strengthens the foundation of Plutus to make DApps on Cardano more cost-efficient, reliable, and easier to develop. It introduces more efficient ways to handle data processing and token operations within smart contracts, reducing fees and improving execution performance. This directly enhances the practicality of DeFi and multi-asset applications.

    It also improves reliability by formally defining program behavior and introducing stronger testing methods to ensure consistent results across different node implementations. This is especially important as node diversity increases. In addition, better developer tools and compiler improvements will make errors clearer and simplify the development environment, lowering the barrier for new developers.

    While some features depend on future hard forks and CIP finalization, this is a critical investment to advance Cardano’s smart contract infrastructure and support long-term ecosystem growth. I strongly support this proposal.

  • Yes 2.5M ₳ Rationale

    I am voting yes on this one. I believe these two companies are co-dependent on eachother in terms of plutus maintenance, which is a good thing. I really resonate with the following quotation directly from this proposal:

    The VacuumLabs co-venture signals that this is an ecosystem effort rather than a proprietary IO initiative. Cardano's core infrastructure benefits from being maintained and evolved across a broad contributor base of expert teams rather than a single organization. This distributed ownership model is a direct contribution to Pillar 5 (Ecosystem Sustainability and Resilience) and is the kind of structural outcome the Cardano 2030 Vision is designed to produce.

    This proposal will greater decentralize core infrastructure. Although the costs seem towards the upper end of the scale, this work can truly only be carried out by a handful of people in the ecosystem. I trust the Vacuum Labs team to deliver and hope that we can hit the outlined milestones, as it would greatly benefit Cardano.

    One thing i think that would strengthen this proposal is a more clearly defined plan of how the community becomes the owners of the maintenance and updates.

  • Yes 2.4M ₳ No rationale
  • Yes 2.4M ₳ No rationale
  • Abstain 2.4M ₳ No rationale
  • Yes 2.3M ₳ No rationale
  • Yes 2.1M ₳ No rationale
  • Yes 2.1M ₳ Rationale

    yes

    A PDF version of this rationale is also made available.

    yes