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

Proposal as pdf: https://ipnso-com.ipns.dweb.link/?cid=Qmd7G7L6xinunTLU9JorPLYyFCLGRarXEn7RngdNYgNH3B

This proposal strengthens Cardano’s smart contract platform across three critical and closely connected areas: language capabilities, formal correctness, and developer experience. It funds targeted expansion to the Plutus language with new syntactic forms and new primitives to reduce script costs, improve expressiveness, and unlock more efficient contract patterns; formal specification, conformance testing, and structured security review to support correctness as node diversity grows; and a better compiler and tooling experience that lowers setup friction, improves error reporting, and makes smart contract development more accessible. Together, these workstreams make Plutus cheaper to use, more trustworthy to build on, and easier for developers to adopt, helping Cardano support a broader range of applications while also providing stronger foundations for alternative node implementations and other ecosystem tooling.

This is a technical collaboration with Input Output and VacuumLabs, distributing Plutus stewardship across expert teams. Intersect administers funds via milestone-based smart contracts with independent oversight. All unspent funds return to the Treasury.

Treasury Ask: ₳11,877,575

As a smart contract developer building on Cardano, whether authoring decentralized finance (DeFi) protocols, zero-knowledge (ZK) applications, or high-assurance infrastructure, I want a Plutus platform that compiles cleanly, runs efficiently, and carries formal correctness guarantees, so that I can spend my time building valuable applications with greater clarity and consistency across tools and specifications.

Opportunity: Plutus, a compact lambda-calculus-based language executed by Cardano nodes, serves as the foundation of all Cardano smart contracts. Its quality and capabilities directly influence what developers can build, how quickly they can build it, and how much confidence they can place in the results. There are three interconnected areas where further improvements would strengthen Plutus’s ability to fulfill this role.

Plutus execution efficiency and expressiveness. On-chain execution costs are critical to Cardano's competitiveness. Targeted expansion of Plutus capabilities and primitives can deliver meaningful reductions in script size and execution budget. Extending casing to cover the built-in Data type would let scripts efficiently pattern-match on Data, a ubiquitous type in validators. Implementing the ratified CIP-0156 (multiIndexArray) and the forthcoming CIP-0168 (additional Value functions) would turn common list and multi-asset operations into single, cheap built-ins rather than verbose on-chain loops. Removing the scope check, which currently adds roughly 25% to script preparation time without providing a security benefit, could free up significant validation overhead. Finally, a systematic exploration of laziness in UPLC would address a fundamental expressiveness gap that today forces developers into less modular or less efficient code patterns.

Formal verification, conformance, and security. As node diversity becomes a reality, the correctness guarantees must keep pace. The Plutus metatheory currently lacks formalization for many built-in functions, and conformance testing falls back to the Haskell reference implementation. Extending the metatheory to cover programmatic builtins and enriching the conformance test suite with a property-based testing framework would help close this gap. Meanwhile, continuous security auditing of the evaluator and costing code would proactively surface correctness and denial-of-service risks before they reach production.

Developer experience and tooling. The smart contract developer experience would benefit from a compiler architecture that produces clear, source-level error messages and eliminates the need for boilerplate and compiler-specific extensions. Beyond that, broader compiler version support and a simpler project setup that does not require Nix or native C library dependencies would make the user experience significantly simpler and more attractive, allowing a new developer to install, build, and write their first contract without friction.

Solution: This proposal funds three workstreams that together address all three areas.

Workstream 1. Plutus capabilities and primitives: extends the UPLC execution model, set of built-in functions, and expressiveness. It delivers support for casing on the built-in Data type, significantly reducing execution costs for most contracts due to the ubiquity of Data; an investigation and CIP or report on removing the redundant scope check (which adds approximately 25% overhead to script preparation); a SNARK-friendly Poseidon hash function CIP and C bindings conditional on benchmarks; implementation of the already-ratified multiIndexArray builtin (CIP-0156); and implementation of additional BuiltinValue functions for multi-asset operations (CIP-0168). It also delivers a CIP exploring laziness and memoization in UPLC, opening the design space for contract patterns that are modular, reusable, and less repetitive - patterns that are currently difficult or impossible to express.

Workstream 2. Formal specification, correctness, and security: strengthens the formal foundations of the Plutus platform. This stream delivers a property-based conformance testing framework, extending the current 1,982-test suite with randomly generated programs, which supports node diversity by enabling alternative Plutus evaluators to verify correctness against the canonical implementation; a systematic security and correctness audit of the security-critical code (such as the Plutus evaluator and costing); and formalization of programmatic built-in types and functions in the Plutus metatheory (Agda), making the metatheory an authoritative, executable specification for the covered built-ins rather than a partial formalization that falls back to the Haskell implementation.

Workstream 3. Developer experience: introduces a new compiler and optimizer architecture that improves code optimization, delivers clearer source-level error messages, and reduces boilerplate. It also simplifies setting up the development environment, removing the need for tools like Nix or manual dependency installation.

