IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability
234 DReps voted · 80 with a rationale
Open a row to read the rationale.
- Abstain 2.1M ₳ No rationale
- Yes 2.1M ₳ No rationale
- Yes 2.1M ₳ Rationale
I voted YES on IO & VacuumLabs: Enhancing Plutus because Plutus is foundational to Cardano’s smart-contract ecosystem. The proposal improves execution efficiency, expands useful primitives, strengthens formal specification and conformance testing, and improves developer tooling through better compiler architecture, clearer errors, reduced boilerplate, and easier setup. These improvements support lower-cost DApps, better developer experience, stronger security, and future node diversity. The ask is proportionate to the importance of Plutus as core infrastructure and the collaboration with VacuumLabs helps broaden stewardship beyond IO.
- No 2.1M ₳ No rationale
- Yes 2M ₳ Rationale
We strongly recommend a YES vote. The reason is simple: the Plutus language is the "heart" of the entire Cardano ecosystem, and currently, this heart is operating at an excessively high cost.
If Cardano wants to compete fairly and attract billions of dollars in capital, the cost of executing smart contracts must be lower. This proposal directly addresses that problem by adding new built-in functions like multiIndexArray and eliminating redundant checks, drastically reducing script size and transaction fees. With lower fees, new DeFi protocols can implement complex features (such as instant liquidation and asset rebalancing) that were previously considered economically impossible on L1.
We consider the 11.9 million ADA budget to be a worthwhile investment in the core infrastructure.
- Yes 2M ₳ No rationale
- Yes 2M ₳ No rationale
- Abstain 1.9M ₳ No rationale
- Yes 1.8M ₳ No rationale
- Yes 1.8M ₳ Rationale
These workstreams enhance the security and usability of Plutus. Necessary ongoing work.
- Yes 1.7M ₳ No rationale
- Yes 1.7M ₳ No rationale
- Yes 1.7M ₳ Rationale
Another much needed upgrade
- Yes 1.7M ₳ No rationale
- Yes 1.5M ₳ Rationale
I voted YES on this proposal, although with some reservations around the size & scope.
That said, I think the core direction is correct. Improving Plutus execution efficiency and reducing unnecessary overhead should help lower fees and make Cardano applications more practical to use at scale. I also think continued investment in formal verification, conformance testing, and tooling is important as the ecosystem matures. Cardano can't afford to loose that.
Overall I believe this is a reasonable infrastructure investment that strengthens the long-term quality and competitiveness of the platform.
- Yes 1.5M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- No 1.4M ₳ No rationale
- Yes 1.2M ₳ No rationale
- Yes 1.2M ₳ Rationale
IOG certainly asks for a lot, although some of the proposals are collaborations with other companies. I will go over the different proposals separately.
✅ Developer Experience
It’s important that developers who want to build on Cardano can do so as easily as possible. While I think this proposal could be done more cheaply, not getting it done would be much worse.✅ Cardano Upgrades
These upgrades will be beneficial for Cardano.✅ Consensus
Implementing Leios is important to handle the transaction volume we’ll have once Cardano is used for many use cases. I would have preferred to see Simple Leios implemented directly (with a longer time frame), though, rather than first spending time and resources on Linear Leios.✅ L2 Scalability
We need solid L2 solutions for high transaction volume applications that would be too expensive on L1 (in terms of resources and fees).❌ Cardano High Assurance
I like this proposal, but unfortunately, under the current available NCL and taking other proposals into account, difficult choices need to be made. I will approve this proposal if it is resubmitted under a new NCL.✅ Cardano Maintenance
This proposal is too expensive for what it delivers, but alternative nodes are not yet mature enough to risk stalling the development of cardano-node.✅ Plutus
Further improvements and extensions of smart contract capabilities are important.➖ Blockfrost
I think the free tier should be subsidized by the revenue Blockfrost generates from its paid tiers, like any other company using a freemium model. I do recognize the decentralization efforts made, although funding for this was already received in the past; hence I will abstain.➖ Pogun
There are multiple alternatives for Bitcoin DeFi on Cardano being developed, and it remains to be seen which one will perform best and attract the most users. The treasury should not provide a grant for this, but since the earnings would be used to repay the funds, it is essentially a loan. Given that additional revenue would later be shared with the treasury, it could even be considered an investment. However, I am not sure whether the current NCL allows for this kind of investment at the moment. If a higher NCL becomes available, I would vote in favor of this proposal, but for now I will abstain. - Yes 1.1M ₳ No rationale
- Yes 1.1M ₳ No rationale
- Yes 1M ₳ Rationale
**Plutus is the smart-contract execution foundation of Cardano. If Plutus is slow, awkward, under-specified, or difficult to use, Cardano’s application layer pays the tax every day. **This proposal sits close to the engine room by improving execution efficiency, adding missing primitives, strengthening formal conformance, supporting alternative evaluators, and reducing developer friction.
Cardano is known for its scientific rigour as a differentiator, and this proposal is the consequence by asking the treasury to pay for the less glamorous tasks of that claim: specification, testing, compiler work, and hardening. One cannot market “high assurance” on Monday and then refuse to fund assurance engineering on Tuesday.
That said, the requested ₳12M is substantial for what's to be done here. Even accepting the reference value of roughly USD 2.85M, this is a serious treasury withdrawal and must not be waved through because the words “Plutus,” “formal methods,” and “developer experience” appear in the same paragraph. My concern is not that the work is frivolous, but that we're going down a funding hole from which we can't get out anymore once foundational infrastructure proposals become too big to question and too technical for DReps to challenge. **The abstract and rationale justify strategic necessity, but they do not by themselves prove cost efficiency. In the real world, assessing a project's costs, I would want a much stronger contractual acceptance criteria, public work visibility, and independent assurance before disbursement. **Why is this not possible on Cardano? Due diligence and accountability, liability for quality issues, milestone enforcements?
Anyways, I consider the work necessary and strategically central enough to justify support, provided the ecosystem remains vigilant about delivery discipline.
- Yes 1M ₳ No rationale
- Yes 985.7K ₳ Rationale
Integrates optimization CIPs to replace gas-heavy on-chain loops with direct built-ins.
- Yes 955.2K ₳ No rationale
- Yes 947.9K ₳ No rationale
- Yes 922.9K ₳ No rationale
- Yes 860.4K ₳ No rationale
- No 818K ₳ Rationale
The technical enhancements outlined in this proposal are high-quality and undeniably beneficial for the long-term evolution of Plutus. However, governance demands a strict balancing of technical utility against immediate strategic urgency. This initiative represents an important but non-urgent optimization that can wait for more favorable market conditions. Under the current economic climate, treasury conservation must take precedence to ensure available capital is aggressively channeled into direct ecosystem growth, user acquisition, and demand-generation activities. Therefore, a NO vote is recommended to safeguard the network's financial reserves for immediate expansion priorities.
- Yes 804.1K ₳ Rationale
Plutus is the foundation every Cardano smart contract is built on. This proposal makes it cheaper to run, more formally verified, and easier to develop on. Lower execution costs benefit every user and protocol today. Better tooling brings more developers in. Stronger formal specification becomes increasingly critical as node diversity grows.
- No 793K ₳ Rationale
Sounds great, but I don't care. IO was funded during the last major Intersect budget cycle with a long list of deliverables. Why wasn't all of this in competition for funding at that time if it was so bloody important. I'm not interested in cutting any more big checks from the Treasury with ADA at these price levels. Get your shit together and tell us what you want to accomplish as part of the primary budget cycle.
- Yes 785.2K ₳ Rationale
Directly improves unit economics (lower execution cost) → immediate impact on DeFi viability and competitiveness.
Plutus is a core bottleneck today; better primitives + compiler + DX meaningfully reduce friction.
Formal spec + conformance testing is critical given future node diversity → avoids consensus risk.
VacuumLabs co-build reduces single-vendor dependency → positive for long-term resilience.
Not a headline growth driver, but high-leverage infrastructure improvement with clear ROI vs cost. - Yes 765.1K ₳ Rationale
Aiken improvements yes.
- Yes 762.6K ₳ No rationale
- Abstain 738.5K ₳ No rationale
- Yes 733.1K ₳ Rationale
YEs
- Yes 670.2K ₳ Rationale
I’m voting yes because this upgrade meaningfully improves Plutus by making smart contracts cheaper to run, more correct through formal verification, and easier to develop with better tooling and simpler setup. That combination lowers friction for builders and increases reliability, which strengthens Cardano’s ability to support serious financial and DeFi applications. It also matters for real-world impact: more efficient contracts and better developer experience usually translate into more builders shipping on Cardano, more deployed dApps, and higher transaction activity over time. In that sense, we do need it—not because the system is broken, but because reducing cost, risk, and complexity is what drives the next wave of adoption and ecosystem growth. It also helps AI agents indirectly, since clearer tooling, better error reporting, and formal verification make smart contract behavior more predictable and machine-analyzable. That makes it easier for AI systems to safely generate, audit, and interact with on-chain logic.
- No 654.5K ₳ Rationale
₳11.9 MILLION ADA FOR PLUTUS — MY ANSWER IS NO ⚠️
I am voting NO on this proposal.
This proposal requests ₳11,877,575 from the Cardano Treasury to improve Plutus — Cardano’s smart contract language. On paper, the goal sounds good: improve Plutus, make smart contracts cheaper, strengthen security, and make life easier for developers.
But the problem is not the beautiful description. The problem is something else.
IOG and affiliated entities have already received major funding from the Cardano Treasury. The proposal itself states that the total allocated amount was ₳130,708,860, of which ₳78,459,777 has already been withdrawn.
And now they are asking for almost 12 million ADA again.
For me, this is the weak point. You cannot keep coming back to the Treasury and saying: “Give us more, we will improve the infrastructure.”
First, there must be a simple and strict report: what was received, what was delivered, what results were achieved, which metrics improved, how many developers came in, and how much easier it actually became to build on Cardano.
Without that, this new proposal does not look like development. It looks like another funding request for basic work that the ecosystem has been waiting for a long time.
Plutus really does need improvement. But that does not mean every large Treasury request should be automatically supported.
The Cardano Treasury is not an endless wallet. It is community money.
That is why my answer is: NO.
First results. Then new money.
I have registered as a DRep and I am ready to help shape the future of the ecosystem. - Optimistic about building the largest digital community in the world. 🖤 My DRep ID: ➡️ drep1y269ehxj30k4vfzfc2z84v0xykd3amuy2xn0kv9zf8rhcec2fg2jr More details here https://t.me/PROCENT666/338
🚀 COURSE “LEDGER COLD CRYPTO WALLET” | METAMASK
https://edgarbagdasarian.justclick.ru/order/LEDGERMETAMASK🔥 CLOSED VIP CHAT PAID SUBSCRIPTION
https://t.me/MREDGARCROSS_BOT🌐 ALL COURSES AND LINKS
https://mredgarcross.com/📌 Note: This post is for informational and analytical purposes only. It does not contain calls for action, protest, or violation of the law. Everything stated is the author’s personal reflection.
- Yes 624.8K ₳ Rationale
Total ask: ₳11,877,575 / ~$2,850,618 at $0.24
Development ratio: ₳10,214,715 = 86%
Team size: 11 named engineers (4 DX / 4 UPLC capabilities / 3 formal methods)
Implied FTE cost: $2,451,532 development ÷ 11 engineers ÷ 12 months × 12 = ~$223K annualized
Unspent funds return: Explicit (Section 4.4)A PDF version of this rationale is also made available.
I'm voting yes because Plutus is the substrate that every Cardano smart contract runs on, and this proposal funds three interconnected improvements around execution efficiency, formal correctness, and developer onboarding which compound directly, the outcomes the ecosystem needs.
The deliverables that align most explicitly with priorities I've stated are in Workstreams 2 and 3. The property-based conformance testing framework, by extending the existing 1,982-test suite with randomly generated programs, it is a direct benefitting enabler of node diversity I've consistently voted to support. Amaru, Dingo, and Gerolamo all need a conformance framework that covers edge cases beyond handwritten tests; this proposal builds it. The Agda formalization of programmatic built-in types and functions extends the same rigorous specification methodology IO applied to the Leios and High Assurance proposals, consistent and cumulative, exactly the kind of infrastructure investment that compounds over time. On the developer experience side: no-Nix installation, source-level error messages, standalone compiler binaries, single-command setup. These are not conveniences. They are the difference between a developer's first Cardano project succeeding or failing. Every friction point that gets removed is a developer retained. The accessibility mandate runs through all three workstreams.
The VacuumLabs co-venture is worth naming explicitly. This isn't IO funding IO work with IO people. VacuumLabs is an independent specialist firm with deep Haskell and formal methods expertise contributing to Plutus as shared public infrastructure. That distributed ownership model supports multiple expert teams stewarding core infrastructure rather than a single organization. This is exactly the structural outcome a maturing ecosystem should be building toward and IO continues to show a mandate to distributing the workload. At ₳11,877,575 (~$2.85M at $0.24), with 86% allocated to development and unspent funds returned, the ask is proportionate for scope. The implied FTE cost runs slightly above my $200K annualized benchmark at roughly $223K per engineer; given that Agda formal methods specialists, GHC compiler engineers, and Haskell security auditors are genuinely scarce expertise, the rate is defensible.
The risks are honestly disclosed and well-contained. The scope check investigation delivers a CIP or a report regardless of outcome, we have a time-boxed deliverable either way. CIP-0168 isn't yet ratified, a real risk that the proposal tracks closely. The new UPLC features require the Dijkstra hard fork for mainnet activation, which is out of scope for this proposal but honestly stated. None of these change the vote. - Yes 589.2K ₳ Rationale
IO got us this far, so it's time to back them to continue the work to help get Cardano to #1.
- Yes 536.5K ₳ Rationale
This proposal not only brings a better more robust DevEx to cardano it also inhanses Cardanos unique selling point or reliability, without a doubt the best easiest YES I can give to any of the IOG proposals
The IOG team delivering them is undoubtedly the best implementor we could ask for.
It is a little pricey, but that is to be expected if we are demanding the best of the best to work on our core infrastructure.
- Yes 534.3K ₳ Rationale
Enhancing and continuing to improve the haskell node and plutus are critical. We demand highly secure and easy to use systems. Plutus must continue to develop and get better tools for developers.
- Yes 525.8K ₳ No rationale
- Yes 487.1K ₳ No rationale
- No 481.5K ₳ Rationale
- Yes 473.6K ₳ No rationale
- Yes 466.2K ₳ No rationale