IO: Cardano High Assurance Technical Collaboration
236 DReps voted · 75 with a rationale
Open a row to read the rationale.
- Yes 21.1M ₳ No rationale
- Yes 20.3M ₳ No rationale
- Yes 19.9M ₳ Rationale
As Cardano strives to be the financial operating system of the world, high assurance formal verification tooling is essential for security of our DApp ecosystem. Improving this tooling and making it more accessible is very useful.
I expect this to be particularly useful once the DeFi Kernel is implemented and tooling on top of this is created. It makes a lot of sense to follow both at the same time. - Yes 17.1M ₳ Rationale
IO: Cardano High Assurance Technical Collaboration
- Abstain 16.7M ₳ Rationale
I’m voting Abstain because I accept the premise that higher assurance and verification tooling strengthens long-term security and trust, but the proposal does not provide sufficient budget transparency and measurable success criteria to justify treasury spending at a multi-million-ADA scale. The document makes the case for value, but for public funding this size I expect a clear mapping of “who delivers what” (named teams/roles), explicit FTE counts and rate assumptions, and concrete milestone acceptance evidence that can be independently verified rather than broad work packages and high-level claims about impact. I also want quantified KPIs/baselines tied to milestone gates (e.g., measurable adoption/usage of the delivered tooling, integration targets, and outcomes that can be observed over time). Finally, we are giving a process penalty for bypassing the Intersect Budget Process, which was specifically designed to address the gap in the process between proposers and Dreps. Bypassing the Intersect budget mechanism undermines comparability and price discovery for a major protocol spend, and founding entities should set the example by using the improved process rather than routing around it.
- No 16.4M ₳ Rationale
IO has been funded by a significant amount of premine tokens.
- Yes 14.2M ₳ No rationale
- Yes 14.1M ₳ No rationale
- Yes 13.3M ₳ Rationale
RCADA Rationale
RCADA votes YES on the IO: Cardano High Assurance Technical Collaboration Treasury Withdrawal proposal.
We support this proposal because it strengthens one of Cardano’s clearest and most important differentiators: high-assurance, security-first development. Cardano has long positioned itself as a blockchain for serious applications where correctness, reliability, and trust matter. However, the practical benefits of formal methods and high-assurance engineering will only reach the wider ecosystem if the tools become accessible to everyday developers, not only specialist auditors, researchers, or formal-methods experts.
This proposal directly addresses that gap.
The first workstream expands Blaster, IO’s automated formal verification tool, from single-script verification toward full DApp-level verification. It also introduces integrations with Aiken, Pebble, Scalus, and Futura; a VS Code extension; visual counterexample exploration; a Common Vulnerability Library; equivalence checking for UPLC programs; and proof reconstruction capabilities. These are meaningful improvements because they make verification more usable, more practical, and more relevant to real-world Cardano DApp development.
The second workstream delivers a Container-Based Developer Environment, intended to package the high-assurance toolkit into a single-command setup. RCADA sees value in this because setup complexity remains a real barrier for Cardano developers. A reliable pre-configured environment can reduce onboarding friction, improve consistency between teams, and make advanced tools easier to adopt.
RCADA also views the collaboration model positively. The proposal includes contributions from IO, Lantr, Harmonic Labs, SAIB, Midgard Labs, TxPipe, and No.Witness Labs. This is the kind of multi-party technical collaboration we want to see more of across the Cardano ecosystem. It broadens delivery responsibility, supports multiple developer communities, and helps avoid high-assurance infrastructure being locked inside one team or one language stack.
The ecosystem value is significant. If successful, this work could help developers identify vulnerabilities earlier, reduce reliance on expensive expert-only assurance processes, improve confidence in production DApps, support safer optimisation, and strengthen Cardano’s credibility with institutional users. In a market where smart contract exploits continue to damage trust, Cardano should lean into the advantage it already has: correctness, formal reasoning, and secure-by-design infrastructure.
That said, RCADA’s YES vote is not without reservations.
The proposal requests ₳13,078,578, with a large share of the budget grouped under development. While we accept that specialist formal-methods work is expensive and requires rare expertise, future proposals of this kind would benefit from clearer partner-level budget breakdowns, staffing assumptions, and milestone-level cost attribution. Treasury-funded work should be understandable not only to experts, but also to the wider community that ultimately pays for it.
We also believe adoption must be treated as a core success condition. A technically excellent verification tool provides limited ecosystem value if it remains underused. The proposal itself recognises that without dedicated promotion and developer outreach, Blaster and CBDE may see low adoption despite being delivered on time. RCADA therefore expects strong documentation, examples, developer education, visible integration paths, and public reporting on actual usage across supported languages.
Execution risk should also be monitored carefully. Scaling Blaster from single-contract to multi-script DApp-level verification is ambitious, and the proposal depends on several specialist contributors delivering coordinated work packages. RCADA supports this ambition, but we expect milestone acceptance and third-party assurance to pay close attention to whether the delivered tools are genuinely usable by external developers, not merely completed in a technical sense.
Overall, RCADA believes this proposal is well aligned with Cardano’s long-term identity and strategic needs. It is more coherent than several other proposals in this funding round, has a clear public-good character, supports distributed technical collaboration, and could materially improve the security baseline for Cardano applications.
For these reasons, RCADA votes YES, while encouraging clear partner accountability, practical documentation, adoption reporting, and improved cost transparency in future high-assurance funding requests.
RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/."
- No 12.2M ₳ Rationale
At this moment, we view this proposal as a WANT rather than a NEED for the Cardano ecosystem. While the proposal introduces technically sophisticated tooling around formal verification and developer environments, the ecosystem’s current priorities remain centered on adoption, liquidity growth, scalability execution, user activity, and strengthening competitive positioning across DeFi and real-world applications.
IO requests ₳13,078,578 from the treasury for tooling and developer infrastructure that, while valuable in principle, does not directly address the most immediate growth constraints currently facing Cardano. Our ecosystem is still actively working through challenges related to liquidity growth, user adoption, transaction demand, scalability execution, stablecoin expansion, and DApp competitiveness. At this stage of ecosystem maturity, we believe that treasury allocations should prioritize initiatives that can generate measurable near-term increases in users, transactions, developer retention, and economic activity. This proposal instead focuses primarily on advanced formal verification infrastructure whose impact remains indirect, difficult to quantify, and likely years away from meaningful ecosystem-wide realization.
The proposal’s KPI assumptions are also highly speculative. It attempts to connect formal verification tooling and developer environment improvements to increases in TVL, throughput utilization, protocol revenue, and monthly active users. However, there is limited evidence demonstrating that formal verification accessibility alone materially increases adoption or capital inflows in blockchain ecosystems. Institutional adoption depends on many factors beyond contract correctness, including liquidity depth, regulatory clarity, interoperability, user demand, and market positioning. The proposal effectively assumes that stronger tooling will naturally translate into ecosystem growth, but this relationship is neither immediate nor guaranteed.
A major concern is the mismatch between the proposal’s complexity and the current size of the active Cardano developer base that would realistically use these tools. Formal verification remains a highly specialized discipline even within mature software ecosystems. Although the proposal aims to simplify the experience through Visual Studio Code integrations and prebuilt templates, most developers in practice prioritize rapid iteration, composability, and shipping products quickly over mathematically proving correctness properties. This confirms that the proposal risks building sophisticated infrastructure for a relatively narrow subset of advanced developers rather than materially improving onboarding and retention across the broader ecosystem.
We urge the community to also consider the timing of this request in the context of already-funded Layer 1 scaling and infrastructure initiatives. Significant treasury resources have recently been allocated toward major protocol and scalability workstreams such as Leios, Peras, and other foundational capacity expansion efforts. Those initiatives are directly tied to increasing Cardano’s transaction throughput, network performance, and competitiveness. This proposal attempts to frame formal verification tooling as complementary to scalability by improving UPLC optimization efficiency, but the actual throughput gains described are marginal compared to the impact expected from already-funded protocol-level scaling initiatives.
There are also substantial execution and dependency risks embedded throughout the proposal. Several deliverables depend on coordination across multiple ecosystem partners, including TxPipe, Lantr, Harmonic Labs, Midgard Labs, and SAIB Inc. The proposal itself acknowledges that delays or underperformance from collaborators could materially impact key milestones, especially language integrations and vulnerability libraries that are critical to ecosystem-wide adoption.
Additionally, important parts of the proposal depend on other treasury initiatives being funded separately. The proposal explicitly states that portions of the onboarding and discoverability strategy rely on the Developer Experience initiative and cardano-init. If those initiatives are not approved or delayed, parts of this proposal become fragmented and less accessible, weakening the ecosystem impact used to justify the treasury ask.
Another governance concern is treasury concentration and repeated reliance on a single organization. The proposal comes from IO, which has already received substantial treasury allocations across multiple workstreams. The proposal itself notes that IO-affiliated initiatives have been allocated over ₳130 million in treasury funding to date. While IO remains a core technical contributor to Cardano, governance should be cautious about continuously approving large allocations to the same organization without stronger evidence of ecosystem diversification, independent delivery capacity, and broader decentralization of technical leadership.
The proposal also places heavy emphasis on future ecosystem positioning rather than present ecosystem needs. Many of the deliverables, including the DApp proof framework, multi-contract verification system, and advanced proof reconstruction modules, are scheduled for delivery in 2027. This means the ecosystem would be committing a significant treasury allocation today for tooling whose adoption, utility, and measurable ecosystem impact may not materialize for several years. In a treasury environment with finite resources and many competing priorities, governance should favor initiatives with clearer short- and medium-term returns.
Finally, the proposal itself acknowledges that delivery alone is insufficient to generate adoption and that dedicated outreach, education, and ecosystem visibility are required for success; yet those activities are not fully funded within the proposal scope. This creates a situation where the treasury may fund technically sophisticated infrastructure without guaranteeing the ecosystem coordination necessary to achieve the adoption metrics used to justify the request.
- Yes 11M ₳ No rationale
- Yes 10.8M ₳ No rationale
- Abstain 10.5M ₳ Rationale
This is already over the threshold. My vote doesn't effect the outcome.
- No 9.6M ₳ No rationale
- Yes 8.8M ₳ Rationale
私はこの提案に賛成します。Cardanoの強みである高保証性や正確性を、実際の開発へ落とし込む重要な提案だと考えています。特に、自動形式検証や共通脆弱性ライブラリ、VS Code統合、複数言語対応などによって、これまで一部の専門家に限られていた高保証ツールを、より多くの開発者が利用可能になる点を評価しています。また、コンテナベース開発者環境（CBDE）による環境構築簡略化は、Cardanoエコシステムにおける開発者参入障壁の改善にも寄与すると考えます。Cardanoは高品質・高安全性を重視するチェーンであり、その思想を実際のDApp開発へ落とし込む取り組みは、中長期的に重要だと考えています。短期的なKPIや普及には不確実性も存在しますが、Cardanoエコシステム全体の技術基盤強化につながる重要な投資だと考え、本提案を支持します。\n\nI support this proposal. I believe this is an important proposal that brings Cardano’s strengths in high assurance and security into practical development workflows. In particular, I appreciate that automated formal verification, a common vulnerability library, VS Code integration, and multi-language support will make high-assurance tooling, which has traditionally been limited to specialists, accessible to a broader range of developers. I also believe that simplifying environment setup through the Container-Based Developer Environment (CBDE) will help reduce barriers for developers entering the Cardano ecosystem. Cardano is a chain that emphasizes high quality and strong security, and I believe efforts to bring that philosophy into actual DApp development are important from a medium- to long-term perspective. While there are still uncertainties regarding short-term KPIs and adoption, I believe this represents an important investment in strengthening the Cardano ecosystem’s technical foundation, and for that reason I support it.
- Yes 8.1M ₳ No rationale
- Yes 7.8M ₳ No rationale
- No 7.8M ₳ No rationale
- Yes 7.3M ₳ No rationale
- Abstain 7.1M ₳ Rationale
I’m voting ABSTAIN, but there is a path to YES.
I like this proposal, and also the new IO proposals more generally, because this is structured as a technical collaboration rather than a purely IO-internal build. IO, Lantr, Harmonic Labs, SAIB, Midgard Labs, TxPipe and No.Witness Labs are all involved. This kind of collaboration makes sense not only politically, but technically as well. This is a kind of mini-Cardano build fest under the hood too.
Teams can easily end up competing for funding instead of building together. This more collaborative approach from IO is commendable. I would encourage all participating teams to commit to hard milestone discipline. If this proposal is delivered well, it can become real public infrastructure for Cardano developers.
Blaster operating at the UPLC level is potentially very valuable long-term as Cardano gains more traction. Since UPLC is the common target for Cardano smart contract languages, this gives the work broader ecosystem value. Coverage for Aiken, Pebble, Scalus and Futura makes the proposal more ecosystem-wide. I would like to see clear acceptance criteria for what counts as a successful language integration.
The proposal also acknowledges that scaling Blaster from single-contract verification to multi-script DApp-level verification may be harder than expected. The adoption risk is also real.
The claim that formal verification directly addresses the security risk that deters institutional capital from Cardano DApps might be a bit overblown. It helps, but it is only one part of institutional confidence. Liquidity, audits, UX, stablecoins, custody and market depth also matter. However, security is becoming a bigger point of interest as AI makes vulnerability discovery and automated probing easier.
For me, the main things to clarify are long-term maintenance and real-world usage. Who maintains Blaster, CBDE and the language integrations after Q2 2027? Is this going to become a standing Treasury obligation? I ask because we are developing a lot of tools and infrastructure that seem to have ongoing costs. Is there room for the Cardano Foundation to be involved, or for Intersect to steward some of the public-good components?
I would also like the teams to provide evidence, before project closure, that non-IO developers can actually use the system in real development work. External developer testing and feedback should be part of the success criteria, not just promotion after delivery. If these points are incorporated into the milestones or reporting, I would be comfortable voting YES.
- Yes 6.2M ₳ No rationale
- Yes 6M ₳ Rationale
I am voting Yes.
While this proposal does not directly advance user growth, it addresses a core requirement for any sustainable ecosystem: security and correctness at the protocol level.
High-assurance engineering reduces the risk of critical failures that can undermine trust and adoption. In that sense, it supports the long-term viability of everything built on top of the chain.
I would still expect continued scrutiny around cost and efficiency in this category, but at a base level, this is important work to fund.
- Yes 5.5M ₳ No rationale
- Yes 5.5M ₳ No rationale
- Yes 5.3M ₳ Rationale
Voting YES. Strong treasury stewardship, decentralising multi-vendor delivery, and proposal soundness make this one of the better-structured treasury asks in the 2026 batch. Formal verification is core to Cardano's institutional credibility, and this proposal makes it accessible to all developers.
The structural safeguards in this proposal - multi-sig disbursement, independent oversight, third-party milestone assurance, proportional refund - should be the template for all treasury withdrawals, not the exception. The multi-vendor delivery model actively decentralises Cardano's high-assurance stack rather than entrenching any single team. Formal verification is the credibility layer institutional capital requires, and making it accessible to all developers via Blaster + CBDE removes a structural barrier that has held the ecosystem back.
Peter Horsfall - Independent DRep, Oceania.
- Yes 5.3M ₳ Rationale
STORM Partners votes YES on IO: Cardano High Assurance Technical Collaboration.
Cardano’s strongest strategic claim is that it can support high-assurance, production-grade applications. This proposal directly reinforces that differentiator by making formal verification more accessible to everyday builders, not only auditors and formal methods specialists.
We view the multi-team structure positively. IO, Lantr, Harmonic Labs, SAIB, Midgard Labs, TxPipe, and No.Witness Labs each contribute to defined components, which helps distribute technical stewardship across the ecosystem rather than keeping high-assurance tooling concentrated in one organization.
The ask is meaningful, and we remain conscious of NCL pressure. But compared with broader infrastructure proposals, this is targeted work with a clear link to developer experience, smart contract security, institutional DeFi readiness, and application quality. Making tools like Blaster available across Aiken, Pebble, Scalus, and Futura could reduce audit costs, improve confidence in DApps, and strengthen Cardano’s credibility for higher-value use cases.
Our YES comes with an expectation that delivery must translate into actual developer adoption: usable integrations, clear documentation, public examples, and reporting on real projects using the toolkit. Formal verification only matters if builders can use it.
- Yes 4.8M ₳ No rationale
- Yes 4.8M ₳ No rationale
- Yes 4.5M ₳ No rationale
- Yes 4.4M ₳ No rationale
- Abstain 4.2M ₳ Rationale
[Portuguese]
Optamos pela "ABSTENÇÃO" nesta ação de governança "Cardano High Assurance Technical Collaboration" (gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3q2yd5rxu), pois reconhecemos sua relevância técnica para a evolução da Cardano, especialmente ao ampliar o acesso a ferramentas de verificação formal, fortalecer a segurança de DApps e reduzir barreiras de desenvolvimento. A proposta aborda temas importantes para consolidar a rede como uma infraestrutura segura e confiável para aplicações críticas. Apesar disso, entendemos que o valor solicitado, de ₳13.078.578, é elevado e depende da execução coordenada de entregas complexas entre múltiplas equipes, além de exigir adoção efetiva pela comunidade para que os benefícios esperados se concretizem. Embora a proposta apresente mecanismos positivos de controle e transparência — como desembolsos condicionados a marcos, supervisão independente, administração pela Intersect e devolução de fundos não utilizados — optamos pela abstenção por cautela em relação ao custo, à capacidade de execução e à mensuração prática do impacto real no ecossistema.
[English]
We chose to "ABSTAIN" on this governance action "Cardano High Assurance Technical Collaboration" (gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3q2yd5rxu), because we recognize its technical relevance to Cardano’s evolution, particularly in expanding access to formal verification tools, strengthening DApp security, and reducing development barriers. The proposal addresses important areas for positioning the network as a secure and reliable infrastructure for critical applications. However, we believe that the requested amount of ₳13,078,578 is substantial and depends on the coordinated execution of complex deliverables across multiple teams, as well as effective community adoption for the expected benefits to materialize. Although the proposal includes positive transparency and accountability mechanisms — such as milestone-based disbursements, independent oversight, administration by Intersect, and the return of unused funds — we chose to abstain out of caution regarding the cost, execution complexity, and the practical measurement of its real impact on the ecosystem. - Yes 4.2M ₳ No rationale
- Yes 4M ₳ No rationale
- Yes 3.8M ₳ Rationale
Valuable expansion to preserve Cardano's USP vs. other blockchains.
A PDF version of this rationale is also made available.
I support this proposal with reservations.
This is one of the more legitimate treasury public-goods proposals in the current round. Cardano’s differentiation around correctness and high-assurance development only matters if those capabilities become accessible ecosystem infrastructure rather than remaining specialized IO-only tooling.
The proposal addresses several real bottlenecks:
- formal verification accessibility,
- multi-language smart contract support,
- developer onboarding friction,
- and shared vulnerability tooling.
The expansion across Aiken, Scalus, Pebble, and Futura is strategically important because verification infrastructure should support the broader language ecosystem rather than reinforcing a single implementation path.
I also view the consortium structure positively relative to pure single-vendor delivery. Shared stewardship across multiple technically credible ecosystem teams is healthier than further concentration inside one organization.
That said, I have meaningful concerns.
The proposal is heavily bundled, reducing governance precision. Long-term maintenance economics and operational ownership are insufficiently defined, which is important because verification and developer tooling create ongoing support obligations rather than one-time deliverables.
I also do not believe DReps currently have sufficient procurement visibility to confidently assess cost efficiency at the line-item level. The proposal appears directionally reasonable for highly specialized formal methods engineering, but transparency remains weaker than ideal for treasury-scale capital allocation.
Finally, while this proposal improves ecosystem tooling diversity, the ecosystem should remain cautious about excessive dependence on IO-originated infrastructure and standards coordination over time.
Overall, I believe the strategic and public-infrastructure value outweighs the governance concerns, but those concerns remain material and should not be ignored in future treasury processes.
- Yes 3.7M ₳ Rationale
Cardano has established itself as one of the most secure blockchains in the industry and we must keep it that way. Formal methods and the proposed tooling are essential as we enter the AI era, where discovering system vulnerabilities becomes accessible to a much wider audience. This is a smart and necessary investment to ensure our ecosystem remains strong and resilient.
==========================================
In general (and this applies to all IOG proposals), I firmly believe Charles is the most capable leader to guide Cardano into its next phase. With his experience, resources, technical knowledge, his army of developers, researchers and strong personal incentive for Cardano’s long term success, I will vote in favor of everything his company proposes. I wish we had even better alternatives, but we don't, cause there aren't any.
Since I am not a technical expert (particularly in this AI driven era), I will not pretend to fully evaluate the cost of these initiatives. That said, for a blockchain with a $10 billion market cap, an annual investment of approximately $40 million in core development does not seem excessive, especially in such a fast moving and highly competitive industry. Ultimately, this level of funding only makes sense if one trusts the incentives and capabilities of the person responsible for managing these resources.
I have also carefully reviewed the arguments circulating on X against funding IOG and find them unconvincing, as they never offer any viable alternative path forward. This includes the so called “conflict of interest” concerns regarding Midnight Ambassadors who are also DReps.
For transparency, I maintain close and regular communication with my 240 delegators through our Greek DAO Discord channel and update them via YouTube videos. They fully understand and expect me to ignore the social media noise, chaos and paranoia, and instead follow common sense and what is genuinely best for Cardano. - Yes 3.5M ₳ No rationale
- Yes 3.1M ₳ No rationale
- Yes 2.9M ₳ No rationale
- Yes 2.8M ₳ Rationale
I'm happy to vote YES for this proposal. Blaster is an essential tool that can be used to significantly reduce the startup costs of any builders on Cardano through an open-sourced automated formal verification tool without the high costs required to submit code to formal verification companies.
Additionally, support for Blaster with 4 additional programming languages (Aiken, Pebble, Scalus, and Futura) is a significant additional support for builders in the Cardano ecosystem.
What concerns me is:
CBDE directly converts the current multi-day Nix setup barrier into a 60-second initialization. Source documents indicate that developer onboarding attrition currently runs at 60–70%; CBDE targets a reduction to under 20%.
A developer onboarding attrition rate of 60-70% is terrible for Cardano, and this tooling should have been prioritized sooner if it results in an attrition rate of under 20%. This is a serious developer bottleneck that has not been prioritized or addressed in the past, and has likely resulted in serious losses for the Cardano ecosystem over the years we have been attempting to attract builders.
Also, in no way should any founding entity, like IOG or its founder Charles Hoskinson publicly attack and pressure Cardano community members and DReps into voting Yes for their proposals. This dishonorable and disrespectful behavior is unbecoming of any leader who wishes to be taken seriously and in turn granted respect.
If this behavior continues in the future, I will be downvoting every proposal by such entities who behave this way as a consequence. Please keep in mind that actions have repercussions.
I also do not appreciate IOG frontrunning the entire Intersect budget process with the intent of claiming the entire NCL for 2026 and leaving nothing for community builders.
I expect this proposal to complete all deliverables as stated, and if this is not done, IOG will receive no further Yes votes from me in the future.
- Yes 2.7M ₳ No rationale
- Yes 2.7M ₳ No rationale
- Yes 2.7M ₳ No rationale
- Yes 2.6M ₳ No rationale
- Yes 2.5M ₳ No rationale
- Yes 2.5M ₳ Rationale
Good idea
- Yes 2.5M ₳ Rationale
本提案は、「Cardanoの“高信頼性”を、専門家だけの武器から、一般DApp開発者が使える標準装備にする提案」です。個々のスマートコントラクト単位の検証から、複数の契約や取引が連動するDApp全体の検証へ発展させることで、実際のアプリ運用に近い安全性確認を進めやすくします。さらに、Aikenなど複数言語、VS Code、共通脆弱性テンプレート、UPLC等価性チェックとも連携し、開発現場で使いやすい形に整備されます。技術難度と普及リスクはありますが、DeFiやブリッジ等の安全性を高め、Cardanoの「安全で正しいスマートコントラクト基盤」という強みを実用レベルへ広げる戦略的投資として支持します。
This proposal is “about turning Cardano’s high assurance from a specialist tool into a standard capability that ordinary DApp developers can use.” It expands verification from individual smart contracts to entire DApps where multiple contracts and transactions interact, making it easier to assess security closer to real application behavior. It also integrates with multiple languages such as Aiken, VS Code, common vulnerability templates, and UPLC equivalence checking, making these tools more practical for developers. While there are technical and adoption risks, I support this as a strategic investment that strengthens DeFi, bridges, and Cardano’s identity as a secure and correctness-oriented smart contract platform.
- No 2.5M ₳ Rationale
While I appreciate that this proposal spreads funding across multiple quality ecosystem teams and builders, I cannot support it in its current form.
The primary issues are transparency in budgeting and measurable KPIs/alignment:
Budget clarity: The proposal names participating teams and high-level work packages, but provides no granular breakdown. There is no visibility into which teams are responsible for which specific deliverables, no FTE allocations, and no insight into cost rates or justification. At this scale, dReps and the community deserve a clearer picture of exactly how the treasury funds will be deployed.
KPIs and strategic alignment: The proposal does an excellent job explaining the theoretical value of high-assurance engineering (formal verification, audits, correctness testing). However, it lacks concrete market data or verifiable sources demonstrating that these gaps are currently blocking adoption, TVL growth, or developer activity. The listed KPIs remain high-level claims without quantified targets or success metrics. Questions such as “how many additional developers or dApps will this unlock?” are left unanswered, making it impossible to objectively measure the proposal’s success after the fact.
Finally, while IO’s coordination role is understandable given their existing code ownership, this work could (and arguably should) be structured as independent proposals from the specialist teams themselves. That would further strengthen the distributed-ownership model the 2030 Vision aims to achieve.
I remain open to revisiting my vote if the proposers provide a detailed budget table, quantified KPIs with baselines and targets, and clearer success criteria before the voting window closes.
- Yes 2.4M ₳ No rationale
- Yes 2.4M ₳ No rationale
- Yes 2.4M ₳ No rationale