Why now: The Plutus team has completed development for the upcoming Van Rossem hard fork. This creates a natural window until the next hard fork, allowing Plutus to further extend its capabilities. Changes that require a hard fork, such as removing the scope check, need to be completed in time for the Dijkstra hard fork. At the same time, it is important to continue building on the developer experience and usability improvements we made over the past year, as further enhancements in this area are critical to Cardano’s adoption. Finally, as Cardano adoption increases and node diversity becomes a reality, the cost of any correctness or security issue is amplified. Investing in formal specification, cross-implementation conformance, and structured auditing now is significantly more cost-effective than responding to incidents in production.

Co-venture with VacuumLabs: This proposal is structured as a deliberate co-venture between Input | Output and VacuumLabs, a specialist firm with deep expertise in formal methods, security-critical Haskell development, and Cardano infrastructure. The partnership is planned and purposeful. Both organizations are investing in Plutus as shared public infrastructure for the Cardano ecosystem. This distributed ownership model reflects what a maturing ecosystem looks like: core infrastructure maintained by a consortium of expert teams, not dependent on any single contributor.

Proposed Value Delivered (Why)

Together, these workstreams enhance Cardano’s smart contract platform across three mutually reinforcing dimensions. Expanded language capabilities and lower execution costs directly translate into better returns for users and a more competitive offering relative to other chains. Formal verification, conformance testing, and continuous security auditing ensure that these gains rest on a sound foundation, which is increasingly important as node diversity expands. Tooling and developer-experience improvements lower the barrier to entry, allowing new developers to start building without friction and broadening the pool of people who write and deploy contracts.

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.

KPIs

Additional KPIs

Pillars

Deliverables and Roadmap

Resources

Workstream 1: Plutus Developer Experience

• 2 Compiler engineers (GHC backend and frontend work)
  
• 1 Compiler engineer (multi-version GHC support, Plinth dependency decoupling)
  
• 1 Language engineer (laziness and memoization investigation and CIP)

Workstream 2: UPLC Capabilities and Platform Primitives

• 1 Compiler and language engineer (built-in casing on Data),
• 1 Language engineer (scope check investigation)
  
• 1 Cryptography engineer (SNARK-friendly hash, Poseidon C bindings)
  
• 1 Language engineer (multiIndexArray CIP-0156 and BuiltinValue CIP-0168)

Workstream 3: Formal Specification, Correctness, and Security

• 1 Language and formal methods engineer (conformance property tests framework)
  
• 1 Security and language engineer (Plutus evaluator and costing audit)
  
• 1 Formal methods engineer (Agda formalization of Plutus primitives)

Budget

Total Treasury Ask: ₳11,877,575

Pricing Principles: IO is requesting funding in ada and has provided USD figures as a reference. A portion of the funding shall be specifically tied to demonstrating measurable impact on Cardano's KPIs and pillars.

• Personnel and Delivery: Majority of costs needed to fund the delivery resources across the IO internal team members and VacuumLabs co-proposer contributions across all three workstreams
  
• Ecosystem support, Audit, Assurance & Contingency: Leadership, ecosystem, and delivery to support execution and wider alignment. Independent work assurance and audits, plus contingency to account for complexities during execution

Risks

Additional Information

Benefit Dependencies: Realizing the cost and size reductions from Workstream 1 requires the corresponding hard fork to activate the new UPLC features on mainnet. The benefits of the property-based conformance framework depends on engagement from teams building alternative node clients.

Release and Solution Readiness: Plutus language and built-in extensions (casing on Data, multiIndexArray, and the additional BuiltinValue functions) are delivered as production-ready code and require a hard fork for activation on mainnet, with Dijkstra as the target. The scope check investigation and the laziness investigation are delivered as CIPs or technical reports; any subsequent implementation depends on community consensus and is out of scope for this proposal. The SNARK-friendly hash builtin is delivered as a CIP, with C bindings shipped conditional on benchmark results. The property-based conformance testing framework is released independently of the node and available for immediate use by alternative node implementers. The Agda formalization of programmatic built-ins ships as part of the Plutus metatheory, and will be used in conformance testing. The security and correctness audit is delivered as a written report with findings and recommendations. Developer experience and usability improvements from Workstream 3 are production-ready on delivery and can be adopted immediately by developers without waiting for a hard fork or any other governance or protocol-level change.

Demos and Assets: Plutus repository: https://github.com/IntersectMBO/plutus | Plutus Core formal spec: https://plutus.cardano.intersectmbo.org/resources/plutus-core-spec.pdf | Metatheory: https://plutus.cardano.intersectmbo.org/metatheory/latest/

Treasury Governance & Compliance

Contract Management

A written off-chain Legal Contract will be created between Input Output and the Cardano Development Holdings (CDH), as mandated by the Constitution, and will be administered by Intersect. This will include details of the project delivery schedule and dispute resolution.

Project Delivery

All milestones, acceptance criteria, payment amounts and expected delivery dates will be agreed between the Input Output and Intersect, acting on behalf of the CDH. Input Output will deliver according to the agreed-upon project schedule within the Legal Contract, of which the necessary information will be made public via the budget management platform via transaction metadata.

