IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability
234 DReps voted · 80 with a rationale
Open a row to read the rationale.
- Yes 445.1K ₳ No rationale
- Yes 443.5K ₳ Rationale
I support all IO projects.
- Yes 441.7K ₳ No rationale
- No 438.7K ₳ No rationale
- Yes 426.2K ₳ Rationale
I’m a big fan of IO and everything they’ve accomplished over these nearly 10 years regarding Cardano. I believe it’s a top-tier company in terms of research, implementation, and blockchain, and I don’t question their capabilities at all.
However, as an observer—since I’m not deeply involved, but would still like to share my perspective. I feel that IO owes the community a clear, solid, and concise explanation of what has been achieved in previous governance actions. From my point of view, it’s very confusing; it feels like there are overlaps between this year’s proposals and last year’s, and it’s not clear at all.
It creates a lot of confusion, raising questions like: “Didn’t we already pay for this last year?” or “Why are we paying again if this was supposed to have been implemented already?” This starts to generate distrust across the community.I would like to see clear, measurable frameworks and informative checkpoints for all these governance actions something like a “Messari-style” State of Cardano report. I understand that a report like that isn’t cheap, but considering that we are about to spend nearly $40 million, the minimum expectation would be a clear report outlining what is intended to be achieved and what was accomplished last year.
This is a humongous amount of money, and it’s unreasonable for there to be so much confusion especially knowing that IO does very good work, yet their efforts start to be questioned. I wouldn’t like to see that happen. If producing such a report costs $50,000 or $100,000, then include it in the budget it doesn’t matter. There needs to be clarity and a formal way to track the return on what is being done. It’s simply too much money for this to remain so informal.
This time, I will support the proposal. However, I want to express that if clarity fails again in future proposals if ambiguity and confusion persist regarding what was delivered versus what was supposed to be delivered—then unfortunately I won’t be able to support with my vote. Cardano is no longer what it was five years ago; now it’s up to us to ensure that what gets done is logical and properly scrutinized.
- Abstain 385.6K ₳ Rationale
Abstaining, as I’m part of the Cardano Constitution Committee Tingvard.
Reading proposals and staying updated, just like you.
Thanks to all fellow DReps who are also doing the hard work.
Follow and DM me on X: @kenerik if you have any questions. - Yes 382.6K ₳ No rationale
- No 377.3K ₳ No rationale
- No 365.3K ₳ No rationale
- Yes 332K ₳ No rationale
- Yes 328.9K ₳ No rationale
- Yes 327.1K ₳ No rationale
- Yes 321.1K ₳ No rationale
- Yes 314.4K ₳ Rationale
I am voting YES. While not a strict “keep the lights on” need, enhancing Plutus is essential for Cardano's DeFi competitiveness. Making smart contracts cheaper and faster is vital. I also applaud the improved budget transparency in this proposal compared to recent requests.
A PDF version of this rationale is also made available.
I am voting YES on this proposal for the following key reasons:
Crucial for Competitiveness & DeFi: To remain relevant, we need cheaper on-chain execution costs that open up application designs that were previously uneconomical. Targeted expansions, such as removing the redundant scope check (which currently adds roughly 25% to script preparation time) and adding new primitives, will significantly reduce execution budgets. This is fundamental for our DeFi ecosystem to flourish and attract deeper liquidity.
Supporting Node Diversity: I have consistently voted to strengthen Cardano’s resilience through technical diversity, such as funding alternative node clients like Amaru and Dingo. This proposal directly supports those initiatives. By delivering a property-based conformance testing framework and authoritative Agda formalisations, alternative full node builders gain the tools needed to verify their evaluators against the canonical implementation.
A Step Forward in Budget Transparency: In my previous rationales, I strongly criticised the "black box" nature of IO’s funding requests and the lack of full-time equivalent (FTE) granularity. I am pleased to see that this proposal provides a clear breakdown of the required engineering resources (e.g., specific allocations for compiler, cryptography, and formal methods engineers). While there is always room for improvement, this allows us to make rough FTE estimates and represents a much-needed shift toward the responsible and justifiable treasury spending I advocate for.
Closing Thoughts
We must continue to equip developers with the best possible tools to build without friction. Furthermore, by distributing the stewardship of Plutus alongside VacuumLabs - a specialist firm with deep expertise - we are moving away from a single point of failure. This distributed ownership model is exactly the kind of ecosystem sustainability and resilience our digital nation needs.
- Yes 313.1K ₳ No rationale
- Yes 298.6K ₳ Rationale
Voting YES on ALL IOG Withdrawals
May 20th 2026
Summery
Nine treasury withdrawals from IOG totalling around 162M ada ($40M USD)
Important Citation
https://x.com/EdnStuff/status/2051321214728118360
EdnStuff said the following on May 4th 2026
I see the IO proposals as a package deal. But by all accounts I see most dreps only voting yes on a small selection of the 9. This is going to lead to some extremely lopsided, fragmented, and piecemeal results that will fall short of what we need on #Cardano $ADA.Charles quote tweeted saying
https://x.com/IOHK_Charles/status/2051376829949464792
Sadly, this is the end result of a piecemeal roadmap. It's an iPhone by committee, with people deciding whether they prefer the fingerprint sensor to wireless charging. You end up with a bizarre, useless product.Statement
There are a handful of people who, when they speak, I think it unwise not to listen to. Charles is one such person. His statement above makes this choice pretty easy.
While we need to foster a wide ecosystem of R&D firms, we cannot afford to jeopardize our relationship with our biggest contributor. It is obvious and undeniable that the long-term success of Cardano remains dependent on the continued efforts of IO.
I am voting for all of these IO proposals because Charles has made it clear that he does not believe Cardano can be successful without each of them, and it would be unwise to disregard his intuition.
Signed,
William DoyleYour friendly neighbourhood DRep!
$computerman
drep1yfpgzfymq6tt9c684e7vzata8r5pl4w84fmrjqeztdqw0sgpzw3nt
https://x.com/william00000010 - No 295.2K ₳ No rationale
- No 279.5K ₳ No rationale
- Yes 271.5K ₳ No rationale
- Yes 261.3K ₳ No rationale
- No 258.6K ₳ Rationale
Review Methodology Disclaimer [EN]
Due not only to the unusually high volume of Treasury Withdrawal Governance Actions and budget proposals submitted in April and May 2026, but also to the lack of meaningful incentives for DReps to perform proposal analysis work, it is not feasible to apply my full standard review framework and reporting template to every proposal.
My standard analysis process usually requires approximately four hours of work per Governance Action. During that process, I research the proposal, review supporting materials, compare different perspectives from DReps and other ecosystem participants, and weigh both positive and negative arguments before reaching a reasonably qualified decision. Even with the use of artificial intelligence to automate parts of the workflow and improve productivity, a responsible evaluation still requires substantial human review, judgment, and contextual understanding.
In addition, this work does not end with the vote itself. It also involves writing and publishing rationales, preparing reports or summaries, communicating the reasoning publicly, and socializing the analysis through public channels and social media. This creates a significant workload, especially when dozens of proposals must be reviewed in a short period.
At present, this work carries no clear financial incentive and only limited reputational incentive, despite requiring substantial time, attention, and accountability. In practice, it is not sustainable to dedicate near full-time effort over several weeks or months to this activity without any form of compensation or institutional support.
Since I have a clear standard for my work and do not want to lower the quality of my judgment, I will reduce the scope of my analysis where necessary rather than rush decisions or produce superficial rationales. This means prioritizing focused due diligence over exhaustive review.
Under these constraints, my methodology during this period will focus on identifying critical strategic, operational, governance, reputational, or execution-related risks that could materially compromise a proposal’s viability, accountability, or successful delivery. In practical terms, this means narrowing my research toward the most critical gaps that may make approval unjustifiable. Where such a serious risk is identified, I may use it as the basis for a rejection vote.
This approach also helps reduce review overload: proposals with clear and material gaps would likely require rework regardless, so voting against them when those gaps are significant can be a responsible way to preserve review capacity while maintaining minimum due diligence.
Examples of such high-priority concerns may include, but are not limited to:
- Serious delivery failures in previous funded proposals;
- Significant unresolved delays in ongoing work;
- Major reputational or accountability issues within the ecosystem;
- Lack of credible execution capacity;
- Structural governance or transparency concerns;
- Severe budgetary or coordination risks.
Where I do not have sufficient time for a deeper evaluation, and no significant red flags or imminent execution risks are identified, I may abstain rather than issue an underdeveloped approval or rejection rationale.
This does not mean that other dimensions of proposal quality are unimportant. It means that, under current constraints, I will prioritize a narrower but still responsible review scope that preserves minimum due diligence, avoids rushed decisions, and keeps the quality of my judgment at an acceptable standard.
Governance Action Review — Enhancing Plutus
1. Introduction
The governance action requests ₳11,877,575 from the Cardano Treasury to fund the proposal “Enhancing Plutus,” delivered through a partnership between Input Output and VacuumLabs. The proposal focuses on advancing the Plutus platform through improvements to developer experience, extensions to UPLC capabilities and primitives, formal specification, conformance testing, and security-related work.
The proposal is organized around three workstreams. The first workstream addresses Plutus capabilities and primitives, including built-in casing on the Data type, implementation of CIP-0156 multiIndexArray, additional BuiltinValue functions under CIP-0168, investigation of the scope check, and exploration of laziness and memoization in UPLC. The second workstream focuses on formal specification, correctness, and security, including property-based conformance testing, formalization of Plutus primitives in Agda, and security review of evaluator and costing logic. The third workstream focuses on developer experience, including compiler and optimizer architecture improvements, clearer source-level error messages, reduced boilerplate, multi-version GHC support, and simplified Plinth setup.
The roadmap spans Q3 2026 to Q2 2027. The proposal identifies a total treasury ask of ₳11,877,575, with ₳10,214,715 allocated to Development, representing 86% of the total budget. Additional categories include Infrastructure, Security & Audits, Legal & Compliance, Engagement & Ecosystem Support, Operations & Delivery, Governance, and Others. :contentReference[oaicite:0]{index=0}
2. Governance Action Analysis
Positive aspects
The vote NO does not rely on technical opposition to the proposal, nor on rejection of Plutus development, UPLC, formal methods, developer experience, or improvements to Cardano’s smart contract base.
Potentially useful improvements for the ecosystem are recognized, including execution cost reduction, tooling improvements, formalization, conformance testing, and support for greater implementation diversity.
The proposal also presents a clearer technical structure than some other treasury requests, with workstreams, roadmap, and deliverables described across Q3 2026 to Q2 2027.
Negative aspects
The decisive issue is the lack of sufficient budget granularity.
The proposal requests ₳11,877,575, of which ₳10,214,715, or 86%, is allocated generically to “Development.” Although the proposal lists technical profiles and workstreams, it does not provide sufficient detail on FTEs, duration per role, rate assumptions, seniority, cost split between IO and VacuumLabs, cost per workstream, cost per deliverable, or cost per milestone.
For a treasury withdrawal of this size, this level of aggregation is not sufficient.
Risks and concerns
There is not enough deep technical knowledge of the tech stack to state with confidence that each proposed implementation is necessary, prioritized correctly, or properly priced.
Based on the proposal and rationales from other dReps, the work appears relevant and positive, but not necessarily critical or urgent enough to overcome budget transparency failures.
This point is especially important as a matter of institutional coherence. Over the years, in the Cardano ecosystem and Project Catalyst, many proposals with five-, six-, or seven-figure budgets were criticized or rejected due to lack of budget granularity. It would be inconsistent to lower the standard of rigor precisely when the request involves a founding entity, relevant technical infrastructure, and a budget of almost ₳12 million.
The technical relevance of a proposal does not remove the need for treasury discipline. On the contrary, the larger the budget and the more central the scope, the greater the level of transparency that should be required.
3. Vote and Rationale
Vote: NO
The vote NO should not be interpreted as opposition to the technical merit of the proposal or to the evolution of Plutus infrastructure.
The reason for the vote NO is exclusively the lack of sufficient budget granularity.
The proposal requests ₳11.877.575, of which ₳10.214.715, or 86%, is allocated generically to “Development.” Although technical profiles and workstreams are listed, there is not enough detail on FTEs, duration per function, rate assumptions, seniority, division of costs between IO and VacuumLabs, cost per workstream, cost per deliverable, or cost per milestone.
For a treasury withdrawal of this size, this level of aggregation is not sufficient.
Large treasury withdrawals need to present an auditable, proportional, and sufficiently granular cost model so that dReps and the community can evaluate whether the requested amount is reasonable, efficient, and well distributed.
Conditions or signals that could change the vote: Unknown.
4. Conclusion
The vote NO reflects a governance position on treasury discipline. The proposal may contain relevant technical work for Plutus and Cardano’s smart contract infrastructure, but a request of almost ₳12 million requires a more granular, auditable, and proportionate budget model before it can receive support.
Nota sobre metodologia e escopo de análise [PT]
Devido não apenas ao volume excepcionalmente alto de Treasury Withdrawal Governance Actions e propostas orçamentárias submetidas em abril e maio de 2026, mas também à falta de incentivos significativos para que DReps realizem o trabalho de análise de propostas, não é viável aplicar meu framework completo de revisão e meu template padrão de relatório a todas as propostas.
Meu processo padrão de análise normalmente exige aproximadamente quatro horas de trabalho por Governance Action. Durante esse processo, eu pesquiso a proposta, reviso materiais de suporte, comparo diferentes perspectivas de DReps e de outros participantes do ecossistema, e peso argumentos positivos e negativos antes de chegar a uma decisão razoavelmente qualificada. Mesmo com o uso de inteligência artificial para automatizar partes do fluxo de trabalho e aumentar a produtividade, uma avaliação responsável ainda exige revisão humana substancial, julgamento e entendimento contextual.
Além disso, esse trabalho não termina no voto em si. Ele também envolve escrever e publicar rationales, preparar relatórios ou resumos, comunicar publicamente a justificativa e socializar a análise por meio de canais públicos e mídias sociais. Isso cria uma carga de trabalho significativa, especialmente quando dezenas de propostas precisam ser avaliadas em um curto período.
Atualmente, esse trabalho não possui incentivo financeiro claro e oferece apenas incentivo reputacional limitado, apesar de exigir tempo, atenção e responsabilidade substanciais. Na prática, não é sustentável dedicar um esforço próximo de tempo integral durante várias semanas ou meses a essa atividade sem qualquer forma de compensação ou apoio institucional.
Como tenho um padrão claro para o meu trabalho e não quero reduzir a qualidade do meu julgamento, irei reduzir o escopo da minha análise quando necessário, em vez de tomar decisões apressadas ou produzir justificativas superficiais. Isso significa priorizar uma diligência focada em vez de uma revisão exaustiva.
Sob essas restrições, minha metodologia durante este período se concentrará em identificar riscos críticos estratégicos, operacionais, de governança, reputacionais ou relacionados à execução que possam comprometer materialmente a viabilidade, a accountability ou a entrega bem-sucedida de uma proposta. Na prática, isso significa concentrar minha pesquisa nos gaps mais críticos que possam tornar a aprovação injustificável. Quando um risco sério desse tipo for identificado, poderei usá-lo como base para um voto de rejeição.
Essa abordagem também ajuda a reduzir a sobrecarga de revisão: propostas com gaps claros e materiais provavelmente exigiriam retrabalho de qualquer forma, então votar contra elas quando esses gaps forem significativos pode ser uma forma responsável de preservar capacidade de análise enquanto se mantém uma diligência mínima.
Exemplos dessas preocupações de alta prioridade podem incluir, mas não se limitam a:
- Falhas graves de entrega em propostas anteriormente financiadas;
- Atrasos significativos e não resolvidos em trabalhos em andamento;
- Problemas graves de reputação ou accountability dentro do ecossistema;
- Falta de capacidade crível de execução;
- Preocupações estruturais de governança ou transparência;
- Riscos severos de orçamento ou coordenação.
Quando eu não tiver tempo suficiente para uma avaliação mais profunda, e nenhum alerta significativo ou risco iminente de execução for identificado, poderei me abster em vez de emitir uma justificativa de aprovação ou rejeição pouco desenvolvida.
Isso não significa que outras dimensões da qualidade de uma proposta não sejam importantes. Significa que, sob as restrições atuais, priorizarei um escopo de revisão mais estreito, mas ainda responsável, que preserve uma diligência mínima, evite decisões apressada
Revisão de Ação de Governança — Enhancing Plutus
1. Introdução
A ação de governança solicita ₳11.877.575 do Tesouro da Cardano para financiar a proposta “Enhancing Plutus”, executada por meio de uma parceria entre Input Output e VacuumLabs. A proposta tem como foco avançar a plataforma Plutus por meio de melhorias na experiência de desenvolvedores, extensões de capacidades e primitivas de UPLC, especificação formal, testes de conformidade e trabalho relacionado à segurança.
A proposta é organizada em três workstreams. O primeiro workstream aborda capacidades e primitivas de Plutus, incluindo built-in casing para o tipo Data, implementação do multiIndexArray da CIP-0156, funções adicionais BuiltinValue da CIP-0168, investigação do scope check e exploração de laziness e memoization em UPLC. O segundo workstream foca em especificação formal, correção e segurança, incluindo testes de conformidade baseados em propriedades, formalização de primitivas Plutus em Agda e revisão de segurança da lógica de avaliação e costing. O terceiro workstream foca em experiência de desenvolvedores, incluindo melhorias na arquitetura de compilador e otimizador, mensagens de erro mais claras em nível de código-fonte, redução de boilerplate, suporte a múltiplas versões de GHC e simplificação do setup do Plinth.
O roadmap cobre o período de Q3 2026 a Q2 2027. A proposta identifica uma solicitação total ao tesouro de ₳11.877.575, com ₳10.214.715 alocados em Development, representando 86% do orçamento total. As demais categorias incluem Infrastructure, Security & Audits, Legal & Compliance, Engagement & Ecosystem Support, Operations & Delivery, Governance e Others. :contentReference[oaicite:1]{index=1}
2. Análise da Ação de Governança
Aspectos positivos
O voto NO não se baseia em oposição técnica à proposta, nem em rejeição ao desenvolvimento de Plutus, UPLC, formal methods, developer experience ou melhorias na base de smart contracts da Cardano.
São reconhecidas melhorias potencialmente úteis para o ecossistema, incluindo redução de custos de execução, aprimoramentos de tooling, formalização, testes de conformidade e suporte a maior diversidade de implementações.
A proposta também apresenta uma estrutura técnica mais clara do que algumas outras solicitações de tesouro, com workstreams, roadmap e entregas descritas ao longo de Q3 2026 a Q2 2027.
Aspectos negativos
O ponto decisivo é a falta de granularidade suficiente no orçamento.
A proposta solicita ₳11.877.575, dos quais ₳10.214.715, ou 86%, são alocados genericamente em “Development”. Embora a proposta liste perfis técnicos e workstreams, ela não fornece detalhamento suficiente sobre FTEs, duração por função, rate assumptions, senioridade, divisão de custos entre IO e VacuumLabs, custo por workstream, custo por deliverable ou custo por milestone.
Para uma retirada de tesouro desse porte, esse nível de agregação não é suficiente.
Riscos e preocupações
Não há conhecimento técnico profundo o suficiente do tech stack para afirmar, com segurança, que cada implementação proposta é necessária, prioritária ou corretamente precificada.
A partir da leitura da proposta e dos rationales de outros dReps, o trabalho parece relevante e positivo, mas não necessariamente crítico ou urgente a ponto de superar falhas de transparência orçamentária.
Esse ponto é especialmente importante por uma questão de coerência institucional. Ao longo dos anos, no ecossistema Cardano e no Project Catalyst, muitas propostas com orçamentos de cinco, seis ou sete figuras foram criticadas ou rejeitadas por falta de granularidade orçamentária. Seria inconsistente baixar o padrão de rigor justamente quando a solicitação envolve uma entidade fundadora, infraestrutura técnica relevante e um orçamento de quase ₳12 milhões.
A relevância técnica de uma proposta não elimina a necessidade de disciplina de tesouro. Pelo contrário: quanto maior o orçamento e quanto mais central o escopo, maior deveria ser o nível de transparência exigido.
3. Voto e Justificativa
Voto: NO
O voto NO não deve ser interpretado como oposição ao mérito técnico da proposta ou à evolução da infraestrutura Plutus.
O motivo do voto NO é única e exclusivamente a falta de granularidade suficiente no orçamento.
A proposta solicita ₳11.877.575, dos quais ₳10.214.715, ou 86%, são alocados genericamente em “Development”. Embora a proposta liste perfis técnicos e workstreams, ela não fornece detalhamento suficiente sobre FTEs, duração por função, rate assumptions, senioridade, divisão de custos entre IO e VacuumLabs, custo por workstream, custo por deliverable ou custo por milestone.
Para uma retirada de tesouro desse porte, esse nível de agregação não é suficiente.
Grandes retiradas do tesouro precisam apresentar um modelo de custo auditável, proporcional e suficientemente granular para que dReps e a comunidade possam avaliar se o valor solicitado é razoável, eficiente e bem distribuído.
Condições ou sinais que poderiam alterar o voto: Unknown.
4. Conclusão
O voto NO reflete uma posição de governança sobre disciplina de tesouro. A proposta pode conter trabalho técnico relevante para Plutus e para a infraestrutura de smart contracts da Cardano, mas uma solicitação de quase ₳12 milhões exige um modelo orçamentário mais granular, auditável e proporcional antes de receber apoio.
- Yes 257K ₳ Rationale
I am voting YES on “IO & VacuumLabs – Enhancing Plutus: Performance, Correctness, and Usability.”
This proposal is a focused, technically strong package that tackles three long‑standing bottlenecks in Cardano’s smart contract stack: execution cost and expressiveness, formal correctness for a world with multiple node implementations, and practical developer experience. It delivers concrete artifacts on a clear roadmap: new built‑ins like CIP‑0156 multiIndexArray and CIP‑0168 BuiltinValue functions plus casing on Data to reduce script size and execution units; a scoped investigation of removing the scope check and a CIP on laziness/memoization in UPLC; a property‑based conformance framework and expanded Agda metatheory for Plutus primitives; systematic audits of evaluator and costing code; and a new Plinth compiler backend that works with multiple GHC versions, ships binaries for major platforms, drops Nix/native‑library friction, and surfaces clearer source‑level errors.
These deliverables map directly to Cardano’s 2030 KPIs and pillars. Cheaper, more expressive scripts and better tooling enable richer DeFi and on‑chain applications and higher transaction volumes; stronger formal specifications and conformance testing reduce the risk of subtle consensus bugs as alternative node implementations emerge; and a simpler Plutus toolchain lowers the drop‑off rate for new developers, which is critical for MAU and ecosystem growth. The budget is mid‑sized relative to other 2026 asks, heavily weighted toward engineering and formal‑methods work across IO and VacuumLabs, with specific milestones, code, CIPs, tests, and documentation attached to each line item.
I share some of the concerns voiced by other DReps about IO’s large cumulative treasury allocation and the need for more fine‑grained cost modeling and prior‑results reporting in future core‑protocol proposals. However, in this case the internal structure, technical scope, and expected impact are strong enough that, on balance, I consider this a justified investment in Cardano’s smart contract foundations, and I will support it with a YES vote. - Yes 245K ₳ Rationale
The VacuumLabs co-venture is the right model - distributing stewardship of critical language infrastructure to a specialist third party is exactly the direction Cardano's development ecosystem needs to travel. Lower UPLC execution costs directly increase effective smart contract throughput without requiring protocol parameter changes. The conformance testing framework (Workstream 2) is essential infrastructure for node diversity and directly complements Tweag's own conformance testing work. The security audit of the Plutus evaluator is overdue given increasing DApp TVL. At 11.88M ADA with this co-venture structure, this is a responsible spend.
- Yes 238.2K ₳ No rationale
- Yes 237.5K ₳ No rationale
- Yes 234.1K ₳ No rationale
- Abstain 215.5K ₳ No rationale
- Yes 212.5K ₳ No rationale
- No 208.6K ₳ Rationale
I'm increasingly concerned about Cardano's overall treasury spend rate, especially following the recent approval of the Draper/Dragon Orion Fund. To provide a necessary counter-balance, I am defaulting to NO on treasury withdrawals at this time.
This proposal (₳11.8M) is important infrastructure work, but it does not meet my strict criteria for approval right now. It is not core/critical infrastructure such as IO Hydra L2 production hardening or deliverables directly required to advance the Midnight partnership.
I will continue voting YES only on the highest-priority items that directly strengthen essential scaling and partnership infrastructure. - Yes 207.3K ₳ No rationale
- Yes 206.4K ₳ No rationale
- Yes 203.6K ₳ No rationale
- Yes 190.2K ₳ No rationale
- No 183.7K ₳ No rationale
- Yes 182K ₳ No rationale
- Yes 181.9K ₳ No rationale
- Abstain 180.9K ₳ No rationale
- Yes 142.3K ₳ No rationale
- Yes 137.3K ₳ No rationale
- Yes 131.7K ₳ No rationale
- Abstain 131.6K ₳ No rationale
- Yes 127.9K ₳ No rationale
- Yes 120.8K ₳ No rationale
- Yes 120.1K ₳ No rationale
- Yes 115.6K ₳ No rationale
- Abstain 115.4K ₳ Rationale
I am voting to abstain on this one. I acknowledge the importance of improving Plutus performance, lowering execution costs, strengthening formal correctness, enhancing conformance testing, and reducing friction in the developer experience. These are worthwhile goals that align with Cardano’s long-term emphasis on resilience, security, and high-assurance infrastructure.
However, after supporting proposals focused on scaling (Leios), user and ecosystem usability (Babel Fees/CIP-159), and formal verification and high-assurance tooling, I remain uncertain about the degree to which this proposal delivers distinct incremental value relative to adjacent investments already receiving support.
My hesitation is not opposition to the objectives (hence abstaining vs voting "No") but uncertainty around prioritization, overlap, and opportunity cost. Multiple initiatives now seek to improve developer experience, security, correctness, and onboarding. I would like stronger evidence demonstrating how these investments differentiate from one another and which bottlenecks they most directly address in accelerating ecosystem growth and adoption.
I view this proposal as potentially valuable, but I am not sufficiently persuaded at this time to support additional Treasury allocation in this category, nor do I believe the proposal’s merits warrant outright rejection.
This abstention reflects a preference for continued scrutiny around sequencing and cumulative investment across overlapping infrastructure initiatives, while recognizing the importance of maintaining Cardano’s strengths in security and technical rigor.
- Yes 111.7K ₳ No rationale
- Yes 100.3K ₳ No rationale
- Yes 96.4K ₳ No rationale
- Yes 88.7K ₳ No rationale