IO: Cardano High Assurance Technical Collaboration

236 DReps voted · 75 with a rationale

Open a row to read the rationale.

• Yoroi W₳llet

  Yes 592.3M ₳ Rationale

  Summary

  Yoroi DRep votes YES for IO: Cardano High Assurance Technical Collaboration, as an investment in the formal verification infrastructure and developer tooling that underpins Cardano’s credibility as a platform for serious, high-value applications.

  Rationale

  Automated formal verification at ecosystem scale

  Blaster’s 2025/26 cycle proved production-scale formal verification is feasible. This proposal extends that to full DApp-level verification, adds language integrations across Aiken, Pebble, Scalus, and Futura, and delivers it with a VS Code extension and Common Vulnerability Library, making formal verification a practical default rather than an expert-only option.

  Distributed delivery and maintenance

  The consortium model across six ecosystem organisations is the right structure for public infrastructure of this nature. It prevents the verification layer from depending on a single team’s continued funding and creates a self-reinforcing maintenance structure.

  Onboarding friction is a real cost

  A 60 to 70% attrition rate during Nix-based environment setup is not an acceptable baseline for a platform competing for developer mindshare. CBDE converting that to a single command has a direct effect on the number of active Plinth developers in the ecosystem.

  Conclusion

  Based on the rationales in the above, Yoroi votes YES. High assurance tooling and accessible developer environments are not peripheral concerns. They are what translates Cardano’s research reputation into real adoption among the developers and institutions that value correctness above all else.

• YUTA

  Yes 428.5M ₳ Rationale

  I am voting YES on "IO: Cardano Upgrades," "IO: Cardano High Assurance Technical Collaboration," and "IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability."

  Cardano Upgrades: I believe that "Account Address Enhancement" and "Babel Fees" are ultimately necessary for the Cardano ecosystem. These will enable progress toward micropayments (and the resulting strengthened sustainability of DApps and wallets), various features that are convenient under an account model, payment of transaction fees in tokens other than ADA (and—though this is outside the scope of this proposal—ultimately the removal of minimum UTXO ADA in native asset transactions). As for "Cardano Multi-Asset Treasury," I think it's likely not necessary right now, but in the future, when ADA's price improves, we may want to convert the treasury's ADA back into stablecoins. Preparing now so that this can be executed if and when we want to may be a good thing, since no one knows when prices will move.

  Cardano High Assurance Technical Collaboration: Various AI-powered hacks have been occurring across different ecosystems, with many tokens being stolen and sold by hackers. This tool can strengthen security, which is one of Cardano's strengths. If we can use 13,078,578 ADA to reduce the likelihood of hacks exceeding 13,078,578 ADA in value, this potentially makes sense.

  Enhancing Plutus: Improving the efficiency of Cardano's smart contract functionality, strengthening security features, and enhancing the developer experience are all necessary pieces.

  ーーー

  私は「IO: Cardano Upgrades」「IO: Cardano High Assurance Technical Collaboration」「IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability」にYESを投票します。

  Cardano Upgrades：
  私は「Account Address Enhancement」と「Babel Fees」は最終的にCardanoのエコシステムに必要だと考えています。これにより少額決済（とそれによるDAppsやウォレットの持続可能性強化）やアカウントモデルによれば便利である様々な機能、ADA以外でのトランザクションフィーの支払い、（そしてこれはこの提案書の範疇ではないですが、そして最終的にはネイティブアセットTxにおける最小UTXO ADAの削除）へ進むことができます。私は「Cardano Multi-Asset Treasury」に関しては今必要ではない可能性が高いと思っていますが、将来的にADAの価格が改善した際に、トレジャリーのADAをステーブルコインに返還しておきたいと私たちは思う可能性があります。そう思った場合にそれが実行できるように準備をしておくことは良いことかもしれません。価格はいつ変動するか誰にもわからないからです。

  Cardano High Assurance Technical Collaboration：
  AIを活用したさまざまなハッキングが種々のエコシステムで発生し、多くのトークンがハッカーに盗まれ、売られています。このツールにより、Cardanoの強みの１つのセキュリティを強化することができます。13,078,578ADAを使用して、13,078,578ADA以上のハッキングの可能性を下げることができるのであれば、これは理にかなっている可能性があります。

  Enhancing Plutus：
  Cardanoのスマートコントラクト機能の効率性の向上、セキュリティ機能の強化、開発者体験の強化はいずれも必要なピースです。

• Blockdaemon

  Yes 328.3M ₳ No rationale
• EMURGO

  Yes 297.4M ₳ Rationale

  Summary

  EMURGO as a DRep votes YES on the treasury withdrawal titled “IO: Cardano High Assurance Technical Collaboration”, with rationale outlined below.

  Rationale

  This proposal funds the infrastructure that makes Cardano’s positioning as a high-assurance platform credible at the tooling level. Blaster has already proven correctness properties for production DApps, including Djed and USDCx. This proposal extends it to full DApp-level verification, integrates it across four smart contract languages, and delivers it as shared public infrastructure accessible to the entire developer community.
  EMURGO is particularly supportive of the consortium delivery model, with Lantr, Harmonic Labs, SAIB, Midgard Labs, TxPipe, and No.Witness Labs each contributing defined work packages.

  This distributes delivery and long-term maintenance across the ecosystem, reducing dependency on any single team’s future funding. The containerised Developer Environment, converting a multi-day Nix setup into a single-command initialisation, further removes a measurable barrier to developer onboarding. For these reasons, EMURGO votes YES.

• CryptoCrow

  Yes 240.8M ₳ No rationale
• Eternl DRep Committee

  Abstain 221.8M ₳ Rationale

  Overview of EDC vote on IO + Tweag proposals:

  ❌ IO: Developer Experience Initiative
  ✅ IO: Cardano Upgrades
  ✅ IO: Consensus Initiative
  ✅ IO & Ensurable Systems: Cardano Maintenance Initiative
  ❌ IO & Midgard Labs: L2 Scalability Initiative
  ➖ IO: Cardano High Assurance Technical Collaboration
  ✅ IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability
  ❌ Blockfrost: Maintenance and Next Generation Indexing
  ❌ Pogun: Capital Without Compromise
  ❌ Tweag Core Cardano Infrastructure: Treasury Withdrawal 2026–2028
  ✅ IO: Cardano Vision 2026: Human Centred, Scalable, Post Quantum Secure - IO Research

  Combined:

  ✅ YES: 147.7m ADA / 35.5m USD
  ❌ NO: 74.0m ADA / 17.7m USD
  ➖ ABSTAIN: 13.1m ADA / 3.1m USD

  All proposed initiatives sound like nice-to-haves for Cardano; some are essential for Cardano's momentum. The asks on almost all of the proposals are too high. That's why we had to triage and prioritize the essentials over the nice-to-haves, allow for a remainder on the NCL, and leave room for other vendors to enter the race for this year's budget.

  We want to make it clear that a NO does not mean we are against the proposed tech. Quite the opposite, for example we'd love to look into Midgard and Pogun for Eternl. We also appreciate the work Blockfrost is doing, trying to replace itself with decentralized tech.

  But we need to leave some part of the NCL for other vendors and initiatives.

• Sebastien Guillemot セバ

  Yes 174.4M ₳ Rationale

  I've looked through the Blaster project and I think it represents a very solid bold bet that makes strategic sense to do now. It helps strengthen the security of projects on the chain at a time where AI makes both formal verification and attacks on insecure code easier. It comes at a time where I feel UPLC is fairly stable, and so it makes sense to focusing on locking down a solid basis in parallel to more ambitious next-gen efforts like Starstream.
  The team has done a great job on the existing work, and the fact they've been able to concretely apply this to real production contracts gives me the confidence on the application of Blaster in the future. For the cost of this project, it quite literally only needs to save Cardano from a single hack to pay off, and with more funds being planned to be locked in contracts than ever (with efforts from Midnight, other partnerchains, pentad projects, etc.) this comes at the right time to give us the safety to deploy capital for these upcoming big bets.