Defined by the milestones within a Legal Contract, Input Output will submit and attest milestone acceptance to the community, Intersect or 3rd Party Assurer.

Project progress will be monitored via Intersect's delivery assurance function which will be communicated to the community.

Acceptance of the work will be supported by a 3rd Party Assurer, who will be responsible for reviewing and signing off the work completed at each project milestone against the corresponding milestone deliverables detailed within the Legal Contract. This work is funded from a portion of this treasury withdrawal.

Auditable Accounts & Fund Delegation

Budget Management Tooling

To administrate treasury funds on-chain, Intersect will utilize the treasury management smart contract framework developed by Sundae Labs. The smart contracts have been extensively tested including audits from TxPipe and MLabs.

Final mainnet validation test can be seen via the Disburse action within transaction: 0f591dc544ae14102dbb4a74d5311a6acffc1772b163d8b7a9656b9525950b17

This withdrawal will utilise Intersect’s 2025 treasury reserve contract with address being: stake17xzc8pt7fgf0lc0x7eq6z7z6puhsxmzktna7dluahrj6g6ghh5qjr
Funds will later be migrated to a 2026 treasury reserve contract once established.

Budget Management Specifics

Intersect will utilize a single Treasury Reserve Smart Contract (TRSC), with many Project-Specific Smart Contracts (PSSC), managed by Intersect. Intersect's management consists of three 'admin' and two Intersect 'leadership' roles. An Oversight Committee consisting of five external, independent third-party entities will provide checks and balances on Intersect, and safeguard against errors and unilateral control. The administration of both TRSC and PSSCs will be managed by Intersect, with external oversight on certain actions from the Oversight Committee.

The 2025 TRSC Oversight Committee consists of Sundae Labs, Cardano Foundation, Dquadrant, Xerberus and NMKR. Their role is to independently verify key administrative actions using on-chain logic, ensuring accuracy and consistency without exercising discretion over governance decisions.

For all details on Intersect's configuration please see the Smart Contract Guide on the knowledgebase.

The high level permissions are as follows:

• TRSC Fund and PSSC Modify
  
  • Two of the three Intersect admins, two of the five trusted entities and one of the two Intersect leadership sign-off must authorize
    
• TRSC Disperse
  
  • Two of three Intersect admins, three of five trusted entities and two of two Intersect leadership sign-off must authorize
    
• TRSC Pause and Resume
  
  • Two of three Intersect admins, and one of two Intersect leadership sign-off must authorize
    
• TRSC Sweep
  
  • One of three Intersect admins, and one of two Intersect leadership sign-off must authorize
    
• TRSC Reorganize
  
  • Two of three Intersect admins and three of five trusted entities must authorize

Processes

Upon enactment of this governance action, funding for this project will be directed into the TRSC's stake account. All instances of TRSC and PSSC can not be staked with a SPO and will be delegated to the auto-abstain predefined DRep. From here funds will be withdrawn into a UTxO remaining at the TRSC.

When a 2026 TRSC is established, the funding for this project will be migrated via the ‘disburse’ action.

When the Legal contract is prepared and Input Output is ready, funding for this project will be transferred using the Fund action to a PSSC. All milestones will be outlined within the metadata.

A dashboard will be available for the community to audit the TRSC or PSSC and track metrics related to this withdrawn ada as well as being immutably verifiable on chain.

Funding Denomination

All amounts in this proposal are denominated in ada (₳). The total Treasury ask is ₳11,877,575. USD figures ($2,850,618) are provided for reference only, based on an ADA/USD rate of 0.24.

Refund Conditions

All funds not disbursed by the end of the delivery period will be returned to the Cardano Treasury. A final reconciliation will be published as part of the oversight reporting cycle. In the event of partial delivery or scope reduction, unspent funds associated with cancelled or reduced deliverables will be returned proportionally.

Prior Treasury Receipts

IO and its affiliated entities has been accountable for delivery of work funded by the Cardano Treasury. The total funds allocated has been ₳130,708,860 across a number of projects within Treasury Smart Contract, to date IOG has withdrawn ₳78,459,777.

**Note: for Catalyst this only reflects the workstream that focuses on the Hermes Infrastructure and UX/UI improvements, not the execution and operation of Funds 14-16. Per Info Action this is in the process of transitioning to Cardano Foundation.

Net Change Limit Compliance

The requested amount does not at time of submission, on its own or in aggregate, breach the applicable 350M Net Change Limit covering Epoch 613 to Epoch 713.

In accordance with the guardrail TREASURY-02a, this withdrawal does not exceed the NCL at the moment of submission.

Audit & Oversight

Audit and oversight costs are included within the overhead applied to this proposal. The Intersect administration fee covers administrative oversight and is reflected within the cost of this proposal. Independent oversight will be provided through Intersect and technically capable third-party, including reporting obligations and milestone-based disbursement controls.

Standardized Format & Immutable Hosting

Upon finalization, this proposal will be hosted on IPFS in an immutable format. The blake2b-256 hash of the document will be provided for on-chain reference and verification.