DRepTalk
Sign in
Governance ActionsDiscussionsDRepsTreasury
Sign in
More ways to sign in

IO & Ensurable Systems: Cardano Maintenance Initiative

System 2mo ago1post
DReps 239 SPOs 0

239 DReps voted · 78 with a rationale

Open a row to read the rationale.

  • Yoroi W₳llet
    Yes 592.3M ₳ Rationale

    Summary

    Yoroi DRep votes YES on the Cardano Maintenance Initiative, as the foundational operational expenditure underpinning every other initiative currently being funded from the Cardano treasury.

    Rationale

    Non-discretionary infrastructure

    Maintenance is continuous and non-optional. The nine functional areas covered constitute the minimum viable operating surface for Cardano as a production network. Gaps in any of them carry direct consequences for SPOs, developers, and end users.

    Everything else depends on this

    The Cardano Blueprint enables node diversity. E2E testing and release management make hard forks safe. Performance benchmarking enables evidence-based parameter decisions. This proposal is not parallel to the ecosystem’s other priorities. It is the substrate they rest on.

    Proportionate cost for genuine scope

    Nine months of cross-functional delivery across engineering, DevOps, QA, performance, security, documentation, and release management. IO’s prior track record of treasury accountability further supports confidence in delivery.

    Conclusion

    Yoroi votes YES. A well-maintained Cardano is not one option among many. It is the precondition for the ecosystem’s 2030 ambitions to be realised at all.

  • YUTA
    Yes 428.5M ₳ Rationale

    I vote YES to "IO & Ensurable Systems: Cardano Maintenance Initiative."

    1. Reasonable Cost

    Compared to some data on maintenance costs for Ethereum and Solana, I don't think the cost is excessively high. Since FTE is not publicly available, it's one of the metrics that allows for comparison with other ecosystems. The AI ​​analysis on the following site partially captures this, but it doesn't include costs other than those of the Ethereum Foundation for DevOps, so if those are taken into account, it approaches the industry standard.

    https://adatool.net/b69-share/io-maintenance

    1. Long-Term Sustainability

    On the other hand, even if it's close to the industry standard, this amount is not sustainable compared to the revenue of the Cardano chain.

    One factor is the lack of development of alternative nodes or alternative talent. Basically, these are things that must be reduced through continued efforts.

    For talented developers who have gone through a competitive recruitment process, maintenance is generally not a particularly "exciting" job, involving tasks like resolving technical debt and handling incidents. Therefore, they tend to prefer automation and AI utilization to avoid wasting time on maintenance, and instead focus on more exciting projects like Leios. They have promised to reduce costs through the use of AI and other means.

    In conclusion, while this amount is not unusually high for the industry, and long-term sustainability is a common topic, there are no alternative teams, and these efforts must continue. The team seems to have an incentive to continue these cost-reduction efforts, so overall, I vote YES.

    私は「IO & Ensurable Systems: Cardano Maintenance Initiative」にYESを投票します。

    1. 金額の妥当性

    イーサリアムやSolanaのメンテナンス費用のいくつかのデータと比較して、異常に高額とは言えないと考えました。FTEは公開されませんので、他のエコシステムとの比較が可能な指標の１つです。次のサイトのAI分析は部分的にそれを捉えていますが、DevOpsについて例えばEthereum財団以外のコストが計上されていないため、それらを加味すると業界的には近い水準へ近づきます。

    https://adatool.net/b69-share/io-maintenance

    1. 長期的な持続可能性

    一方で、業界の水準に近いとしても、Cardanoチェーンの収益と比較して、これは持続可能な金額ではありません。

    代替ノードあるいは代替的な人材が育っていないことは１つの要因です。基本的にはこれらは削減の努力を続けるほかありません。

    競争力ある採用プロセスを経た才能のある開発者にとって、一般論としては、このメンテナンスは技術負債の解消やインシデント対応など、比較的に「エキサイティング」な仕事ではないため、メンテナンスに不要な時間をかけずに自動化、AIの活用を進め、よりエキサイティングなLeiosなどの関与を願う傾向があるという話も聞きました。AIの活用等によりコスト削減を進めることを彼らは約束しています。

    結論としては、この金額は業界としては異常に高額とは言えず、一方で長期的な持続可能性の話題は一般的に存在するものの、代替チームはなくこれらは努力を続ける必要があり、チームはこの削減の努力を続けるインセンティブがあるようですので、総合的に見て、YESを投票します。

  • Blockdaemon
    Yes 328.3M ₳ No rationale
  • EMURGO
    Yes 297.4M ₳ Rationale

    Summary

    EMURGO as a DRep votes YES on the treasury withdrawal titled “IO & Ensurable Systems: Cardano Maintenance Initiative”, with rationale outlined below.

    Rationale

    Every capability the Cardano ecosystem is building toward depends on a platform that is stable, well-tested, and reliably released. The Cardano Maintenance proposal funds exactly that foundation. It is not a feature investment; it is the operational envelope without which every other treasury-funded initiative carries elevated execution risk.

    The scope is comprehensive and appropriately so. Node bugfixing, CI/CD operations, security reviews, E2E testing, performance benchmarking, Plutus interpreter maintenance, DB-Sync consistency, and the Cardano Blueprint documentation together constitute the non-negotiable maintenance surface of a production blockchain. Deferred maintenance compounds, and the cost of catching up consistently exceeds the cost of continuity.

    IO, in collaboration with Ensurable Systems, is the team best positioned to deliver this work. The institutional knowledge embedded across consensus, ledger, networking, and release engineering is not easily replicated. The 62.1 million ADA request reflects the true cost of sustaining a production-grade blockchain at this level of complexity across a nine-month period, and EMURGO is satisfied that it is a proportionate ask. For these reasons, EMURGO votes YES.

  • CryptoCrow
    Yes 240.8M ₳ No rationale
  • Eternl DRep Committee
    Yes 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 believe the team does a very honest job when it comes to maintenance initiatives, and I do feel there will be quite a bit more work than historically given the rise of AI creating a lot more maintenance work in security all parts of the software. I have confidence in IOG to deliver on this.

  • Everstake
    Abstain 160.5M ₳ No rationale
  • Cardano Foundation
    Abstain 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 have decided to vote YES on the proposal: IO & Ensureable Systems: Cardano Maintenance Initiative.

    My rationale:

    This is one of the most important proposals in the current cycle, but also one of the most difficult to evaluate, as it sits in a gray zone. Maintenance is unquestionably necessary for the network to function, yet it is inherently harder to measure, benchmark, and justify with precision compared to feature-driven work.

    I want to clearly state that the proposal, in its current form, lacks sufficient transparency relative to its size. The overall budget is high, and while the scope is broad, the level of detail provided does not allow DReps to assess cost efficiency properly. A more granular breakdown is needed, including clearer information on team size, FTE allocation, salary assumptions, and cost distribution across specific components and activities.

    Ethereum provides a useful benchmark for funding core protocol maintenance. More than $100M has been distributed over multiple years, roughly three to four, to support base-layer development across multiple independent client teams, including execution clients such as Geth, Reth, Nethermind, Besu, and Erigon, and consensus clients such as Prysm, Lighthouse, Lodestar, Nimbus, and Teku, along with supporting research, testing, and infrastructure work.

    This implies an approximate annualized funding level of $25M to $35M for the entire multi-client ecosystem, not for a single team.

    Through initiatives like Protocol Guild, funding is distributed across roughly 190 contributors and around 30 teams. Total compensation for experienced Ethereum engineers typically falls in the range of $100k to $180k annually.

    By contrast, IO is requesting approximately ₳62.1M, or about $15M, for nine months of maintenance for a single primary implementation, which annualizes to nearly $20M.

    This does not include additional IO proposals for consensus upgrades, protocol improvements, and other initiatives.

    For additional context, alternative node teams are operating at significantly lower budgets. The Amaru team requested approximately $3.04M, and the Dingo team approximately $2.07M.

    While IO's scope is broader, the difference in scale highlights the need to continuously push towards cost efficiency, especially in a future where multiple node implementations will require ongoing funding.

    Maintenance is clearly essential, but this proposal concentrates a very large budget within a single entity. Compared to Ethereum's multi-client ecosystem, which is supported through distributed funding across many independent teams, this level of funding for one dominant implementation requires significantly greater transparency and justification.

    The proposal does not provide a breakdown that would allow DReps to determine how much of the requested budget is allocated specifically to maintaining the Haskell node versus other components. Costs are aggregated across broad categories, making it difficult to assess efficiency at the component, team, or deliverable level.

    Similarly, while the funding distribution table provides a high-level overview, categories such as "Governance" and "Engagement & Ecosystem support" are not sufficiently defined. Without a clearer scope, deliverables, and resource allocation, it is difficult to evaluate whether these costs are justified or optimally structured.

    Despite these concerns, I am voting in favor of this proposal because maintenance is not optional. It is a fundamental requirement for the stability, security, and continuity of the network. Without it, all other investments in the ecosystem would be at risk.

    I am fully aware of the reputational risk if the IO does not receive key funding.

    However, this approval should not be interpreted as acceptance of the current level of transparency or cost structure. Going forward, I strongly encourage IO to move towards a more detailed and modular budgeting approach. This could include separating core areas such as node maintenance, infrastructure, and ecosystem support into distinct proposals, each with clearly defined scope, FTEs, and cost assumptions.

    If Cardano is moving towards a multi-node environment, as is clearly the case with Amaru, Dingo, and other implementations, then the cost structure across nodes must become more comparable and transparent. It is difficult to justify a situation where one implementation is maintained at a significantly higher cost without a clear, data-driven justification.

    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 & Ensurable Systems: Cardano Maintenance Initiative.

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

    SIPO supports this proposal as the foundational infrastructure layer that every other proposal in this round depends on. As the proposal itself states: "Maintenance is not a feature. It is the foundation that every feature depends on." At ₳62,134,630, this is the largest single ask in this round, but the scope justifies the size — nine functional areas covering the complete maintenance and operational envelope for Cardano over a continuous nine-month period (Q3 2026 to Q1 2027). Without sustained maintenance, Leios delivery is at risk, alt-client diversity (Amaru, Dingo) cannot operate against a stable specification, and every other Cardano 2030 initiative funded in this round encounters compounding technical debt.

    Why SIPO votes YES

    1. Maintenance is non-discretionary infrastructure, not a discretionary investment. The nine functional areas — Node Bugfixing & Architecture, DevOps & Infrastructure (including disaster recovery per CIP-135 and bootstrap relay operations), Monitoring (mainnet and global mempool), Documentation (Cardano Blueprint), Open Source Support, Performance, Quality Assurance, Release & Support (with L1/L2/L3 incident management), and Component Maintenance (Plutus Core, DB-Sync, guardrails, API, CLI) — together constitute the support envelope without which no other Cardano 2030 initiative can ship safely. Cutting maintenance to save Treasury is the kind of false economy that compounds into operational incidents.

    2. Cardano Blueprint is the prerequisite for the node-diversity doctrine SIPO has consistently funded. The Blueprint provides implementation-independent specifications for consensus, network, ledger, and Plutus. Without it, Amaru (Rust) and Dingo (Go) — both of which SIPO has voted YES on — cannot operate against an authoritative reference. Funding maintenance without the Blueprint workstream would orphan SIPO's prior investments in alt-client diversity. The Blueprint is therefore not optional ecosystem documentation; it is structural infrastructure for node-diversity that compounds across multiple SIPO decisions.

    3. Ensurable Systems co-venture distributes platform stewardship beyond IO. Maintenance is a category where single-organization dependency is particularly dangerous: if IO maintenance capacity is interrupted, Cardano operates without a backstop. The Ensurable Systems co-venture brings a specialist team with deep protocol knowledge to share the load, distributing infrastructure stewardship across multiple organizations. This is the same Pillar 5 stewardship-distribution pattern SIPO has supported in HLabs Pebble + Gerolamo and the IO Cardano Upgrades co-venture.

    4. The continuous, non-phased deliverable structure matches the nature of maintenance work. Unlike feature proposals where milestone gating is appropriate, maintenance is by definition continuous — bugfixing cannot be deferred to a quarter boundary, monitoring must be 24/7, and release management runs on Cardano's release cadence, not the Treasury's milestone cadence. The proposal correctly frames all nine functional areas as continuous deliverables rather than imposing artificial phasing.

    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). 74% Development plus 10% Infrastructure (cloud and testnet operations) is consistent with the operational nature of this proposal — higher Infrastructure share than feature proposals because of the AWS, monitoring, and testnet costs intrinsic to maintenance.

    Expectations (YES with binding operational commitments)

    • Monthly velocity transparency per functional area: SIPO expects month-level public visibility into progress across all nine functional areas, so the community can evaluate whether each area is receiving appropriate engineering attention. Aggregating maintenance into a single top-level report would obscure the prioritization decisions being made under the hood.

    • Ensurable Systems responsibility split disclosure: The proposal frames Ensurable as a co-venture but does not publish the specific responsibility split. SIPO expects a public split published by the end of Q3 2026, including which functional areas Ensurable owns versus shares with IO.

    • Cardano Blueprint milestone-gating: The Blueprint is structural infrastructure for node-diversity. SIPO expects the Blueprint to have explicit publish milestones (consensus chapter, network chapter, ledger chapter, Plutus chapter) with each chapter's release tracked publicly, not bundled into the continuous deliverable category.

    • Leios / Peras maintenance burden prioritization transparency: The proposal acknowledges that new features delivered by other proposals (Leios, Peras) may consume more maintenance capacity than budgeted. SIPO expects transparent prioritization reports when this risk materializes — specifically, which lower-priority items (technical debt reduction, etc.) are being deferred to absorb the burden.

    • Quarterly reporting in stable format: SIPO expects the same reporting discipline already standard on Amaru, Dingo, and HLabs.

    Closing

    At ₳62.13M for nine months of continuous maintenance across nine functional areas with Ensurable Systems co-venture, this proposal is the largest line item in the round but the most foundational. Every other proposal SIPO is voting YES on in this round — Leios, IO Cardano Upgrades, Developer Experience, High Assurance, Enhancing Plutus, L2 Scalability, Blockfrost, Pogun — depends on this maintenance layer continuing to operate. Cutting maintenance to save Treasury is false economy. With expectations above treated as binding operational commitments, SIPO DRep votes YES.

    For these reasons, SIPO DRep votes YES.

    SIPO DRepとして、本提案「IO & Ensurable Systems: Cardano Maintenance Initiative」に賛成（YES）を投じます。

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

    SIPOは本提案を、本ラウンドの他の全提案が依存する基盤インフラ層として支持します。提案書自身が述べる通り「Maintenance is not a feature. It is the foundation that every feature depends on」です。₳62,134,630は本ラウンド最大の単独申請ですが、スコープは規模を正当化します — 9つの機能領域がCardanoの完全な maintenance & operational envelopeを9ヶ月（Q3 2026〜Q1 2027）連続的にカバーします。持続的なmaintenanceなしでは、Leiosデリバリーがリスクに晒され、alt-client多様性（Amaru、Dingo）は安定仕様に対して動作できず、本ラウンドで資金提供される他の全Cardano 2030イニシアチブは複利的に技術債務を抱えます。

    SIPOがYESと判断する理由

    1. Maintenanceは裁量的投資ではなく非裁量的インフラ。9つの機能領域 — Node Bugfixing & Architecture、DevOps & Infrastructure（CIP-135準拠のdisaster recoveryとbootstrap relay operations含む）、Monitoring（mainnetとglobal mempool）、Documentation（Cardano Blueprint）、Open Source Support、Performance、Quality Assurance、Release & Support（L1/L2/L3 incident management含む）、Component Maintenance（Plutus Core、DB-Sync、guardrails、API、CLI）— は組み合わさってCardanoのsupport envelopeを構成し、これなしでは他のCardano 2030イニシアチブは安全にshipできません。Treasury節約のためにmaintenanceを削減するのは、運用インシデントへ複利的に育つ偽の経済性です。

    2. Cardano BlueprintはSIPOが一貫支持してきたノード多様性ドクトリンの前提条件。Blueprintはconsensus、network、ledger、Plutusの実装非依存仕様を提供します。これなしでは、SIPOがYESを投じてきたAmaru（Rust）とDingo（Go）は権威ある参照に対して動作できません。Blueprint workstreamなしでmaintenanceに資金提供することは、SIPOのalt-client多様性への過去投資を孤児化することになります。Blueprintは任意のエコシステム文書ではなく、複数のSIPO判断にわたり複利的に効くノード多様性のための構造的インフラです。

    3. Ensurable Systems co-ventureはIOを超えてプラットフォームのstewardshipを分散する。Maintenanceは単一組織依存が特に危険なカテゴリです：IO maintenance capacityが中断された場合、Cardanoはbackstopなしで運用されます。Ensurable Systems co-ventureは深いプロトコル知識を持つ専門チームをloadシェアに導入し、インフラstewardshipを複数組織に分散します。これはSIPOがHLabs Pebble + GerolamoとIO Cardano Upgrades co-ventureで支持したPillar 5 stewardship分散パターンと同じです。

    4. Continuous（非段階型）デリバリー構造はmaintenance仕事の性質と一致。Milestone gateが適切な機能提案と異なり、maintenanceは定義上continuousです — bugfixingは四半期境界に延期できず、monitoringは24時間365日でなければならず、release managementはTreasuryのmilestoneケイデンスではなくCardanoのreleaseケイデンスで動きます。本提案は9つの機能領域全てを連続デリバリーとして正しくフレーム化し、人為的な段階化を強要しません。

    ガバナンス・監視構造はSIPOがAmaru、Dingo、HLabs Pebble + Gerolamo、DeFi Liquidity Budget、Orion Fundで承認した標準と同一です。74% Development + 10% Infrastructure（クラウドとtestnet operations）は本提案の運用的性質と整合します — 機能提案より高いInfrastructure比率は、AWS、monitoring、testnetコストがmaintenanceに固有であるためです。

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

    • 機能領域別月次velocity透明性：SIPOは9機能領域全てに対する月次レベルの公開可視性を期待します。コミュニティが各領域に適切なエンジニアリングアテンションが配分されているかを評価できるように。Maintenanceを単一トップレベル報告に集約することは、内部で行われている優先順位決定を不透明化します。

    • Ensurable Systems責任分担の開示：本提案はEnsurableをco-ventureとフレーム化していますが、具体的な責任分担を公開していません。SIPOはQ3 2026末までの公開分担を期待します — Ensurableが所有する機能領域とIOと共有する領域を含めて。

    • Cardano Blueprintマイルストーン化：Blueprintはノード多様性のための構造的インフラです。SIPOはBlueprintに明示的な公開マイルストーン（consensus章、network章、ledger章、Plutus章）を期待し、各章のリリースが連続デリバリーカテゴリにバンドルされず公開追跡されることを期待します。

    • Leios / Peras maintenance burden優先順位透明性：本提案は他提案（Leios、Peras）が予算を超えてmaintenance capacityを消費する可能性を認識しています。SIPOはこのリスクが実体化した場合の透明な優先順位報告を期待します — 具体的に、どのlow-priorityアイテム（技術債務削減等）がburden吸収のために延期されているか。

    • 安定フォーマットでの四半期報告：Amaru、Dingo、HLabsで既に標準となっている報告規律を期待。

    結び

    ₳62.13Mで9ヶ月の連続的maintenance、9機能領域、Ensurable Systems co-venture — 本提案は本ラウンド最大のline itemですが、最も基礎的です。SIPOが本ラウンドでYESを投じる他の全提案 — Leios、IO Cardano Upgrades、Developer Experience、High Assurance、Enhancing Plutus、L2 Scalability、Blockfrost、Pogun — は全て、このmaintenance層が動作し続けることに依存しています。Treasury節約のためにmaintenanceを削減することは偽の経済性です。上記期待事項が拘束力のある運用上のコミットメントとして扱われることを前提として、SIPO DRep は本提案に賛成（YES）を投じます。

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

  • Army of Spies
    No 89.3M ₳ Rationale

    I desperately want to vote yes for a proposal for maintenance of our beloved ecosystem. But, even a desperate man has limits. I am 100% for spending money on maintenance. But, the price tag has to be supported in some way. I am not yet persuaded that is the case here. Adding insult to injury, this price seems to only be for 9 months. I cannot in good conscience vote yes when I am not yet convinced the price is justified. I would happily vote yes if the cost were to be justified in a more detailed proposal or otherwise. This is not a vote against maintenance. This is a vote for a better justification of the price tag. As it stands, Jimmy McMillan put it perfectly: "The rent is too damn high!"

  • BTBF_XSP
    Yes 89.2M ₳ Rationale

    Every feature and upgrade depends on a stable, secure, well-maintained platform beneath it. Continuous maintenance across nine areas — bug fixing, security reviews, CI/CD and infrastructure, monitoring, release management, component maintenance — is non-discretionary foundational investment, not optional. The ask is the largest of the eight, but appropriately so given its nature; deferring it lets risk compound. Therefore I vote YES.

  • Dumpling🥟
    Yes 77.3M ₳ No rationale
  • drep1yg343cyuckg...
    Yes 76.1M ₳ Rationale

    Cardano needs concrete execution against known bottlenecks and known maintenance backlogs.

    A PDF version of this rationale is also made available.

    Parts of this proposal fund important operational continuity for core Cardano infrastructure, especially where resources go directly toward ledger, node, release, API, CLI, DB-Sync, Plutus, and guardrail maintenance.
    However, the current package appears too broad and mixes necessary continuity with overlapping assurance, benchmarking, documentation, and testing work that may already be covered by other proposal budgets or feature-specific engineering streams.
    Cardano needs concrete execution against known bottlenecks and known maintenance backlogs. We recommend that the proposal be trimmed, itemized, and reoriented toward tangible engineering improvements, especially low-hanging performance and ledger/node optimization work that existing teams already know needs to be done.

    We cannot afford to not fund this, as even a temporary gap in FTEs working through current core infra backlog would have cascading negative impacts, however, I truly would like to see more tangible outcomes (ie. the work should be reframed and geared towards "incremental improvements" engineering effort towards backlog tickets, instead of vague maintenance)

  • 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
    No 71.3M ₳ Rationale

    I am changing my vote to NO. Unprofessional conduct by leadership has caused brand damage and severely diminished my faith in their ability to execute. Furthermore, sweeping 62M ADA into an opaque budget is fiscally irresponsible. I cannot deploy 66.9M ADA to endorse poor governance.

    A PDF version of this rationale is also made available.

    With 67 million ADA voting power, I have decided to vote NO on the treasury withdrawal: IO & Ensurable Systems: Cardano Maintenance Initiative

    On behalf of my loyal delegates.

    I am officially changing my vote from YES to NO on the IO and Ensurable Systems: Cardano Maintenance Initiative, representing 66.94 million ADA on behalf of my loyal delegates. Initially, I intended to support this proposal to secure our operational foundation. However, upon deeper reflection, my faith in the current leadership to successfully execute a mandate of this magnitude has severely diminished. I cannot in good conscience deploy my delegates' voting power to endorse this request under its current conditions.

    Professionalism is the bedrock of decentralised governance, and I am profoundly disappointed by the recent public conduct displayed by leadership. The Cardano brand represents a mature, enterprise grade ecosystem. When individuals approach the public Treasury for tens of millions of dollars, their behaviour must absolutely reflect that maturity. The recent conduct falls drastically short, causing undeniable brand damage and directly undermining my confidence in their ability to lead and execute effectively.

    Furthermore, governance of a finite Treasury requires absolute financial accountability. Approving an opaque budget of over sixty two million ADA is fiscally irresponsible without a granular, line item breakdown. The community can no longer be expected to write blank cheques while being denied basic financial transparency, this ask is significant.

    We must hold our infrastructure stewards to the highest possible standards. Technical capability does not excuse financial opacity, nor does it excuse unprofessional conduct that damages our ecosystem's reputation. Until these fundamental standards are met, my vote remains a firm NO, I appreciate the hard work done by all of the team at IOG, and would welcome a proposal with further transparency on specific spend.

  • Martin Lang
    Abstain 70.8M ₳ No rationale
  • SASA_nagamaru_ながまる
    Yes 68M ₳ Rationale

    As a DRep, I have decided to vote YES on the proposal: “IO & Ensureable Systems: Cardano Maintenance Initiative.”

    The reason is simple: maintenance is not optional. It is the foundational layer required to sustain the Cardano network itself.

    Areas such as node maintenance, release management, security response, CI/CD, monitoring, QA, and testnet maintenance are often not highly visible. However, the moment these systems fail, the reliability and security of the entire network can be severely impacted.

    Especially as Cardano moves toward a more complex architecture with upgrades such as Leios and Peras, I believe the importance of maintenance will only continue to grow.

    At the same time, I do not consider the current structure to be ideal.

    Cardano still remains highly dependent on IO. Realistically speaking, IO currently possesses the deepest protocol knowledge and operational expertise within the ecosystem. However, from a long-term sustainability perspective, it is not desirable for maintenance capabilities and operational knowledge to remain permanently concentrated within a single organization.

    If Cardano truly aims to become a decentralized ecosystem, I believe it must not only increase the number of node implementations, but also increase the number of organizations capable of meaningfully participating in maintenance itself.

    For this reason, I view the Blueprint initiative and implementation-independent documentation as strategically important. In my view, these are not simply documentation improvements. They can become foundational infrastructure that enables alternative node implementations and external organizations to participate more actively in Cardano maintenance over time.

    I also believe collaboration with external organizations — including Ensurable Systems — as well as broader knowledge sharing and operational decentralization, should continue to expand going forward.

    Additionally, maintenance work is inherently difficult to measure because success is often defined by “problems that did not happen.” This creates a risk of maintenance becoming difficult to evaluate from the outside. For that reason, I believe stronger transparency and more detailed maintenance KPIs will become increasingly important over time.

    I support maintenance itself. However, I also believe that, in the long run, maintenance capabilities should gradually become more distributed across the ecosystem.

    My YES vote should not be interpreted as meaning that I believe the current structure is ideal. Rather, it reflects my view that this proposal is necessary for Cardano at its current stage.

    Long term, I hope to see Cardano evolve toward a more sustainable and decentralized maintenance model with reduced dependence on any single organization.

    僕はDRepとして、本提案「IO & Ensureable Systems: Cardano Maintenance Initiative」にYESで投票します。

    理由はシンプルで、maintenanceは任意ではなく、Cardanoというネットワークを維持するための基盤そのものだからです。

    Node maintenance、release management、security response、CI/CD、monitoring、QA、testnet maintenanceなどは、普段は目立ちにくい領域です。しかし、これらが機能しなくなった瞬間に、ネットワーク全体の信頼性や安全性は大きく損なわれます。

    特に今後、LeiosやPerasなどによってCardanoの構造がさらに複雑化していく中で、maintenanceの重要性は今まで以上に高まっていくと考えています。

    一方で、僕はこの提案を「理想的な形」だとは考えていません。

    現在のCardanoは、依然としてIOへの依存度が非常に高い状態にあります。現実的に見れば、現時点でIOが最も深い知識と運用能力を持つ組織であることは事実です。しかし、長期的に見れば、maintenance能力や運用知識が単一組織へ集中し続ける状態は、Cardanoの持続可能性という観点で大きな課題になり得ます。

    僕は、Cardanoが本当に分散化されたエコシステムを目指すのであれば、単にノード実装を増やすだけではなく、「maintenanceできる組織」自体を増やしていく必要があると考えています。

    その意味で、Blueprint initiative や implementation-independent documentation は非常に重要だと考えています。これらは単なるドキュメント整備ではなく、将来的にalternative node implementations や外部組織がCardano maintenanceへ参加できる土台になる可能性があります。

    また、Ensurable Systemsを含む外部組織との協力体制や、知識共有、運用ノウハウの分散化についても、今後さらに強化されるべきだと考えています。

    さらに、本提案はmaintenanceという性質上、「問題が起きなかったこと」が成果になるため、成果測定がブラックボックス化しやすい側面があります。そのため今後は、より詳細なKPIや透明性の強化も必要だと考えています。

    僕はmaintenance自体には賛成しています。しかし同時に、将来的にはmaintenance能力そのものがエコシステム全体へ分散されていく方向へ進むべきだと考えています。

    今回のYESは、「現在の構造が理想的である」という意味ではありません。現時点のCardanoにおいて必要性が高いと判断した上でのYESです。

    長期的には、Cardanoが単一組織への依存を徐々に減らしながら、より持続可能で分散化されたmaintenance体制へ移行していくことを期待しています。

  • Hermes Stakepool Germany (HRMS)
    Abstain 65.7M ₳ Rationale

    yes, maintenance is the foundation, but the amount asked for is ridiculous. therefore a heavy hearted abstain with a strong tendency towards "no"

  • Peter Bui
    Yes 62.7M ₳ No rationale
  • Dori
    Yes 53.8M ₳ Rationale

    I'm voting Yes on IOG's Consensus and Maintenance proposals.

    Network scalability and core infrastructure maintenance are not optional priorities, they are the foundation everything else in the Cardano ecosystem depends on.

    1. Leios: Sustainable L1 Throughput

    Cardano's current 10 to 15 TPS makes it structurally difficult to host products that require high transaction frequency — perpetual DEXs, on-chain games, AI agent micro-payments, enterprise-grade RWA infrastructure. Leios changes this at the protocol level, targeting a 10x to 65x throughput increase.

    The 2030 Vision of scaling from 800,000 monthly transactions to over 27 million is not achievable through L2 alone. L1 must scale, and Leios is the mechanism designed to get there. The multi-vendor consortium and the fail-safe fallback to Praos make this an ambitious but disciplined upgrade.

    1. Maintenance: The Layer Everything Depends On

    Every stake pool, every dApp, every transaction runs on what this work delivers. By the end of 2026, stewardship of Cardano's Haskell engineering capability is set to move to a dedicated entity exactly the kind of structural decentralization the ecosystem has been asking for, and it has to be funded through to completion.

    Consensus and Maintenance are also inseparable. Leios specifications come from the Consensus workstream, but integration into the node and long-term stability depend on Maintenance.

    Strong tech at the protocol layer only really pays off when it's tested properly and kept up over time. Leios is a pretty ambitious upgrade, and that means it needs to be delivered carefully, not rushed. I'm voting Yes because both proposals have milestone-based funding, a multi-vendor delivery setup, and a clear handoff plan in place.

  • Goofycrisp
    Yes 51.1M ₳ Rationale

    Cardano’s core maintenance is foundational to the stability, security, and continuity of the network. While ongoing maintenance funding should be watched carefully as more node teams come online, IO currently remains essential to this work. Given the importance of maintaining the core infrastructure that the ecosystem depends on, I believe this proposal should be supported.

  • Chris-O
    Yes 50.5M ₳ No rationale
  • AdaStat
    Yes 49.8M ₳ Rationale

    Despite the relatively large amount being requested, there is currently no alternative proposal available. So I'm voting Yes, since maintenance is necessary.

  • hix_coffeepool
    Abstain 49.7M ₳ Rationale

    I am abstaining on "IO & Ensurable Systems: Cardano Maintenance Initiative (Q3 2026 – Q1 2027)". Core Cardano maintenance — covering bug fixes, CI/CD, release management, Plutus Core upkeep, security reviews, and QA — is Tier 2a non-discretionary infrastructure work essential to network continuity. The nine functional areas in this proposal constitute comprehensive coverage of core maintenance responsibilities, and the accountability structures are strong: Intersect milestone management, 3rd-party assurance, and unspent fund refund conditions are all in place. The Cardano Blueprint deliverable adds further value by reducing barriers to alternative client implementations. However, ₳62M for a single 9-month proposal is the largest ask in this review cycle, and combined with Leios and CIP-159 already receiving Yes votes, NCL concentration from a single proposer is a significant concern under current market conditions. Abstaining acknowledges the genuine necessity of the work while flagging the scale and concentration risk, and does not imply opposition to the maintenance function itself. Reference: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem/ [Japanese version follows] 私は、「IO & Ensurable Systems: Cardano Maintenance Initiative（Q3 2026〜Q1 2027）」に棄権票を投じます。コアメンテナンス（バグ修正・CI/CD・リリース管理・Plutus Core保守・セキュリティレビュー・QA）はカルダノネットワーク運用に不可欠な非裁量作業です。9つの機能領域はコアメンテナンスの包括的カバレッジを構成しており、説明責任体制も整っています。Intersectのマイルストーン管理・第三者保証・未使用資金返還条件が揃っており、Cardano Blueprintの成果物はオルタナティブクライアント実装の参入障壁を下げる追加価値もあります。しかし₳62Mは9ヶ月の単一提案として今回の審査サイクル最大の請求額であり、Leios・CIP-159がすでにYES票を受けている状況での単一提案者へのNCL集中リスクは、現在の市場状況下では看過できない懸念事項です。棄権はメンテナンス業務そのものへの反対を意味するものではなく、規模と集中リスクへの懸念を示すものです。参照: https://coffeepool.jp/notes/drep-voting-framework-for-sustainable-ecosystem-jp/

  • drep1ytjz60rgwhk...
    Abstain 42.9M ₳ No rationale
  • PoolTool
    No 42.4M ₳ No rationale
  • drep1ygm9wxzrrdq...
    Yes 40M ₳ Rationale

    I feel unable to assess this proposal fairly. The amount is very high and seems unreasonable. But it seems to me that it's necessary so that development on Cardano doesn't halt completely.

  • drep1yffcjs0njfe...
    Yes 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 proposal funds Cardano's core maintenance and operational support from Q3 2026 through Q1 2027 — a 62,134,630 ADA withdrawal covering nine functional areas, from bug fixing and security review to infrastructure operations, mainnet monitoring, release management, and component maintenance across Plutus Core, DB-Sync, the APIs, and CLI tools.

    Maintenance is the easiest line item to underfund and the most expensive to neglect. Every feature, upgrade, and scaling initiative on Cardano's roadmap depends on a stable platform beneath it; withholding this support would not save money, it would convert deferred maintenance into outages, security exposure, and slower delivery elsewhere. The proposal also funds the Cardano Blueprint — implementation-independent specifications that lower the barrier for alternative node implementations — which is structurally good for decentralisation.

    The ask is large, and Socious does not treat that lightly. Two things make the Yes clear: the work is genuinely non-discretionary, and Intersect administers the funds through milestone-based smart contracts with independent assurance, returning any unspent balance to the Treasury. Socious will track delivery against the published on-chain dashboards.

    ソーシャスは本提案に賛成します。本提案は、2026年第3四半期から2027年第1四半期にかけてのCardanoのコア保守と運用支援に充てるもので、62,134,630 ADAの引き出しを求めています。対象は、不具合修正やセキュリティレビューからインフラ運用、メインネット監視、リリース管理、そしてPlutus Core・DB-Sync・各種API・CLIツールのコンポーネント保守まで、九つの機能領域に及びます。

    保守は予算の中で最も削られやすく、そして怠ったときの代償が最も大きい項目です。Cardanoのロードマップにある新機能・アップグレード・スケーリングは、いずれも安定した土台があって初めて成立します。ここで支援を絞っても費用が浮くわけではなく、先送りした保守が障害やセキュリティリスク、他領域での開発の遅れとなって表れるだけです。本提案はCardano Blueprint（実装に依存しない仕様策定）にも資金を充てており、代替ノード実装の参入障壁を下げる点で分散化にも資します。

    要求額は大きく、ソーシャスもそれを軽視しません。それでも賛成の判断は明確です。第一に、この作業は裁量の余地がない必須の保守であること。第二に、資金はIntersectがマイルストーン連動のスマートコントラクトと独立した検証のもとで管理し、未使用分はトレジャリーへ返還されることです。ソーシャスは、公開されるオンチェーンのダッシュボードで進捗を確認していきます。

  • drep1yf2jzhuc4f7...
    Yes 32.3M ₳ Rationale

    Yes. ₳62.1M for 9 months of continuous Cardano platform maintenance (Q3 2026 - Q1 2027): node, DevOps, monitoring, performance, QA, release, component upkeep. IO + Ensurable Systems consortium, Intersect milestone-administered. Foundational L1 work every other slate action depends on.

    A PDF version of this rationale is also made available.

    Vote: Yes

    ₳62.1M for continuous Cardano platform maintenance from Q3 2026 to Q1 2027, covering nine functional areas: node bugfixing and architecture, DevOps and infrastructure (including CIP-135 disaster recovery), mainnet and mempool monitoring, the Cardano Blueprint specification project, open-source community support, performance optimization, quality assurance, release management with L1/L2/L3 incident response, and component upkeep across Plutus Core, DB-Sync, guardrails scripts, APIs, and CLI tools.

    This is the foundation that every other proposal in the IO slate depends on. If the underlying platform is not maintained, nothing else ships cleanly. The HOSKY Cardano First framework reads strongly across multiple pillars.

    Pillar Analysis

    Decentralization (lead pillar)

    The work is structured as an IO + Ensurable Systems collaboration, the same distributed-stewardship shape as the Plutus + VacuumLabs co-venture elsewhere in this slate. Ensurable Systems is a specialist infrastructure firm contributing alongside IO rather than IO carrying the maintenance load alone.

    The Cardano Blueprint deliverable is the standout Decentralization artifact: implementation-independent specifications across consensus, network, ledger, and Plutus that lower the barrier for alternative node implementations. Direct enabler for Amaru, Dingo, Pebble + Gerolamo, and any future client. Same logic as my Yes on each of those.

    Adoption

    L1/L2/L3 incident response, mainnet and mempool monitoring with public data publication, GitHub triage and external contribution review, multi-testnet maintenance for DApp developers to validate against. The maintenance layer is invisible when it works and devastating when it does not. Reliable platform operation is what lets DApp builders and SPOs commit to Cardano as production-grade infrastructure.

    Scalability

    The Performance workstream covers systematic ledger optimization, system-level node optimizations (block production, diffusion, timeliness), benchmarking at integration level to safeguard releases and hard forks, and continuous improvement of the node's tracing, logging, and metrics. These are the throughput levers that compound across every transaction on Cardano, independent of any single feature ship. Direct safeguard for the Leios path of release.

    Governance Transparency

    Standard Intersect 2025 TRSC pattern: milestone-based smart-contract disbursement, independent third-party Assurer, transparent on-chain dashboards, unspent funds return to Treasury. Same shape as Pebble + Gerolamo, Dingo, Amaru, and the Plutus collaboration.

    Continuation precedent: HOSKY voted Yes on the 2025 Input Output Engineering Core Development proposal in July 2025. This proposal is the 2026 equivalent under a new co-stewardship structure with Ensurable Systems. The pattern is consistent with how core platform maintenance gets funded: continuously, annually, not as a one-time spend.

    Risks I'm Accepting With This Yes

    Largest single line item in the IO slate

    ₳62.1M is the biggest individual ask in the seven-proposal IO slate. The cost breakdown by collaborator (IO vs Ensurable Systems) is not provided in the proposal. Implicit trust that Intersect's third-party Assurer catches mispricing or scope-creep at the milestone level.

    Continuous deliverables, weaker milestone gating

    The proposal explicitly states there is no sequential phasing or quarterly gating: maintenance activities are ongoing and parallel. That is honest about how maintenance actually works, but it reduces the leverage Intersect milestone-gating provides. Gating is per-functional-area rather than per-deliverable.

    Scope overlap with sibling IO actions

    Plutus Core interpreter maintenance, DB-Sync consistency, and High Assurance tool maintenance appear here and also in the Plutus, High Assurance, and Upgrades proposals. The boundary is not perfectly clean. The mitigation is that Intersect-administered milestone smart contracts settle the boundary at execution time, not at vote time.

    Ensurable Systems portion not quantified

    The proposal asserts an IO + Ensurable Systems consortium but does not specify what fraction of the work or budget Ensurable owns. Same observation as the VacuumLabs partnership in the Plutus proposal. Structural shape is right; specifics are loose.

    Self-reported impact metrics

    Reliability uptime, performance gains, and alternative-node-implementation enablement claims are proposer-stated. The structural deliverables (Cardano Blueprint, CI/CD, monitoring infrastructure, release process, component upkeep) are independently verifiable; downstream impact claims will need community measurement.

    Slate aggregation

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

    Bottom Line

    The platform underneath every other initiative in the slate. Without continuous maintenance, none of the feature work in Consensus, Plutus, High Assurance, Upgrades, or Developer Experience lands cleanly. Yes.

  • Liqwid DAO
    Yes 31.3M ₳ No rationale
  • drep1y2xacakh0g8...
    Yes 31M ₳ Rationale

    Although I still have significant concerns about the proposal’s broad scope, cost, and the limited clarity around prioritization, I ultimately decided to support it after considering Cardano’s long‑term stability and the importance of maintaining reliable core infrastructure.

  • drep1ygxeadaklzz...
    Yes 30.5M ₳ No rationale
  • FIMI
    Yes 29.3M ₳ No rationale
  • Cerkoryn
    Yes 28.2M ₳ Rationale

    Until we have alternate nodes available with sufficient stake, then maintaining our one-and-only Haskell node has to be the top priority for funding.

  • Drep One
    Yes 27.9M ₳ No rationale
  • TERA DRep
    Yes 27.4M ₳ No rationale
  • Blockjock (James Meidinger)
    Yes 26.1M ₳ Rationale

    Rationale — Cardano Core Maintenance
    Header

    You cannot build a high-performance system on an unstable base. But core maintenance still requires clear accountability.

    Constitutional Gate

    Assessment: Conditional Pass

    The proposal supports ecosystem sustainability, continuity, security, and reliability. It covers essential operational responsibilities including node stability, bug fixing, DevOps, monitoring, incident response, documentation, release management, and QA.

    The concern is structure. This is a continuous spend model, not a clean milestone-based delivery model, which makes output, efficiency, and value harder to measure.

    Decision Declaration

    Vote: YES — Necessary, with ongoing scrutiny required.

    This is required to keep Cardano operational, but it creates a precedent that must be tightly monitored.

    Core Rationale

    Every other treasury-funded initiative depends on the base network functioning properly. Core maintenance is not a growth proposal by itself. It is continuity infrastructure.

    The proposal helps preserve uptime, security, release quality, developer confidence, and user trust. Without that foundation, higher-level infrastructure, DeFi, governance, and enterprise adoption are all weakened.

    Strategic Alignment

    The proposal aligns with network uptime, reliability, security, and ecosystem continuity.

    It enables the rest of the roadmap to function, but should be understood as base-layer maintenance rather than direct growth investment.

    Economic Impact

    The economic value is defensive.

    It helps prevent downtime, security incidents, broken releases, and loss of trust. It also supports consistent transaction flow and developer confidence.

    The limitation is that it does not directly generate revenue, increase TVL, or create a new market. This is cost-center infrastructure.

    Execution Risk

    The main risk is that the treasury becomes a recurring operational backstop without enough competitive pressure or measurable performance standards.

    Additional risks include cost creep, weak benchmarking, and reduced incentive to optimize internal operations over time.

    These risks are partly mitigated by Intersect oversight, public reporting, third-party assurance, and the possibility of future competitive maintenance providers.

    Accountability

    The proposal includes oversight, reporting, governance structure, third-party assurance, and on-chain tracking.

    The weakness is that continuous maintenance is harder to evaluate than milestone-based delivery. Future reporting should clearly measure uptime, performance, incident response, release quality, and cost efficiency.

    Stablecoin Utilization

    The proposal does not appear to include a stablecoin conversion strategy for the operational budget.

    That is a meaningful weakness given the size of the request. A large maintenance allocation should not depend on ADA maintaining a favorable price throughout the delivery period.

    The proposer should consider stablecoin hedging or staged conversion to protect staffing, infrastructure, DevOps, QA, and incident response budgets.

    The treasury disbursement process should also support budget smoothing where predictable purchasing power is required. Hoping a volatile asset remains at a certain price is not a treasury strategy.

    End-User Lens

    For builders, this means a stable environment to deploy and maintain applications.

    For users, this means the network stays online, apps continue to work, and transactions remain reliable.

    For capital providers, it preserves confidence that core infrastructure will not fail.

    Conditions to Change Vote

    This rationale would materially change if reporting lacks transparency, measurable performance does not improve, incident response weakens, costs continue rising without justification, or viable competitive maintenance providers emerge and are not considered.

  • drep1yguh6dsgx0g...
    No 25.9M ₳ Rationale

    After reflecting on the issues raised and engaging extensively with the Cardano community in recent discussions (reference: https://x.com/sachs_johnny/status/2057466309625962756), I have decided to change my vote to NO. In my view, it is important that Cardano continues to strengthen its operational resilience and reduce potential concentration risks.

    Maintenance activities are undoubtedly critical, and I would be prepared to support a revised proposal from IO that provides greater transparency regarding the scope of work being performed. Such a proposal should also include a clear strategy for knowledge transfer and capability building, enabling other teams within the ecosystem to progressively acquire the expertise required to perform these maintenance activities.

    In addition, greater visibility into the effort, costs, and roles of subcontractors would allow the community to better assess which activities could potentially be contracted directly in the future. Under such a model, IO could continue to serve as the prime contractor, providing oversight, prioritization, coordination, and quality assurance across the various workstreams.

    Looking ahead, an ideal outcome would be that by Q4 2026 or Q1 2027, Cardano is in a position to open at least part of the maintenance work to a competitive bidding process among multiple qualified teams. This would strengthen resilience, foster ecosystem growth, and further advance Cardano’s decentralization objectives.

  • Kyle Solomon
    Abstain 25.2M ₳ No rationale
  • wolf31o2 (Chris Gianelloni)
    Yes 22.7M ₳ Rationale

    Ongoing maintenance, especially for systems like IO's performance testing cluster and fleet of Cardano nodes used as bootstrap peers, is vital to the ability for the network to operate smoothly. While the price may seem high, this includes software and systems which help all node developers and operators. Dingo can be built at a low cost because IO does this work. It's the least sexy work, but the most important for a healthy network.

  • 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