• Everstake

  Yes 160.5M ₳ No rationale
• Cardano Foundation

  Yes 135.1M ₳ Rationale

  This document includes the Cardano Foundation’s voting decisions and individual voting rationales for nine Treasury Withdrawal governance actions submitted by Input Output Global.

  A PDF version of this rationale is also made available.

  We have decided to create a unified document to record our votes as many of the initiatives are connected.

  We invite the proposers and anyone else from the Cardano Community to carefully review our individual rationales below per proposal, as well as the following table.

  Governance Action Title	CF DRep Vote
  97. IO - Developer Experience Initiative	NO
  98. IO - Cardano Upgrades	YES
  99. IO - Consensus Initiative	YES
  100. IO & Ensurable Systems - Cardano Maintenance Initiative	ABSTAIN
  101. IO & Midgard Labs - L2 Scalability Initiative	ABSTAIN
  102. IO - Cardano High Assurance Technical Collaboration	YES
  103. IO & VacuumLabs - Enhancing Plutus - Performance, Correctness, and Usability	NO
  104. Blockfrost - Maintenance and Next Generation Indexing	NO
  105. Pogun - Capital Without Compromise	YES

  Individual Rationales

  The following section contains all nine individual voting rationales for the above-mentioned proposals.

  97. IO - Developer Experience Initiative

  Summary

  The Cardano Foundation votes NO. We are eager to collaborate on DevX, but this proposal is expensive, lacks financial granularity, and risks duplicating ecosystem efforts. We encourage returning with a leaner, more detailed, and coordinated resubmission addressing the points as recommended below.

  Rationale Statement

  We recognize that developer onboarding is a critical vertical, and we appreciate the proposers targeting legitimate ecosystem pain points. While we fully support the overarching goals, we cannot approve this treasury withdrawal in its current form due to the following structural and financial concerns:

  1. Costs Lacking Granularity: The request for approximately 900k USD is exceptionally high for a 6-month timeframe. The budget lacks a meaningful Full-Time Equivalent (FTE) breakdown, allocating 81% to a broadly categorized "Development & Engineering" bucket. This makes it difficult to distinguish between community bounties, hackathon prizes, and administrative overhead, hindering our ability to evaluate financial proportionality.Creating CLI tooling, cleaning documentation, and building contract templates can be achieved in a cost-effective way which does not require a budget of this size.
  2. Overlap with Active CF and Intersect Initiatives: The proposal intends to restructure the "Developer HUB" using the Developer Portal as its primary entry point. The Developer Portal is already actively maintained, funded, and strategized by the Cardano Foundation alongside Intersect committees. While we are highly receptive to ecosystem contributions, requesting nearly 900k USD to duplicate or restructure ongoing work is inefficient. We would welcome collaboration on this workstream to improve cost efficiency.
  3. Severe Execution Risk: The proposal requests funding for only six months. The proposer indicates that the engineering team for these workstreams has not yet been established and will be hired using the funds released from this withdrawal. Setting up a new team and familiarizing them with the necessary ecosystem intricacies will conservatively consume a significant portion of this short timeframe, jeopardizing the delivery schedule. A future proposal would be significantly strengthened by establishing an upfront execution structure. Clearly identifying, aligning, and sharing ownership with ecosystem partners from the outset ensures precise accountability for all deliverables.
  4. Lack of Long-Term Ownership and Maintenance: There is no clear transition strategy for the resulting products (such as cardano-init or the contracts library) after the initial six-month funding period. The ecosystem requires continuous, ongoing feedback and maintenance for developer tools, rather than a highly expensive, short-term sprint that risks leaving behind abandoned infrastructure if subsequent funding is not secured.
  5. Open Source Fragmentation: While cardano-init is explicitly designed as an aggregation layer to unify and elevate existing ecosystem tools rather than replace them, its long-term value hinges heavily on sustained community buy-in. The proposal’s strategy for allocating bounties and incentives to existing tool maintainers is a strong step toward coordination. However, the primary risk shifts from community fragmentation to the execution of integrations: we must ensure that external toolmakers actively maintain these integrations over time so the aggregator remains a reliable, up-to-date entry point for new developers.

  Conclusion

  The Cardano Foundation votes NO. While the ambition to improve Cardano's developer experience is valued, this proposal's steep cost, execution risks, and overlapping scope prevent us from approving it in its current form. To secure approval, a resubmission must be leaner, more cost-effective and provide a granular FTE budget breakdown for financial transparency. It should also integrate with active Cardano Foundation and Intersect initiatives to avoid duplicating ongoing work, establish an execution structure with a pre-identified team to ensure delivery within the tight six-month window, and outline a strategy for long-term maintenance and community buy-in.

  98. IO - Cardano Upgrades

  Summary

  The Cardano Foundation votes YES. CIP-159, CPS-23, and Native Babel Fees have potential to improve L2 reserves, protect against volatility, and improve onboarding. Despite certain budget and execution concerns, we view the 13.1M ada ask as an acceptable investment.

  Rationale Statement

  We recognize the impact these three platform-level capabilities will have on Cardano’s economic models and ecosystem growth. We are voting YES based on the following technical and strategic assessments:

  1. Critical Infrastructure and Economic Resilience: The CIP-159 (Account Address Enhancements) upgrade bridges the gap between UTXO and Account models. By solving the minUTxO constraints, it enables micro-fee collection, cheaper DeFi batcher operations, and introduces new smart contract paradigms more familiar to EVM developers. Furthermore, it is a prerequisite for seamless L2 reserve management. CPS-23 (Multi-Asset Treasury) enables the Cardano Treasury to hold stablecoins or other native assets, which is a next step for long-term sustainability. It could protect the ecosystem's funding runway from ADA price volatility and introduce the potential for diverse treasury holdings.
  2. Native Babel Fees and Onboarding: While non-native (smart contract-based) Babel fees currently exist within the ecosystem, they have struggled to gain significant traction. Allowing users to interact with Cardano DApps using stablecoins or bridged assets without first acquiring ADA will hopefully be a driver for mainstream institutional and retail adoption.

  3. Feedback for Ongoing Alignment: While we support funding this initiative, there are elements of this proposal which raised concerns and we wish to offer feedback.

  Implementing CIP-159 fundamentally alters Cardano's accounting model. With alternative nodes like Amaru and Dingo actively in development, introducing such massive ledger changes requires careful coordination. Making frequent, significant modifications directly onto the Layer 1 core ledger introduces substantial maintenance fatigue for open-source builders, which can be lessened with coordination. We urge IO to collaborate to establish a clear framework for alignment with other node implementation and material downstream tooling teams to prevent consensus fragmentation.

  Workstream 2 allocates roughly $565,000 USD primarily to design and draft the Multi-Asset Treasury CIP. For a design-phase deliverable, this is a premium investment. We expect this effort to feature rigorous, high-quality deliverables, contributions to improvements to the overall CIP process and extensive community consultation to reflect the amount.

  Workstream 3 includes integration with the Lace wallet. Given the use of treasury funds, we expect the IO team to ensure that the underlying infrastructure for Native Babel Fees is open and easily accessible for all ecosystem wallets, Tx builders (e.g., Mesh, Lucid Evolution), and indexers, rather than focusing support solely on its own products.

  Although these concerns are valid, we appreciate the dialogue with IOG on this proposal which contributed to this voting decision.

  Conclusion

  The Cardano Foundation votes YES. The combination of Account Enhancements, a Multi-Asset Treasury, and Native Babel Fees represents a step forward for Cardano's scalability, developer experience, and economic sustainability.

  99. IO - Consensus Initiative

  Summary

  The Cardano Foundation votes YES. Leios is important for scaling Cardano and long-term competitiveness. Despite concerns over budget opacity and prior funding overlaps, delaying this upgrade risks ecosystem stagnation. We approve to ensure development continuity.

  Rationale Statement

  We recognize the impact that the Consensus Initiative (Leios) will have on the network’s capacity. We are voting YES based on the following technical and strategic assessments:

  1. Essential Base Layer Scaling: Scaling through Leios is fundamentally positive and provides Cardano with a massive upgrade. To ensure Cardano remains competitive with newer Layer 1 blockchains in terms of throughput, upgrading the base protocol is non-negotiable. This prevents the network from adopting unsustainable design patterns, such as forcing all high-volume activity to Layer 2 solutions.
  2. Core Infrastructure Investment: This proposal is a direct investment in the core protocol infrastructure. The Leios research phase has produced solid, academic-level work fully in the spirit of a peer-reviewed blockchain.
  3. Development Continuity: Leios development requires highly specialized knowledge. Voting NO at this critical juncture would risk halting momentum, meaning expert engineering teams would need to be replaced or re-assembled at a later date. Approving this proposal ensures the unbroken continuation of the roadmap toward the Dijkstra era.

  Conclusion

  The Cardano Foundation votes YES. We recognize that Leios is a credible path available to meet Cardano's 2030 scaling ambitions. While we have significant concerns regarding the insufficiently detailed, escalating budget, the risk of derailing base-layer scaling is too significant.

  100. IO & Ensurable Systems - Cardano Maintenance Initiative

  Summary

  The Cardano Foundation votes ABSTAIN. We appreciate the dialogue with IOG on this proposal, which contributed to our voting decision. While continuous maintenance is important for long-term network stability, this 62.1M ada proposal presents fiscal uncertainty and the scope appears to duplicate funding of other concurrent initiatives.

  Rationale Statement

  While the critical importance of keeping the network operating securely is undisputed, our evaluation reflects several material concerns regarding the current formulation of the proposal:

  1. Lack of Budget Detail/Potential Duplications: This proposal bundles nine maintenance workstreams into a single budget, grouping 74% (46M ada) of the funds into a broad "Development" category, which, without a granular Full-Time Equivalent (FTE) headcount breakdown, limits the capacity to verify cost efficiency. Additionally, given that the same development teams contribute across multiple initiatives, there appears to be a funding overlap with resources already requested in the Upgrades, Plutus, Consensus, and Developer Experience proposals. Providing a more detailed budget breakdown would help the community in conducting a clear cost-benefit analysis and ensure there is no duplication of funding.
  2. Lack of Quantifiable Deliverables: The proposal functions structurally as an open-ended funding commitment lacking defined technical boundaries, presenting a deficit of tangible deliverables, milestones, or open-source repository evidence mapping out the work. Without clear engineering baselines, it acts as an unquantifiable blanket retainer that challenges our ability to properly assess the proposal.
  3. Substantial Budget Inflation: The requested amount of 62.1M ada (approximately 14.9M USD) represents a high allocation of treasury resources. Industry baselines indicate that these costs are significantly inflated relative to the actual operational overhead required for equivalent DevOps and core maintenance tasks.
  4. Structural Preference for Targeted Initiatives: The Cardano Foundation maintains a clear structural preference for a modular funding framework wherever possible. Funding generalized blanket proposals introduces fiscal uncertainty, whereas smaller, targeted sub-proposals (such as specific consensus, developer experience, or scaling layer initiatives) feature transparent line-item budgets and clearly defined milestones that allow for rigorous milestone-based verification.
  5. Node Diversity Risks: To support a healthy multi-client ecosystem, overarching services such as global network monitoring and core documentation (e.g., the Cardano Blueprint) should be gradually decoupled from node-specific maintenance to ensure a completely product-agnostic and inclusive infrastructure landscape.

  Conclusion

  The Cardano Foundation votes ABSTAIN. We appreciate the critical nature of network maintenance and the expertise of the proposing teams. However, we require greater financial transparency, and a more node-agnostic approach to ecosystem tooling in order to properly assess this proposal. If this proposal does not reach the required approval threshold, we ask the proposers to refine and resubmit. A resubmission would greatly benefit from a decoupled structure, detailed FTE allocations, and an independent oversight mechanism to ensure verifiable and neutral delivery.

  101. IO & Midgard Labs - L2 Scalability Initiative

  Summary

  The Cardano Foundation votes ABSTAIN. While Layer 2 scaling is important for enterprise DApps, the proposal's lack of budget granularity, contested IP, and unresolved 2025 milestones introduce uncertainty. While we do not oppose this proposal, we urge a refined resubmission if it does not pass.

  Rationale Statement

  We support the technological objectives and the necessity of Layer 2 scaling, however we require further clarity regarding the following uncertainties before we are able to support:

  1. Unclear Scope and Structural Bundling: The proposal bundles two Layer 2 technologies at different stages of their respective product lifecycles into a single governance action. Furthermore, the financial distribution is skewed; despite being a titular focus of the initiative, the Midgard workstream receives only 9% of the allocated funding, while Hydra consumes approximately 73%.
  2. Milestone Accountability and Prior Deliverables: Midgard's 2025 funded milestones under contract EC-0001-25 were previously reported as past due and paused. While new evidence was submitted on May 19 to claim milestones 2–5, these submissions remain pending final verification. Committing additional treasury resources without a fully finalized reconciliation of past deliverables introduces significant fiscal uncertainty.
  3. Budget Granularity and Potential Overlaps: The 10.4M ada request lacks a granular breakdown. The technical scope for Workstream 2 (Hydra) closely mirrors the team's existing public roadmap and open pull requests, making it difficult to isolate net-new work from previously funded core engineering efforts. Additionally, the 1.8M ada requested for a bespoke Data Availability (DA) prototype does not sufficiently clarify why existing modular alternatives are unsuitable.
  4. Technical, IP, and Organizational Risks: The proposal contains contradictory timelines regarding the Midgard mainnet launch (end of 2026 versus Q1 2027). Subject Matter Experts (SMEs) also noted unresolved authorship and payment disputes (e.g., PR #434) that introduce contested-IP risks. Finally, the legal distinction and relationship between "Midgard Labs" and Anastasia Labs require clarification to ensure accountability.
  5. Unsubstantiated Metrics and Commercial Dependencies: Performance claims such as "10,000+ TPS" are presented without concrete benchmarking data or baseline metrics. Furthermore, the proposal relies heavily on specific commercial partners (like Delta DeFi and Masumi) continuing to build, without providing contingency plans. Ideally, commercial entities utilizing the stack for enterprise applications should contribute to the hardening of the infrastructure they rely upon.

  Conclusion

  The Cardano Foundation votes ABSTAIN. We appreciate the dialogue with IOG on this proposal which contributed to our voting decision. We value the technical ambition of this initiative and respect the engineering teams involved, but we cannot support this proposal in its current state without proper budget breakdowns, clarity on IP, and clear accountability for past milestones. If this proposal does not reach the required approval threshold, we ask the proposers to refine and resubmit their initiative.

  102. IO - Cardano High Assurance Technical Collaboration

  Summary

  The Cardano Foundation votes YES. Automating formal verification is a strategic public good that reinforces network security. Despite significant concerns regarding budget opacity and adoption risks, the ecosystem benefits outweigh the reservations.

  Rationale Statement

  We support this proposal because it aligns with Cardano's core value proposition of security, correctness, and determinism. Our YES vote is grounded in the following primary drivers:

  1. Strategic Digital Trust Infrastructure: Cardano’s underlying smart contract model, based on Lambda calculus and determinism, is uniquely positioned for formal mathematical verification. Recent high-profile vulnerabilities in EVM-based DeFi protocols, such as the ~$300M Kelp DAO exploit, highlight that verifiable security is a strict prerequisite for institutional adoption. This enables a shift away from high-risk environments toward highly secure, institutional-grade DeFi applications.
  2. Universal Ecosystem Support via UPLC: The proposed automated verification tool, Blaster, operates directly on Untyped Plutus Core (UPLC). This architectural choice is strategic, as it avoids siloed development and simultaneously supports developers across the ecosystem, regardless of whether they write in Aiken, Plutus, or other high-level smart contract languages.
  3. Lowering the Barrier to Entry: Historically, formal verification has been restricted to specialized experts. By providing a Lean4-based verification enabler, integrating it directly into native toolchains (e.g., VS Code), and offering extended "one-click" containerized developer environments, this initiative significantly democratizes access to production-ready, secure smart contract development.
  4. AI-Agentic Workflow Readiness: As software engineering transitions toward AI-assisted development, the emphasis on robust Command Line Interfaces (CLIs) within this proposal provides a strong, secure foundation for future integration with autonomous AI agents, ensuring Cardano's toolchain remains forward-looking.
  5. Reusable and Auditable Components: The initiative focuses on d
• CardanoYoda (MANDA Pool)

  Yes 93.3M ₳ Rationale

  As a DRep, I decided to vote YES for the proposal: IO: Cardano High Assurance Technical Collaboration

  My rationale:

  I support this proposal because it strengthens one of Cardano's most important long-term differentiators: security and formal correctness.

  Many blockchain ecosystems prioritize speed of development but often pay the price later through exploits, protocol failures, and loss of user trust. The industry has repeatedly seen hacks worth hundreds of millions of dollars across bridges, lending protocols, exchanges, and DeFi applications. Audits alone are often insufficient because they review code but do not mathematically prove correctness.

  This proposal pushes Cardano further towards a model where security becomes a real competitive advantage rather than just a marketing narrative.

  The first workstream expands Blaster, IO's automated formal verification tool. Blaster has already been used to verify individual smart contracts used in production applications such as Djed and USDCx, but full DApp-level verification currently requires significant manual effort.

  This proposal aims to automate verification across multi-contract systems and multi-transaction flows, which is significantly more valuable because many major exploits occur at the protocol level through flawed interactions between contracts, state transitions, and external assumptions rather than within a single script alone.

  The proposal also introduces a Common Vulnerability Library, which could make formal verification more accessible by giving developers reusable templates for common attack vectors and security checks. This could significantly improve baseline security standards for smaller teams that cannot afford repeated audits or large internal security teams. It should not be viewed as a replacement for audits, but it can help teams identify vulnerabilities earlier and reduce reliance on costly manual reviews.

  Another valuable component is the equivalence checking tool, which allows developers to optimize UPLC code while mathematically proving that functionality remains unchanged. This can improve efficiency without introducing unnecessary security risks.

  The proposal also expands support across multiple smart contract languages, including Aiken, Scalus, Pebble, and Futura, which is important for ecosystem decentralization. Cardano should not become dependent on a single development stack.

  The second workstream focuses on a Container-Based Developer Environment (CBDE) that simplifies onboarding by packaging the full high-assurance tooling stack into a much easier setup process. This addresses a real pain point for developers.

  This proposal is also complementary to IO & VacuumLabs: Enhancing Plutus – Performance, Correctness, and Usability, which focuses more on protocol-layer improvements such as Plutus capabilities, formal specifications, and core tooling.

  I also appreciate that this proposal includes collaboration with multiple ecosystem teams rather than concentrating all work inside IO. The involvement of TxPipe, Midgard Labs, Harmonic Labs, Lantr, SAIB, and No.Witness Labs is a positive signal and helps distribute technical expertise across the ecosystem.

  That said, the proposal still lacks sufficient financial transparency. It explains technical deliverables well, but it does not show how much funding goes to each participating team. If ecosystem collaboration is presented as a major strength, DReps should be able to see how funds are distributed across organizations, how many engineers are involved, and what each team is being compensated for. This is particularly important when some ecosystem teams may also pursue separate funding through other channels.

  Finally, some of the proposal's adoption projections appear overly optimistic. Better tooling can improve developer experience, but developer growth also depends on broader ecosystem demand, liquidity, users, and real business opportunities.

  Despite these concerns, this proposal strengthens Cardano's long-term security model and reinforces an area where Cardano can genuinely differentiate itself from competing ecosystems. For these reasons, I support it.

  If you'd like to support my work, consider delegating to the MANDA pool and backing me as a DRep. Your support is the only way I can get time for governance.

  MANDA Pool ID:
  pool1c3fjkls7d2aujud8y5xy5e0azu0ueatwn34u7jy3ql85ze3xya8

  My DRep ID:
  drep1y2m0g4r66pyaw3p7u454wc0p4f0ygm8ueaev0mgd3tvwm7sskqwqp

• JAZZ

  Yes 92.1M ₳ No rationale
• SIPO

  Yes 89.8M ₳ Rationale

  SIPO DRep votes YES on IO: Cardano High Assurance Technical Collaboration.

  Governance Action ID: gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3q2yd5rxu
  DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
  Date: 2026-05-09

  SIPO supports this proposal as the most advanced stewardship-distribution example in this round. Seven organizations — Input Output, Lantr (Scalus), Harmonic Labs (Pebble), SAIB (Futura), Midgard Labs (Aiken), TxPipe, and No.Witness Labs — share defined work packages on a single coherent toolchain, extending SIPO's node-diversity doctrine from consensus-layer alt-clients into the smart-contract language and formal-verification layer. Two workstreams — Blaster (formal verification at DApp scale) and CBDE (Container-Based Developer Environment) — together make formal verification accessible to every Cardano developer regardless of formal-methods background.

  Why SIPO votes YES

  1. Seven-organization collaboration is the most advanced stewardship-distribution model in this round. Each partner contributes a defined component: Lantr integrates Blaster with Scalus, Harmonic Labs with Pebble, SAIB with Futura, IO with Aiken (also Midgard Labs participates on Aiken integration), TxPipe delivers proof reconstruction, and No.Witness Labs builds the Common Vulnerability Library. This is not "IO with consultants" — it is a consortium of Cardano specialist teams sharing maintenance and delivery responsibility on shared public infrastructure. SIPO has consistently supported the stewardship-distribution pattern (HLabs Pebble + Gerolamo, IO Cardano Upgrades co-venture with Ensurable, Enhancing Plutus co-venture with VacuumLabs); this proposal extends that pattern further than any other in the round.

  2. Blaster operates at the UPLC level, supporting all Cardano smart-contract languages equally. Untyped Plutus Core is the common compilation target of Aiken, Pebble, Scalus, Futura, and Plinth. By building automated formal verification at the UPLC level, the investment supports the entire smart-contract language ecosystem simultaneously, rather than privileging one language over another. This directly extends SIPO's node-diversity doctrine — diversity in alt-clients (Amaru, Dingo) is matched by diversity in smart-contract languages, and this proposal funds the verification infrastructure that ensures all of those languages produce correct compiled output.

  3. Production track record: Blaster has already proved correctness properties on Djed and USDCx. The 2025/26 cycle demonstrated that automated formal verification of Cardano smart contracts is feasible at production scale on real DeFi protocols. This is not a research bet — it is the productization of an already-proven tool. Extending Blaster from single-script to multi-script DApp-level verification, adding language-native VS Code integrations for four languages, and delivering a Common Vulnerability Library with templates for major protocol categories (DEXs, bridges, lending, NFT minting) translates a working tool into ecosystem infrastructure.

  4. CBDE addresses a measured developer-onboarding bottleneck. The proposal documents 60-70% developer attrition during multi-day Nix setup. CBDE compresses environment configuration from days to a 60-second initialization with a single command, targeting attrition reduction to under 20% and a 3-5x increase in active Plinth developers within 12 months. This connects directly to the Developer Experience Initiative (also under SIPO YES vote in this round) — cardano-init is designed as the integration point for the High Assurance toolchain plugin architecture.

  Governance and oversight structure is identical to the standard SIPO has approved on Amaru, Dingo, HLabs Pebble + Gerolamo, DeFi Liquidity Budget, and Orion Fund (Sundae Labs treasury-contracts framework, Intersect administration, 5-entity Oversight Committee, multi-signature disbursement, refund clause). 86% Development allocation. Net Change Limit compliant.

  Expectations (YES with binding operational commitments)

  • Seven-partner milestone transparency: With seven organizations sharing delivery, the risk of milestone slippage from any single partner is real. SIPO expects each partner's component to be tracked publicly, with clear visibility into which partner owns which deliverable and where any partner-side delay is impacting downstream work.

  • Common Vulnerability Library external audit firm participation: The library's credibility for institutional adoption depends on auditor participation. SIPO expects at least two external Cardano audit firms (in addition to the named partners) to be confirmed as contributors by Q2 2027.

  • DApp Proof Framework Q2 2027 demo and TWAG 1 examples: The DApp-level proof framework is the most engineering-intensive deliverable. SIPO expects the Q2 2027 demo to include at least three TWAG 1 ready-to-audit examples with full proofs visible to the community, not just internal demos.

  • Plinth developer adoption baseline disclosure: The "3-5x increase in active Plinth developers within 12 months" claim requires a baseline. SIPO expects the baseline (current active Plinth dev count, measurement methodology) published before CBDE V1.0 release in Q2 2027.

  • Coordination with Developer Experience Initiative: cardano-init's plugin architecture is referenced as the entry point for the High Assurance toolchain. SIPO expects coordination so the plugin interface is designed in time and CBDE/Blaster integrate cleanly.

  Closing

  This proposal extends SIPO's node-diversity doctrine from consensus alt-clients into the smart-contract language and formal-verification layer, with seven organizations sharing stewardship of a single coherent toolchain. Blaster's production track record on Djed and USDCx demonstrates this is productization, not speculation. CBDE addresses a measured 60-70% developer attrition problem with a documented 60-second target. With expectations above treated as binding operational commitments, SIPO DRep votes YES.

  For these reasons, SIPO DRep votes YES.

  ---

  SIPO DRepとして、本提案「IO: Cardano High Assurance Technical Collaboration」に賛成（YES）を投じます。

  Governance Action ID: gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3q2yd5rxu
  DRep: drep1yffld2866p00cyg3ejjdewtvazgah7jjgk0s9m7m5ytmmdq33v3zh
  Date: 2026-05-09

  SIPOは本提案を、本ラウンドにおける最も先進的なstewardship分散の事例として支持します。7つの組織 — Input Output、Lantr（Scalus）、Harmonic Labs（Pebble）、SAIB（Futura）、Midgard Labs（Aiken）、TxPipe、No.Witness Labs — が単一のコヒーレントなツールチェーンに対する明確な作業パッケージを共有し、SIPOのノード多様性ドクトリンを合意層 alt-clients から smart-contract 言語と formal-verification 層へと拡張します。2つのワークストリーム — Blaster（DAppスケールでの formal verification）と CBDE（Container-Based Developer Environment）— が組み合わさることで、formal methods の背景を持たない開発者を含む全ての Cardano 開発者に formal verification を accessible にします。

  SIPOがYESと判断する理由

  1. 7組織協業は本ラウンドで最も先進的なstewardship分散モデル。各パートナーが定義された貢献を行います：LantrがBlasterとScalusを統合、Harmonic LabsがPebbleと、SAIBがFuturaと、IOがAikenと（Midgard LabsもAiken統合に参加）、TxPipeがproof reconstructionを提供、No.Witness LabsがCommon Vulnerability Libraryを構築。これは「IOとコンサルタント」ではなく、Cardano専門チームの consortium が共有公共インフラの maintenance と delivery 責任を分担しています。SIPOはstewardship分散パターン（HLabs Pebble + Gerolamo、Ensurable Systemsとの IO Cardano Upgrades co-venture、VacuumLabsとの Enhancing Plutus co-venture）を一貫支持してきました。本提案はそのパターンを本ラウンドの他のいずれよりも更に拡張しています。

  2. BlasterはUPLCレベルで動作し、全Cardano smart-contract言語を平等に支援。Untyped Plutus Coreは Aiken、Pebble、Scalus、Futura、Plinthの共通コンパイル先です。UPLCレベルで自動formal verificationを構築することで、本投資は smart-contract 言語エコシステム全体を同時に支援し、特定の言語を優遇しません。これはSIPOのノード多様性ドクトリンを直接拡張します — alt-clients（Amaru、Dingo）の多様性が smart-contract 言語の多様性と対応し、本提案はそれら全ての言語が正しいコンパイル出力を生成することを保証する verification インフラに資金提供します。

  3. プロダクション実績：BlasterはDjedとUSDCxで既にcorrectness propertiesを証明済み。2025/26サイクルは、Cardano smart contractsの自動formal verificationが実DeFiプロトコルでプロダクションスケールで実行可能であることを実証しました。これはリサーチbetではなく、既に実証済みツールのプロダクト化です。Blasterを単一スクリプトから multi-script DApp レベル verification に拡張し、4言語の language-native VS Code 統合を追加し、主要プロトコルカテゴリ（DEX、bridge、lending、NFT minting）向けテンプレート付き Common Vulnerability Library を提供することで、動作するツールがエコシステムインフラへと変わります。

  4. CBDEは測定された開発者onboardingボトルネックに対応。本提案は複数日のNixセットアップ中に60-70%の開発者離脱が発生していることを文書化しています。CBDEは環境設定を数日から60秒の単一コマンド初期化に圧縮し、離脱率を20%未満に削減、12ヶ月以内のアクティブPlinth開発者3-5倍増を目標とします。これは本ラウンドで同様にYESを投じるDeveloper Experience Initiativeと直接接続します — cardano-initはHigh Assurance toolchainプラグインアーキテクチャの統合点として設計されています。

  ガバナンス・監視構造はSIPOがAmaru、Dingo、HLabs Pebble + Gerolamo、DeFi Liquidity Budget、Orion Fundで承認した標準と同一です。86% Development配分、Net Change Limit準拠。

  期待事項（YESには拘束力のある運用上のコミットメントを伴う）

  • 7パートナーマイルストーン透明性：7組織がデリバリーを共有することで、いずれかのパートナーからのマイルストーン遅延リスクは実在します。SIPOは各パートナーの貢献が公開追跡され、どのパートナーがどのデリバリーを所有し、パートナー側の遅延が下流作業に影響している箇所が明確に可視化されることを期待します。

  • Common Vulnerability Library外部監査会社の参画：ライブラリの institutional 採用に対する信頼性は監査会社の参画に依存します。SIPOはQ2 2027までに少なくとも2社の外部Cardano監査会社（指名パートナーに加えて）が貢献者として確定することを期待します。

  • DApp Proof Framework Q2 2027 demoとTWAG 1 examples：DAppレベルproof frameworkは最もengineering-intensiveなデリバリーです。SIPOはQ2 2027 demoに少なくとも3つのTWAG 1 ready-to-audit examplesと完全なproofsがコミュニティに可視化されることを期待します — 内部デモではなく。

  • Plinth開発者採用ベースラインの開示：「12ヶ月以内のアクティブPlinth開発者3-5倍増」という主張はベースラインを必要とします。SIPOはCBDE V1.0のQ2 2027リリース前に、ベースライン（現在のアクティブPlinth開発者数、測定方法論）の公開を期待します。

  • Developer Experience Initiativeとの連携：cardano-initのプラグインアーキテクチャはHigh Assurance toolchainのエントリーポイントとして参照されています。SIPOはプラグインインターフェースが時間的に設計され、CBDEとBlasterが clean に統合されるよう連携を期待します。

  結び

  本提案は、SIPOのノード多様性ドクトリンを合意層alt-clientsからsmart-contract言語とformal-verification層に拡張し、7組織が単一のコヒーレントなツールチェーンの stewardship を共有するものです。BlasterのDjedとUSDCxでのプロダクション実績は、これが投機ではなくプロダクト化であることを実証します。CBDEは測定された60-70%開発者離脱問題に文書化された60秒ターゲットで対応します。上記期待事項が拘束力のある運用上のコミットメントとして扱われることを前提として、SIPO DRep は本提案に賛成（YES）を投じます。

  以上の理由により、SIPO DRepとして本提案に賛成（YES）を投じます。

• Army of Spies

  Yes 89.3M ₳ Rationale

  Keeping Cardano from being another part of the Robbery Forest is a goal worth spending some money. I can get behind automated formal verification at this price. Yes to security! It will be even more important in an age of AI generated zero days.

• BTBF_XSP

  Yes 89.2M ₳ Rationale

  Cardano's strongest differentiator is its focus on security and correctness, yet the tools delivering it have been the domain of auditors and formal-methods experts. This proposal extends the automated formal verification tool Blaster to DApp-level verification and opens it to ordinary developers via VS Code integration and a one-command environment. It turns that differentiator into practice and distributes maintenance across multiple teams — so I vote YES.

• Dumpling🥟

  Abstain 77.3M ₳ No rationale
• drep1yg343cyuckg...

  Yes 76.1M ₳ Rationale

  Support high-assurance tooling that proves properties of real contracts and makes serious verification practical for builders.

  A PDF version of this rationale is also made available.

  Support high-assurance tooling that proves properties of real contracts and makes serious verification practical for builders. The strongest case is reusable verification tooling, public documentation, security findings, and contract proofs that create a genuine Cardano advantage in correctness and security.

  The entire design philosophy of Cardano and our execution layer of prioritizing security above all else and making the sacrifices to do so, has struggled in the market for the past five years because the blue chip DeFi protocols on other chains were largely considered untouchable, secure, and reliable with years of proven history.

  So we had to argue abstractly that dApps here are more secure, which doesn’t land well when someone can point to AAVE and see that in its many years of operations, has never been subject to an exploit, or to Uniswap where the same is true.

  With the advent of advanced AI all of that has changed, the cracks are finally showing, bluechip DeFi apps with impeccable historic records are being exploited left and right for millions and millions month after month. Trust is shaking, LPs are leaving left and right.

  It is critical that we take advantage of this narrative and we market this now. We need to strike while the iron is hot, and recent events form a perfect storm for heavily marketing Cardano DeFi and attracting external LPs.

  Blaster is the single most significant market advantage our ecosystem has had since the release of Ouroboros.

• ranket

  Yes 74.7M ₳ Rationale

  there is the practical issue that there is no developer that can fully absorb the risk of ADA price fluctuations. I am aware of concerns regarding the speed of development, etc. However, I believe that this would only be the case if an alternative development group with a proven track record were to propose it. In some cases, it is possible that the new group could negotiate with IO and Charles after the proposal is approved.

• Dave

  Yes 71.3M ₳ Rationale

  I vote YES. Competing blockchains have recently lost billions to smart contract exploits. Democratising formal verification empowers all developers to mathematically immunise our ecosystem against these attacks. This is a vital investment in institutional trust, and I am happy to support it.

  A PDF version of this rationale is also made available.

  I am formally registering a YES vote on the Cardano High Assurance Technical Collaboration. Throughout 2025 and early 2026, the wider Web3 ecosystem has haemorrhaged billions of dollars to smart contract vulnerabilities and bridge exploits across competing blockchains. Cardano’s fundamental value proposition is its high-assurance security, yet this has historically been gatekept by expensive auditing firms and formal methods specialists.

  This proposal elegantly democratises that security. By embedding the Blaster formal verification tool directly into the native languages our builders actually use—such as Aiken, Scalus, Pebble, and Futura—it empowers every developer to mathematically prove their applications are immune to catastrophic exploits prior to deployment. Furthermore, the Container-Based Developer Environment solves a glaring onboarding bottleneck, compressing notoriously complex, multi-day configurations into a seamless, single-click setup so builders can focus on engineering.

  Mathematically safeguarding our ecosystem's Total Value Locked against the exploits currently crippling rival blockchains is an absolute necessity. Distributing the stewardship of this critical tooling across a consortium of ecosystem partners ensures resilience and correctly aligns with our open-source ethos. This initiative is a vital investment in Cardano’s institutional trust and long-term growth, and I am happy to support it.

• Martin Lang

  Yes 70.8M ₳ No rationale
• SASA_nagamaru_ながまる

  Abstain 68M ₳ Rationale

  I strongly support the overall direction of this proposal and the broader “High Assurance” vision it represents. One of Cardano’s greatest competitive advantages is its emphasis on security, correctness, and formal verification, and expanding tools such as Blaster and the formal verification stack could significantly strengthen the quality of the Cardano ecosystem over the long term. In particular, the demonstrated use cases with Djed and USDCx, support for multiple smart contract languages, and efforts to simplify the developer environment are all meaningful contributions.

  At the same time, considering the challenges Cardano currently faces, I believe the prioritization of this proposal requires careful consideration. At the present stage, Cardano appears to face larger challenges around user acquisition, developer experience, liquidity, real-world demand, marketing, and L2 scaling than around the lack of advanced formal verification infrastructure itself. In that context, allocating more than ₳13M toward a relatively research- and high-assurance-focused initiative is difficult for me to fully justify at this time.

  Additionally, while the proposal is technically strong and could meaningfully strengthen Cardano’s long-term differentiation, I believe there may be room for a more phased approach or narrower scope given the current treasury environment and competing priorities across the ecosystem.

  For these reasons, while I support the vision and direction of the proposal, I will abstain at this time due to concerns around prioritization and budget scale.

  本提案が目指している「高保証（High Assurance）」の方向性そのものには強く賛同しています。Cardanoの最大の競争優位の一つは、安全性・正確性・形式的検証可能性にあり、Blasterや形式検証基盤の拡張は、長期的にはCardanoエコシステム全体の品質向上に大きく寄与する可能性があります。特に、DjedやUSDCxなど既存事例への活用実績や、複数のスマートコントラクト言語への対応、開発環境の簡略化などは非常に意義のある取り組みだと感じています。

  一方で、現在のCardanoが直面している課題を考えると、本提案の優先順位については慎重に考える必要があるとも感じています。現状のCardanoは、形式検証不足よりも、ユーザー獲得、開発者体験、流動性、実需、マーケティング、L2スケーリングなど、市場接続に近い領域における課題の方が大きい局面にあると考えています。その中で、₳13Mを超える大規模予算を、比較的研究・高保証寄りの領域へ一括で投入することについては、現時点では判断が難しいと感じました。

  また、本提案は技術的には非常に高度であり、長期的にはCardanoの強みをさらに伸ばす可能性を持つ一方で、現在のトレジャリー状況や他の優先課題とのバランスを考えると、より段階的なアプローチやスコープ調整の余地もあるように感じています。

  そのため、本提案の思想や方向性には賛同しつつも、現在の優先順位および予算規模を踏まえ、今回は棄権とします。

• Hermes Stakepool Germany (HRMS)

  No 65.7M ₳ Rationale

  beneficial but not first priority to spend money on imho

• Peter Bui

  Yes 62.7M ₳ No rationale
• Dori

  Yes 53.8M ₳ Rationale

  I am voting Yes on IO's Cardano High Assurance proposal.

  In a market with repeated hacks, I believe Cardano's core differentiator lies in declarative validation built on the eUTXO model: the structural security advantage of being able to fully verify a transaction's result before it executes. This proposal extends that strength to the DApp level.

  Formal Verification is "the work of mathematically proving that code behaves exactly as intended." It is one of Cardano's core differentiators, but until now it has been accessible only to a small group of developers trained in specialized verification tools.

  The Blaster track brings this capability into a form ordinary developers can use naturally inside the code editor (VS Code) they already work in. Verification scope expands from a single contract to an entire DApp, common vulnerabilities come as pre-built property templates so developers don't need to write verification from scratch, and the equivalence checker preserves prior verification results when code is optimized.

  In short, this converts Cardano's "safety in theory" into "safety used in everyday development." Especially as AI-driven automated exploits proliferate, this is not a developer-convenience improvement but an infrastructure investment that raises the security baseline of the entire ecosystem, and a natural next step in the line of work I supported when voting for the Enhancing Plutus proposal.

  I also note the consortium structure. WS1 distributes work across multiple smart contract language integrations and additional components among external partner organizations. Rather than IOG vertically integrating every language and toolchain, this is a distributed execution structure where specialized organizations own their respective domains, aligned with reducing single-org dependency on IOG and with the decentralization direction of IO's 2030 Vision.

  Over the long run, I think such a structure distributes expertise across organizations, accelerates technical progress, and creates a meaningful opportunity to grow specialized engineers within the Cardano ecosystem.

  That said, partner-level budget allocation, FTE composition, and milestone schedules should be disclosed. Despite the ₳13M scale, the share of responsibility and resource allocation for each partner organization is not specified in the proposal. I do not believe IO's influence should serve as grounds for exempting it from the transparency and accountability standards that apply to every other proposer. Even if this proposal passes, partner-level deliverables and resource allocation should be disclosed in a trackable form during execution.

  The overall direction of this proposal, extending eUTXO's structural security advantages to the level of practicing developers and reducing IOG dependency through a multi-partner distributed execution structure, is essential work for Cardano to prove its differentiated value to the market at the next stage.

  For these reasons, I am voting Yes.

• Goofycrisp

  Yes 51.1M ₳ Rationale

  High assurance and formal methods are part of what makes Cardano distinct. This proposal supports stronger security, correctness, and engineering standards, which are essential for serious long-term adoption. Tools that can help prove smart contracts are safe before deployment are especially valuable in an environment where exploits and AI-assisted vulnerabilities are becoming more common. This reinforces Cardano’s credibility and differentiation.

• Chris-O

  Yes 50.5M ₳ No rationale
• AdaStat

  Abstain 49.8M ₳ Rationale

  I'm going to revisit this proposal a bit later. For now, I'm voting Abstain just in case I don't manage to do that before the deadline.

• hix_coffeepool

  No 49.7M ₳ Rationale

  I am voting No on this proposal. As a DRep, I evaluate all treasury withdrawal governance actions against my published voting framework, with a focus on the healthy development and long-term sustainability of the ecosystem. This proposal does not meet the framework's requirements, and I am voting No on that basis.

• drep1ytjz60rgwhk...

  Yes 42.9M ₳ No rationale
• PoolTool

  No 42.4M ₳ No rationale
• drep1ygm9wxzrrdq...

  No 40M ₳ Rationale

  While I absolutely see the value of this proposal & the community collaborators are strong, I believe this to be more of a "nice to have" than what we currently require for this ecosystem to succeed.

• drep1yffcjs0njfe...

  No 38.1M ₳ No rationale
• Linda - Cryptofly

  Yes 36.8M ₳ No rationale
• MUEN

  Yes 34.4M ₳ No rationale
• Socious

  Yes 34.3M ₳ Rationale

  Socious votes Yes. This 13,103,039 ADA proposal funds three initiatives that each remove a concrete economic constraint. CIP-159 Account Address Enhancement lets wallets collect micro-fees and makes DeFi cheaper for end users while providing building blocks for Layer 2. Multi-Asset Treasury begins the design work for the Cardano Treasury to hold stablecoins and other native assets alongside ADA. Babel Fees lets users pay transaction fees in any native asset, removing the long-standing requirement to hold ADA before transacting at all.

  Of the three, Multi-Asset Treasury is the one Socious weighs most heavily. A treasury denominated entirely in a volatile asset exposes the whole funding process — including every proposal in this cycle — to price swings; design work toward diversification is prudent stewardship, not a luxury. Babel Fees, meanwhile, addresses a real onboarding barrier that quietly costs Cardano new users.

  The initiatives are coherent, the friction points they target are genuine, and Intersect administers the funds on milestones with unspent balances returned. Socious supports this proposal.

  ソーシャスは本提案に賛成します。本提案は13,103,039 ADAを投じ、それぞれが具体的な経済的制約を取り除く三つの取り組みに資金を充てます。CIP-159によるアカウントアドレスの改良は、ウォレットによる少額手数料の徴収を可能にし、利用者にとってのDeFiのコストを下げるとともに、Layer 2のための部品を提供します。マルチアセット・トレジャリーは、CardanoのトレジャリーがADAに加えてステーブルコインなどのネイティブ資産を保有できるようにするための設計作業に着手します。Babel Feesは、利用者が任意のネイティブ資産で取引手数料を支払えるようにし、取引のためにまずADAを保有しなければならないという長年の前提を取り除きます。

  三つのうちソーシャスが最も重く見るのはマルチアセット・トレジャリーです。トレジャリーを変動の大きい単一資産だけで構成することは、今サイクルのすべての提案を含む資金プロセス全体を価格変動にさらします。分散化に向けた設計作業は、贅沢ではなく堅実な資産管理です。またBabel Feesは、Cardanoが新規利用者を静かに取りこぼしている実際の参入障壁に対処するものです。

  各取り組みは一貫しており、対象とする摩擦は現実のものです。Intersectがマイルストーンに基づき資金を管理し、未使用分が返還されることも踏まえ、ソーシャスは本提案を支持します。

• drep1yf2jzhuc4f7...

  Yes 32.3M ₳ Rationale

  Yes. ₳13.08M for Blaster (automated formal verification scaling from single-script to DApp-level, integrated with Aiken, Pebble, Scalus, Futura) and CBDE (containerized Plinth toolkit replacing days of Nix with one-command setup). Multi-team consortium delivery.

  A PDF version of this rationale is also made available.

  Vote: Yes

  ₳13.08M for two workstreams that operationalise Cardano's security-and-correctness differentiator for the broader developer pool.

  Blaster, IO's automated formal verification tool, scales from single-script to full DApp-level verification with native integration into Aiken, Pebble, Scalus, and Futura. CBDE (Container-Based Developer Environment) replaces a multi-day Nix setup with a one-command containerized Plinth toolkit. The HOSKY Cardano First framework reads strongly across multiple pillars.

  Pillar Analysis

  Adoption (lead pillar)

  CBDE eliminates the Nix-and-C-library setup step that the proposal characterizes as the source of 60-70% developer onboarding attrition; the target is under 20%. Blaster's VS Code extension, language integrations, and Common Vulnerability Library mean formal verification stops being a specialist activity and becomes a default in the standard developer workflow.

  Both shift Cardano's security promise from "available to teams with formal methods budgets" to "available to every Plinth developer by default."

  Decentralization

  The Blaster work is structured as a real multi-team consortium: Lantr (Scalus), Harmonic Labs (Pebble), SAIB (Futura), Midgard Labs, IO (Aiken), No.Witness Labs, and TxPipe each own defined work packages. The Common Vulnerability Library and the Universal Annotation Language are delivered as shared public infrastructure that any future language team can integrate against.

  Same logic as my Yes on Pebble + Gerolamo and Dingo on distributed stewardship.

  Scalability

  The equivalence checking tool enables aggressive UPLC optimization with machine-checked semantic preservation, which is the kind of compounding tooling improvement that pays back to every contract. Reducing execution-unit consumption per transaction is a complementary throughput lever to Leios, not a substitute. Lean-Blaster as an automated formal verification backend for Lean 4, with formal UPLC semantics and a CEK machine formalization, is genuine research-grade infrastructure that the optimization work compounds against.

  Governance Transparency

  Standard Intersect 2025 TRSC pattern: milestone-gated disbursement, third-party Assurer, unspent funds return to Treasury.

  Cardano's claim to be the chain for serious applications rests on formal methods being usable in practice. This proposal funds the work that makes that claim operational for the developer pool that does not bring a formal methods background.

  Risks I'm Accepting With This Yes

  Blaster pivot from IO-internal to public infrastructure

  Blaster has been an internal tool used on IO-led DApps (Djed, USDCx). Restructuring as a multi-team consortium with cross-language integration is a real shift. The consortium model is the right structural shape but execution risk exists.

  CBDE depends on the already-funded cardano-init

  CBDE integrates with the cardano-init Setup CLI from the Developer Experience proposal. Cross-proposal dependency that sits outside this proposal's scope.

  Self-reported KPIs

  "3-5x increase in active Plinth developers within 12 months" and the 60-70% to under 20% drop-off reduction are proposer-estimated. The structural deliverables (Blaster integrations, CBDE container, VS Code extension, Common Vulnerability Library, equivalence checker) are independently verifiable; the downstream adoption claims will need community measurement.

  Formal methods adoption is downstream of education and culture

  Funding the tooling does not guarantee community uptake. Developer training and DApp-team buy-in are the harder parts and not in scope here.

  Slate aggregation

  Part of the roughly ₳141.9M IO slate across seven actions. Each action stands alone.

  Bottom Line

  Cardano's security differentiator becomes real only when formal verification is a default option in the standard developer workflow. Yes.

• Liqwid DAO

  Yes 31.3M ₳ No rationale
• drep1y2xacakh0g8...

  Yes 31M ₳ Rationale

  While I still have meaningful concerns about the proposal’s limited urgency, high cost, and the lack of clear prioritization, I ultimately decided to support it after considering Cardano’s long‑term stability and the importance of maintaining high‑assurance research for future protocol safety.

• drep1ygxeadaklzz...

  Yes 30.5M ₳ No rationale
• FIMI

  Yes 29.3M ₳ No rationale
• Cerkoryn

  Yes 28.2M ₳ Rationale

  Cardano's formal verification and high assurance is one of its crowning strengths, especially in the age of AI when smart contract hacks are becoming far more common amongst our competitors. Extending Blaster to work with some of our most popular smart contract languages and creating the CBDE will help us leverage this strength to come out on top.

• Drep One

  Yes 27.9M ₳ No rationale
• TERA DRep

  Yes 27.4M ₳ No rationale
• Blockjock (James Meidinger)

  Yes 26.1M ₳ Rationale

  Rationale — High Assurance Toolkit
  Header
  Security is Cardano’s brand. This proposal helps turn that promise into a developer default.
  Constitutional Gate
  Assessment: Pass
  The proposal supports sustainable ecosystem growth through security, developer trust, and high-assurance infrastructure.
  It includes defined outputs, milestones, audits, ecosystem integrations, and consortium-based delivery. Treasury use is justified as core assurance infrastructure.
  Decision Declaration
  Vote: YES — Strategic, identity-defining infrastructure.
  This strengthens one of Cardano’s core value propositions: correctness, reliability, and security.
  Core Rationale
  This proposal expands Blaster for automated formal verification at the DApp level and supports CBDE as a one-click developer environment.
  The main value is accessibility. Formal verification is one of Cardano’s strongest differentiators, but today it remains too difficult for many developers to use. This proposal moves verification from expert-only tooling toward practical developer workflow.
  Strategic Alignment
  The proposal aligns with Cardano’s security-first positioning, institutional readiness, developer growth, and enterprise-grade infrastructure.
  It also supports high-assurance DeFi by making safer contract development easier across languages and tools.
  Economic Impact
  The impact is indirect but important.
  Better verification reduces exploit risk, protects TVL, improves institutional confidence, and lowers the cost of secure development.
  Security does not directly generate yield, but it prevents loss. That matters when real capital is expected to use Cardano applications.
  Execution Risk
  Key risks include developer adoption, coordination across multiple teams, and the complexity of scaling verification from scripts to full DApps.
  These risks are partly mitigated by multi-language integrations, VS Code support, CBDE, vulnerability templates, and developer-first tooling.
  Accountability
  The proposal has two clear workstreams: Blaster expansion and CBDE.
  Deliverables include DApp-level verification, vulnerability libraries, VS Code integration, equivalence checking, and broader language support across Aiken, Pebble, Scalus, and Futura.
  The consortium model also spreads delivery responsibility across specialized teams.
  Stablecoin Utilization
  The proposal does not appear to include a clear stablecoin strategy for treasury disbursement.
  That is a weakness. Long-duration infrastructure work requires predictable purchasing power for staffing, tooling, audits, and delivery continuity.
  The proposer should consider converting an appropriate portion of received ADA into stablecoins, and the treasury disbursement process should support staged stablecoin conversion where operating expenses need price stability.
  Security infrastructure should not be exposed unnecessarily to ADA downside volatility. Hoping a volatile asset remains at a certain price is not treasury management.
  End-User Lens
  For builders, this means formal verification becomes easier to use without needing deep formal methods expertise.
  For users, this means safer applications and lower risk of exploit-driven losses.
  For capital providers, stronger assurance improves confidence when deploying real money into Cardano DeFi.
  Conditions to Change Vote
  This rationale would materially change if developer adoption remains weak, major language integrations are not completed, delivered tools are difficult to use, or the project fails to make formal verification meaningfully more accessible.

• drep1yguh6dsgx0g...

  Yes 25.9M ₳ No rationale
• Kyle Solomon

  Yes 25.2M ₳ No rationale
• wolf31o2 (Chris Gianelloni)

  Yes 22.7M ₳ Rationale

  Blaster has started gaining traction outside Cardano. High assurance and formal proofs are our strengths. Lean into it.

• DINO

  Yes 22M ₳ No rationale
• Duc Tiger

  No 22M ₳ No rationale
• Hephaestus Stake Pool [HEPHY]

  Yes 21.2M ₳ No rationale
• SIDAN Lab

  Yes 21.1M ₳ No rationale