IO: Cardano High Assurance Technical Collaboration
236 DReps voted · 80 with a rationale · 7 changed their vote · 7 re-voted unchanged
Open a row to read the rationale.
Changed votes: 6 to yes, 1 to abstain, together voting with 115.9M ₳ of voting power.
- No90.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 Report — Cardano High Assurance
1. Introduction
Cardano High Assurance requests ₳13,078,578 from the Cardano Treasury to deliver automated formal verification tooling and a unified, containerized developer environment for secure and verifiable smart contract development on Cardano.
The proposal is organized into two workstreams: Blaster, IO’s automated formal verification tool for Lean 4 and UPLC-based smart contracts, and CBDE, a Container-Based Developer Environment intended to reduce setup friction for developers using the Plinth high-assurance toolkit.
The Blaster workstream includes DApp-level verification, language integrations for Aiken, Pebble, Scalus, and Futura, a VS Code extension, a Common Vulnerability Library, an equivalence checking tool, and proof reconstruction.
The CBDE workstream includes a pre-configured environment with compilers, libraries, property-based testing, static analysis, formal verification, and profiling tools.
The proposal presents this work as a way to make high-assurance development more accessible and to support Cardano’s positioning around correctness, security, and institutional-grade applications.
2. Governance Action Analysis
Positive aspects
This vote should not be interpreted as opposition to formal verification, high-assurance development, developer tooling, or the technical capabilities of the teams involved.
The proposal addresses a legitimate area of technical improvement for Cardano. Tools such as Blaster, language integrations, the Common Vulnerability Library, VS Code support, and the Container-Based Developer Environment may contribute to safer smart contract development and better developer experience over time.
Negative aspects
Technical value alone is not sufficient to justify treasury funding at this scale.
The proposal requests ₳13,078,578, with ₳11,247,577, or 86% of the total budget, allocated to “Development.”
While the proposal provides a high-level split between the Blaster workstream and the CBDE workstream, it does not provide enough granular detail on FTE allocation, team-by-team budget distribution, rate assumptions, seniority levels, subcontractor allocations, or the specific mapping between budget amounts and deliverables.
For a multi-million-ADA treasury withdrawal, this level of budget abstraction is not sufficient for dReps and the community to assess whether the requested amount is proportionate, efficient, or properly scoped.
This concern is consistent with the standard applied in previous votes. Large treasury requests require clear budget breakdowns.
If dReps accept broad development categories without sufficient cost justification, it becomes difficult to enforce treasury discipline across the rest of the ecosystem.
A second concern is the lack of sufficiently concrete and measurable impact targets.
The proposal aligns itself with Cardano Vision 2030 and connects the work to KPIs such as TVL, monthly transactions, monthly active users, protocol revenue, and throughput capacity. However, many of these connections remain indirect, speculative, or difficult to verify.
Formal verification may improve security and confidence, but the proposal does not clearly demonstrate how this work will materially move the needle on adoption, liquidity, transaction volume, developer retention, or ecosystem growth within a measurable timeframe.
For example, the proposal states that CBDE could reduce a multi-day setup process to a 60-second initialization and expects a 3–5x increase in active Plinth developers within 12 months of release.
These are relevant claims, but they would be stronger with clearer baselines, current developer counts, measurement methodology, and independently verifiable milestone targets.
Risks and concerns
The proposal acknowledges that delivery alone may not produce adoption.
It states that community visibility and developer outreach are required to convert tool delivery into measurable MAU and KPI impact, but these activities are not fully funded within this proposal and depend on coordination with other initiatives.
This weakens the link between the requested treasury spend and the broader ecosystem outcomes used to justify it.
A third concern is prioritization.
This proposal is a desirable technical addition rather than a pressing ecosystem need.
It does not appear to be part of the direct continuity of core development or maintenance of existing critical infrastructure in the same way as some other IO-related proposals.
It may improve the quality and security of Cardano’s technical stack over time, but it is not clear that this is among the most urgent constraints currently facing the ecosystem.
Under the current Net Change Limit environment, this matters.
The ecosystem is already directing substantial treasury resources toward infrastructure, protocol development, maintenance, scalability, and other technical initiatives. A significant share of these resources is also flowing to IO or IO-affiliated workstreams.
The proposal itself states that IO and affiliated entities have already been allocated ₳130,708,860 across treasury-funded projects, with ₳78,459,777 withdrawn to date.
That does not mean IO should be excluded from funding. IO remains an important technical contributor to Cardano.
But repeated large allocations to the same organization increase the burden of transparency, cost justification, and prioritization.
If treasury funding continues to concentrate heavily in infrastructure and IO-led initiatives, other crucial areas of the ecosystem may be left without sufficient funding.
3. Vote and Rationale
Vote: NO
This treasury withdrawal is rejected primarily due to insufficient budget granularity, limited measurable impact targets, and concerns about prioritization under the current Net Change Limit constraints.
The vote is based on three main concerns:
- Insufficient budget granularity for a proposal of this size.
- Insufficiently concrete impact metrics, targets, and baselines to evaluate contribution to Cardano Vision 2030.
- Weak prioritization under current NCL constraints, since this appears to be a desirable high-assurance tooling initiative rather than an urgent ecosystem need.
This type of proposal would be more open to reconsideration if it included a more detailed budget breakdown, clearer team-level accountability, stronger KPI baselines and targets, measurable adoption criteria, and a clearer explanation of why this work should be prioritized over other competing treasury needs in this funding cycle.
4. Conclusion
The proposal addresses a valid technical area and may improve Cardano’s high-assurance development tooling over time.
However, the requested funding is not supported by sufficient budget granularity, concrete impact measurement, or prioritization strength under current NCL constraints.
For these reasons, the proposal cannot be supported in its current form.
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 apressadas e mantenha a qualidade do meu julgamento em um padrão aceitável.
Relatório de Ação de Governança — Cardano High Assurance
1. Introdução
A Cardano High Assurance solicita ₳13.078.578 do Tesouro da Cardano para entregar ferramentas automatizadas de verificação formal e um ambiente de desenvolvimento unificado e containerizado para desenvolvimento seguro e verificável de smart contracts na Cardano.
A proposta é organizada em dois workstreams: Blaster, a ferramenta de verificação formal automatizada da IO para Lean 4 e smart contracts baseados em UPLC, e CBDE, um Container-Based Developer Environment destinado a reduzir a fricção de configuração para desenvolvedores que usam o toolkit de alta garantia Plinth.
O workstream Blaster inclui verificação em nível de DApp, integrações de linguagem para Aiken, Pebble, Scalus e Futura, uma extensão para VS Code, uma Common Vulnerability Library, uma ferramenta de equivalence checking e proof reconstruction.
O workstream CBDE inclui um ambiente pré-configurado com compiladores, bibliotecas, testes baseados em propriedades, análise estática, verificação formal e ferramentas de profiling.
A proposta apresenta esse trabalho como uma forma de tornar o desenvolvimento de alta garantia mais acessível e de apoiar o posicionamento da Cardano em torno de correção, segurança e aplicações de nível institucional.
2. Análise da Ação de Governança
Aspectos positivos
Este voto não deve ser interpretado como oposição à verificação formal, desenvolvimento de alta garantia, ferramentas para desenvolvedores ou às capacidades técnicas das equipes envolvidas.
A proposta aborda uma área legítima de melhoria técnica para a Cardano. Ferramentas como Blaster, integrações de linguagem, Common Vulnerability Library, suporte a VS Code e Container-Based Developer Environment podem contribuir para um desenvolvimento de smart contracts mais seguro e uma melhor experiência para desenvolvedores ao longo do tempo.
Aspectos negativos
Valor técnico, por si só, não é suficiente para justificar financiamento do tesouro nesta escala.
A proposta solicita ₳13.078.578, com ₳11.247.577, ou 86% do orçamento total, alocados para “Development.”
Embora a proposta forneça uma divisão de alto nível entre o workstream Blaster e o workstream CBDE, ela não fornece granularidade suficiente sobre alocação de FTEs, distribuição orçamentária por equipe, premissas de rate, níveis de senioridade, alocações para subcontratados ou o mapeamento específico entre valores orçamentários e entregáveis.
Para uma retirada de tesouro de vários milhões de ADA, esse nível de abstração orçamentária não é suficiente para que dReps e a comunidade avaliem se o valor solicitado é proporcional, eficiente ou adequadamente escopado.
Essa preocupação é consistente com o padrão aplicado em votos anteriores. Grandes solicitações de tesouraria exigem breakdowns orçamentários claros.
Se dReps aceitarem categorias amplas de desenvolvimento sem justificativa suficiente de custo, torna-se difícil aplicar disciplina de tesouraria no restante do ecossistema.
Uma segunda preocupação é a falta de metas de impacto suficientemente concretas e mensuráveis.
A proposta se alinha à Cardano Vision 2030 e conecta o trabalho a KPIs como TVL, transações mensais, usuários ativos mensais, receita do protocolo e capacidade de throughput. No entanto, muitas dessas conexões permanecem indiretas, especulativas ou difíceis de verificar.
Verificação formal pode melhorar segurança e confiança, mas a proposta não demonstra claramente como esse trabalho irá mover materialmente a agulha em adoção, liquidez, volume de transações, retenção de desenvolvedores ou crescimento do ecossistema dentro de um período mensurável.
Por exemplo, a proposta afirma que o CBDE poderia reduzir um processo de configuração de vários dias para uma inicialização de 60 segundos e espera um aumento de 3–5x no número de desenvolvedores Plinth ativos em até 12 meses após o lançamento.
Essas são afirmações relevantes, mas seriam mais fortes com baselines mais claros, contagens atuais de desenvolvedores, metodologia de mensuração e metas de milestone independentemente verificáveis.
Riscos e preocupações
A proposta reconhece que a entrega, por si só, pode não produzir adoção.
Ela afirma que visibilidade comunitária e outreach para desenvolvedores são necessários para converter a entrega das ferramentas em impacto mensurável em MAU e KPIs, mas essas atividades não são totalmente financiadas dentro desta proposta e dependem de coordenação com outras iniciativas.
Isso enfraquece o vínculo entre o gasto solicitado do tesouro e os resultados mais amplos do ecossistema usados para justificá-lo.
Uma terceira preocupação é priorização.
Esta proposta é uma adição técnica desejável, e não uma necessidade urgente do ecossistema.
Ela não parece fazer parte da continuidade direta do core development ou da manutenção de infraestrutura crítica existente da mesma forma que algumas outras propostas relacionadas à IO.
Ela pode melhorar a qualidade e a segurança do stack técnico da Cardano ao longo do tempo, mas não está claro que esteja entre as restrições mais urgentes enfrentadas atualmente pelo ecossistema.
No ambiente atual de Net Change Limit, isso importa.
O ecossistema já está direcionando recursos substanciais do tesouro para infraestrutura, desenvolvimento de protocolo, manutenção, escalabilidade e outras
- Yes85.7K ₳No rationale
- Yes83.9K ₳Rationale
I am voting in favor of the Cardano High Assurance Technical Collaboration. This proposal ensures that the network continues to double down on the security guarantees and I believe this is the right focus for our community to maintain.
By funding this collaboration, we are protecting one of Cardano's most valuable asset—its reputation for being the top prospect of high-assurance engineering.
Also I believe that as the ecosystem expands into complex DeFi, identity systems, and enterprise solutions, the cost of a single major exploit would far outweigh the cost of this proposal.
Security is an ongoing process and we should keep funding it and keep the experts in the community working on it. This proposal is a strategic investment in one of the main features that makes Cardano unique. - Yes65.9K ₳No rationale
- Yes63.1K ₳Rationale
I support this proposal because it aligns with what I believe Cardano must become to achieve the 2030 vision: not only secure in theory, but usable, measurable, and accessible in practice.
As a voting member of the Cardano Product Committee, KPI measurability is very important to me. I want to see treasury funding assessed not only by whether the work sounds valuable, but by whether it clearly advances the outcomes that matter most: stronger developer adoption, safer applications, more resilient infrastructure, and measurable progress toward real-world use.
This proposal is strong because it sits directly at the intersection of Cardano’s high-assurance identity and developer experience. Blaster, DApp-level formal verification, language integrations, a VS Code extension, a Common Vulnerability Library, and a container-based developer environment all point toward the same outcome: making Cardano’s security advantage easier for builders to actually use. The proposal’s own roadmap includes these deliverables across formal verification and CBDE workstreams.
This also connects with my broader thesis: Cardano needs convenience without dependency. Treasury funding should move the ecosystem from service dependency toward ecosystem capacity. In this case, the strongest argument for support is that the proposal can turn high-assurance tooling into shared public infrastructure used across multiple teams, languages, and developer communities — not just a private capability held by specialists.
I also see this through a practical education and talent-pipeline lens. Through judging 70+ senior student projects at FIU’s Capstone Senior Showcase, and through work alongside the now extinct IO Education team to help develop FIU’s blockchain awareness and curriculum for undergraduate and graduate courses, I have seen how important developer onboarding really is. Students and emerging builders need tools that reduce unnecessary setup friction while still teaching strong engineering discipline. If Cardano wants more builders to move from learning into industry-ready contribution, we need environments and workflows that are easier to start with, easier to trust, and easier to measure.
That is why I see value in this proposal — but my support depends on disciplined execution. The proposal should be judged by concrete evidence: working open-source deliverables, successful language integrations, usable documentation, adoption by real developers, clear milestone acceptance criteria, and transparent reporting. The KPI claims around TVL, MAU, transactions, and protocol revenue should be treated as indirect outcomes, not automatic results. The direct measurable outcomes should be developer usage, verification workflows completed, integrations shipped, and real DApps using the tooling.
For me, this is a YES because it funds ecosystem capacity in an area where Cardano should lead: secure, high-assurance application development. But the vote should come with a clear expectation: deliver the tooling, prove usage, measure adoption, and make the benefits accessible beyond IO and formal methods experts.
- Yes63.1K ₳No rationale
- Yes59.8K ₳No rationale
- Yes56.4K ₳Rationale
I shall continue to vote in favor of the Input Output Global (iOG formerly known as iOHK) proposals due to the fact that iOG has continuously year in and year out built, upgraded, innovated, and further strengthened the ecosystem through various market upheavals, negative press, and technological shifts. Through continuous efforts this cadre of developers, educators, various business persons, scientists, and experts in their fields have proven more than capable of the continued maintenance and innovation necessary to further the Cardano blackchain. I find value in all proposals from iOG until a suitable development group or lab can prove not only innovative, but evolutionary for the technology in which we all utilize and enjoy. The blockchain has survived based off of the creators of the protocol, we must continue the path set forth until we have a suitable substitute that can create viable upgrades and are capable of pushing the community and the blockchain into a realm of technological dominance I vote Yes for this proposal.
LourdeOuroborus Imperator Aeternalis - Yes55.1K ₳No rationale
- Yes51.8K ₳No rationale
- Yes50K ₳No rationale
- No48K ₳No rationale
- Abstain45.3K ₳No rationale
- Yes39.8K ₳No rationale
- Yes32K ₳No rationale
- Yes29.3K ₳No rationale
- Yes28.8K ₳No rationale
- No19.4K ₳No rationale
- Yes15.7K ₳No rationale
- YesRevoted15.3K ₳History
Earlier votes
Yes4mo agoSuperseded
- Yes14.8K ₳Rationale
I believe that io has cardano's best interest at heart.
- Yes9K ₳No rationale
- No6.8K ₳No rationale
- Yes4.1K ₳No rationale
- Yes3.6K ₳No rationale
- YesRevoted2.4K ₳History
Earlier votes
Yes3mo agoSuperseded
- Yes1.7K ₳No rationale
- YesRevoted1.2K ₳History
Earlier votes
Yes3mo agoSuperseded
- Yes999.7 ₳No rationale
- Yes688.8 ₳No rationale
- Yes684.6 ₳No rationale
- Yes84.1 ₳No rationale
- Yes10.8 ₳No rationale
- Yes0 ₳No rationale
- Yes0 ₳No rationale
- Yes0 ₳No rationale