IO: Cardano High Assurance Technical Collaboration
236 DReps voted · 75 with a rationale
Open a row to read the rationale.
- Yes 2.3M ₳ No rationale
- Yes 2.1M ₳ No rationale
- Yes 2.1M ₳ Rationale
- Abstain 2.1M ₳ No rationale
- Yes 2.1M ₳ No rationale
- Yes 2.1M ₳ Rationale
I voted YES on IO: Cardano High Assurance Technical Collaboration because security and correctness are central to Cardano’s long-term value proposition. This proposal makes formal verification more accessible to everyday developers by extending Blaster to DApp-level verification, integrating with major Cardano smart contract languages, delivering a VS Code extension, building a Common Vulnerability Library, and providing a preconfigured developer environment. As Cardano grows DeFi, bridges, stablecoins, and institutional use cases, stronger verification tooling reduces exploit risk and increases trust. The ask is proportionate, collaborative across multiple ecosystem teams, and aligned with Cardano’s high-assurance identity.
- Yes 2.1M ₳ No rationale
- Yes 2M ₳ Rationale
High assurance and mathematical precision are Cardano's signature "weapons." However, we believe these weapons are currently being kept hidden away: they are too complex and expensive, making formal verification a privilege reserved only for experts or projects with massive audit budgets.
This proposal is revolutionary because it "democratizes" security technology. By packaging complex verification tools into familiar programming environments (like VS Code), every programmer can now automatically verify the validity of smart contracts while writing code, preventing vulnerabilities from developing.
We consider the 13 million ADA investment reasonable given the devastating hacks that have wiped out billions of dollars in TVL on other platforms. Therefore, we believe that voting YES is an action that transforms Cardano's safety philosophy into a practical tool, paving a solid path to receiving massive and stringent capital flows from traditional financial institutions.
- Yes 2M ₳ No rationale
- Yes 2M ₳ No rationale
- Abstain 1.9M ₳ No rationale
- Yes 1.8M ₳ No rationale
- Yes 1.8M ₳ Rationale
This work extends formal verification to every Cardano developer, enhancing their ability to deliver highly secure apps.
I believe this is absolutely necessary, particularly given the threat of AI to find and exploit bugs. Cardano needs to be the safest place in blockchain to build apps – this is a big step forward in that direction.
- Yes 1.7M ₳ No rationale
- Yes 1.7M ₳ No rationale
- Yes 1.7M ₳ Rationale
Proposal and methods seem to be sound. I support continued ecosystem improvements
- Yes 1.7M ₳ No rationale
- Yes 1.5M ₳ Rationale
Vote: YES — Cardano High Assurance
I support this proposal because it meaningfully strengthens Cardano’s high-assurance development ecosystem through better tooling, improved developer experience, and expanded access to formal verification.
The proposal delivers long-term public infrastructure rather than short-term incentives. Expanding Blaster across multiple smart contract languages, integrating verification directly into developer workflows, and providing reusable security templates can significantly improve smart contract quality and reduce exploit risk across the ecosystem.
The containerized developer environment is also a valuable addition. Simplifying setup and reducing tooling friction can improve onboarding, collaboration, and developer retention.
I particularly value the proposal’s ecosystem-wide approach, with contributions from multiple external teams rather than a fully centralized implementation.
While execution and adoption risks exist, the proposal is transparent about them and remains strongly aligned with Cardano’s long-term strategic focus on security, correctness, and institutional-grade infrastructure.
For these reasons, I support this proposal with a YES vote.
- Yes 1.5M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.2M ₳ No rationale
- Yes 1.2M ₳ No rationale
- Yes 1.2M ₳ Rationale
I initially voted NO on this proposal because choices needed to be made due to the NCL, but given the high level of support for this proposal, I changed my vote to YES.
- Yes 1.1M ₳ No rationale
- Yes 1.1M ₳ No rationale
- Yes 1M ₳ Rationale
This is a serious proposal. Some ₳13M for highly specialized formal-methods engineering, multi-language smart-contract integration, developer tooling, and ecosystem coordination, is, given present USD exchange rates, a realistic number.
One thing to remember, and I get this out of the way right away: Accessibility DOES NOT automatically create adoption! Cardano already has Aiken, Plinth, Plutarch-style ecosystems, property testing, audits, containers, and other developer tooling patterns. **In my view, the argument that “developers need another toolkit” is weak. **
Why I still like the proposal is that I believe that Cardano currently lacks a broadly accessible, open, formal verification pathway, which I see as a strategic necessity to industrialize Cardano’s scientific advantage through hard openness, auditability, and measurable use. This will give the Cardano ecosystem a public assurance layer for high-value applications where testing and audits alone are not good enough.
- Yes 1M ₳ No rationale
- Yes 985.7K ₳ Rationale
Important for adoption
- Yes 955.2K ₳ No rationale
- Yes 947.9K ₳ No rationale
- Yes 941.2K ₳ No rationale
- Abstain 922.9K ₳ No rationale
- Yes 860.4K ₳ No rationale
- Yes 818K ₳ Rationale
This proposal directly advances the core objectives of the Latin American Cardano community and the global network: prioritizing user trust, hardening application security, and radically expanding developer accessibility. In emerging economies like Latin America, where development teams operate with lean budgets and cannot always afford expensive external audits, embedding institutional-grade formal verification tools (Blaster) directly into standard toolchains is a massive equalizer. Furthermore, the single-click containerized environment (CBDE) solves an existential onboarding friction point for new builders.
- Yes 804.1K ₳ Rationale
Cardano's security reputation is its biggest selling point — this makes it accessible. Automated formal verification has been locked behind specialist expertise; this proposal puts it in every developer's IDE. Safer DApps means more confident users, more TVL, and a stronger case for institutional adoption.
- No 793K ₳ Rationale
Sounds great, but I don't care. IO was funded during the last major Intersect budget cycle with a long list of deliverables. Why wasn't all of this in competition for funding at that time if it was so bloody important. I'm not interested in cutting any more big checks from the Treasury with ADA at these price levels. Get your shit together and tell us what you want to accomplish as part of the primary budget cycle.
- Yes 785.2K ₳ Rationale
High-assurance tooling is Cardano’s core differentiation; this reinforces that moat in a credible way.
Moving formal verification from expert-only to developer-native (Blaster + IDE integration) is a real unlock.
CBDE meaningfully reduces onboarding friction → complements DevX initiative and increases conversion.
However, impact is indirect and slower vs L1/L2 scaling or adoption initiatives → not first-order growth driver.
Execution risk around adoption is real; without strong distribution, this risks becoming underutilized tooling. - Yes 765.1K ₳ No rationale
- Yes 762.8K ₳ No rationale
- Yes 762.6K ₳ No rationale
- Yes 738.5K ₳ No rationale
- Yes 733.1K ₳ Rationale
Yes
- Yes 670.2K ₳ Rationale
I’m voting yes because this proposal strengthens Cardano’s core advantage in security and correctness by funding automated formal verification at scale.
A PDF version of this rationale is also made available.
I’m voting yes because this proposal strengthens Cardano’s core advantage in security and correctness by funding automated formal verification at scale. It extends IO’s Blaster tool from single-script checks to full DApp-level verification, integrates it across multiple smart contract languages (Aiken, Pebble, Scalus, Futura), and pairs it with a Common Vulnerability Library, VS Code integration, equivalence checking for safer optimizations, and a one-click developer environment (CBDE) that drastically reduces setup friction and improves developer onboarding. This also directly benefits AI agents and AI-assisted development by making smart contracts more machine-verifiable, structured, and analyzable. With formal verification, standardized vulnerability templates, and UPLC-level equivalence proofs, AI agents can more safely generate, audit, and optimize contracts while reducing hallucinated or unsafe code paths—enabling more reliable autonomous development and debugging workflows on Cardano as we enter an AI driven future.
- No 654.5K ₳ Rationale
🚫 MY ANSWER IS NO. REJECTED.
IOG and related entities have already received major funding from the Cardano Treasury.
The document clearly states:
Total allocated: ₳130,708,860
Already withdrawn: ₳78,459,777Now they are asking again for:
₳13,078,578 from the Cardano Treasury.
For me, this looks simple:
first show real results for the money already received, then come back for new funding.
Yes, the proposal sounds good on paper: security, formal verification, Blaster, developer tools, and smart contracts.
But the issue is not the beautiful description.
The issue is different:
where is the final result for the millions of ADA already received?
what is the concrete benefit for ordinary Cardano users?
why should the Treasury keep paying for work that large structures should be able to develop themselves?I am not against Cardano development.
I am against constant Treasury withdrawals without strict accountability and clear results.My position is simple:
first results — then new money.
My vote on this proposal:
🚫 NO
🚫 REJECTED
🚫 The Cardano Treasury must not become an endless wallet for the same players.I registered as a DRep and I am ready to help shape the future of the ecosystem. - Optimistic about building the largest digital community in the world. 🖤 My DRep ID: ➡️ drep1y269ehxj30k4vfzfc2z84v0xykd3amuy2xn0kv9zf8rhcec2fg2jr More details here https://t.me/PROCENT666/338
🚀 COURSE “LEDGER COLD CRYPTO WALLET” | METAMASK
https://edgarbagdasarian.justclick.ru/order/LEDGERMETAMASK🔥 CLOSED VIP CHAT PAID SUBSCRIPTION
https://t.me/MREDGARCROSS_BOT🌐 ALL COURSES AND LINKS
https://mredgarcross.com/📌 Note: This post is for informational and analytical purposes only. It does not contain calls for action, protests, or violations of the law. Everything stated is the author’s personal opinion.
- Yes 624.8K ₳ Rationale
Total ask: ₳13,078,578
Development: ₳11,247,577 = 86%
Workstream split: ₳10.1M Blaster / ₳2.97M CBDE
Team: IO + 6 partners (Lantr, Harmonic Labs, SAIB, Midgard Labs, TxPipe, No.Witness Labs)
FTE estimate: $2.7M dev ÷ ~10–12 specialists ÷ 10.5 months × 12 ≈ $257–308K/yearA PDF version of this rationale is also made available.
I'm voting yes because this proposal makes Cardano's formal verification capability accessible and accessible is the operative word. Blaster already proved correctness properties for Djed and USDCx at production scale. The 2025/26 cycle demonstrated the core works. This cycle opens that tooling to the full ecosystem, extends it from single-contract to DApp-level verification, integrates it into four smart contract languages, and delivers it through a developer environment that replaces multi-day Nix configuration with a 60-second initialization.
At ₳13,078,578 (~$3.14M at $0.24) with 86% allocated to development across a nine-organization consortium consisting of IO, Lantr (Scalus), Harmonic Labs (Pebble), SAIB (Futura), Midgard Labs (Aiken), TxPipe, and No.Witness Labs each holding defined work packages, this is complex orchestration efficiently structured for its scope and duration and only possible by IO. Formal methods specialists with production-level Lean 4 depth are scarce; and therefore the implied FTE cost is appropriate. The workstream split (₳10.1M Blaster, ₳2.97M CBDE) is transparent.
Three deliverables align directly with priorities I hold and use to inform my decisions. The Container-Based Developer Environment converts the multi-day Nix setup barrier into a single command, this is the accessibility work that makes Cardano's high-assurance tooling available to developers who are building, not just the narrow cohort that can configure it. The Common Vulnerability Library containing pre-built property templates for Double Satisfaction, Large Value Attack, and Large Datum Attack, produced with auditing partners and open for contribution, democratizes security analysis that currently requires expensive specialist. The VS Code Extension V2 includes an LLM-friendly counterexample format for AI-assisted debugging, which is exactly the kind of AI/LLM integration that should be embedded in Cardano's developer tooling from the start rather than bolted on afterward and early alignment is critical.
The proposal is honest about the hard parts. Scaling from single-contract to multi-script DApp-level verification is rated "Medium" likelihood and "High" severity; the formal methods team is small and subject to IO reprioritization risk. It's equally honest about what's not funded: community outreach is a stated benefit dependency requiring coordination with the Developer Experience Initiative, while this proposal builds the tools, it’s not the distribution flywheel. Standard milestone-based Intersect governance keeps funding accountable. - Yes 589.2K ₳ Rationale
Will take every win and every advancement that IO can deliver on the path towards Crypto Eating Legacy
- Yes 536.5K ₳ Rationale
Cardano unique selling point has always been reliability, this tooling strengthens that position
The IOG team delivering them is undoubtedly the best implementor we could ask for.
It is a little pricey, but that is to be expected if we are demanding the best of the best to work on our core infrastructure.