IO & Ensurable Systems: Cardano Maintenance Initiative
239 DReps voted · 78 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 a stake pool operator, I definitely want the Cardano platform to remain stable, performant, and secure with predictable release cycles, so that I can rely on it as a production-grade foundation for my operations and applications.
The Cardano Blueprint delivery will also be very useful for our alternative nodes to follow. - Yes 17.1M ₳ Rationale
IO & Ensurable Systems: Cardano Maintenance Initiative
- Abstain 16.7M ₳ Rationale
I’m voting ABSTAIN because maintenance is clearly important, but approving ₳62,134,630 on the current level of transparency risks normalizing a treasury “operating backstop” without sufficient cost traceability, benchmarking, or measurable performance gates. The proposal provides a broad scope and high-level budget distribution, but for an ask of this magnitude, I expect component-level costing (what portion is node maintenance vs other functions), explicit team size/FTE allocations, and rate assumptions, and acceptance evidence that makes a continuous spend model governable. Without that, it becomes difficult to compare costs over time, especially as Cardano moves into a multi-client world where maintenance responsibility and funding will need to be distributed and benchmarked across teams. As a governance principle, I don’t want treasury-funded maintenance to become an open-ended model that reduces incentive to optimize; the ask must be structured to allow cost and performance scrutiny. 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 & Ensurable Systems: Cardano Maintenance Initiative Treasury Withdrawal proposal.
We support this proposal because Cardano’s core maintenance is essential infrastructure. Every feature, upgrade, DApp, wallet, stake pool, governance process, and future scaling initiative depends on a stable, secure, well-maintained base layer. Maintenance is not a discretionary luxury; it is the operational foundation that allows Cardano to remain reliable as a production blockchain.
RCADA recognises that IO has carried a significant share of Cardano’s core maintenance responsibility to date and has done so with a strong overall record. Cardano’s stability, release discipline, security posture, and continued protocol evolution have benefited from IO’s institutional knowledge and technical depth. At this stage, there is no practical or sensible path to simply remove that expertise from the maintenance envelope without creating unnecessary continuity risk.
However, RCADA does not believe the long-term objective should be to replace IO with another single dominant maintenance provider. Cardano should avoid recreating single-provider dependency, whether that provider is IO or any future organisation. The healthier path is progressive multi-party stewardship, where IO continues to contribute its deep protocol expertise while more responsibilities are opened, where practical and safe, to capable ecosystem contributors, independent engineering groups, alternative client teams, SPOs, auditors, open-source organisations, and neutral coordination structures.
We therefore view the collaboration with Ensurable Systems as a positive step, not because it replaces IO, but because it points toward a broader and more resilient maintenance model. Cardano’s long-term infrastructure health will be strengthened when knowledge, responsibility, tooling, monitoring, documentation, and operational capability are distributed across a wider bench of competent contributors.
The proposal covers a wide and important maintenance envelope, including node bug fixing, DevOps and CI/CD infrastructure, disaster recovery, mainnet and mempool monitoring, documentation, open-source support, performance optimisation, QA, release management, incident response, Plutus Core, DB-Sync, guardrails scripts, APIs, CLI tools, and related components. These are not glamorous workstreams, but they are critical to keeping Cardano safe, usable, and dependable.
RCADA also sees value in the proposal’s focus on the Cardano Blueprint and implementation-independent documentation. In our view, documentation should be treated as a serious maintenance deliverable, not a secondary activity. Cardano’s technical documentation remains fragmented across repositories, specifications, guides, and community-maintained resources. We would welcome a more coherent and accessible documentation layer covering network architecture, node setup, configuration, operational practices, core technologies, and implementation-independent specifications. Better documentation would benefit SPOs, developers, auditors, alternative client teams, and new contributors.
That said, our YES vote should not be read as a blank cheque.
This proposal requests ₳62,134,630, which is a substantial Treasury allocation. Large recurring maintenance budgets must meet a high standard of public transparency, cost justification, measurable delivery, and independent assurance. While the proposal includes budget categories, refund provisions, smart-contract administration, third-party assurance, prior Treasury receipt disclosure, and Net Change Limit compliance, RCADA agrees with the broader community concern that future maintenance proposals should provide clearer line-item detail, staffing assumptions, workstream-level cost attribution, and measurable public reporting.
We are also wary of Treasury-funded maintenance becoming an opaque mechanism for underwriting ongoing employment under a broad maintenance umbrella. Maintenance work is essential, and the people performing it should be fairly compensated, but recurring public funding must remain tied to clear outputs, visible service levels, delivery evidence, and ecosystem benefit. The community should be able to understand not only that maintenance is needed, but what is being maintained, by whom, at what cost, and with what measurable results.
RCADA would therefore like to see future maintenance reporting include clearer evidence around uptime, incident response, release cadence, security reviews, unresolved critical issues, test coverage, performance benchmarks, documentation progress, open-source contribution handling, and progress toward broader multi-party participation. Continuous maintenance does not remove the need for measurable accountability.
We also recognise the concerns raised by other DReps and community members around proposal size, budget granularity, potential overlap with other IO-led initiatives, and concentration of Treasury funding. The Cardano Foundation’s abstention, for example, highlights legitimate questions about financial detail, potential duplication, quantifiable deliverables, and the need for a more modular and node-agnostic maintenance approach. These concerns are valid and should influence how future maintenance proposals are structured.
Nevertheless, RCADA believes that rejecting this proposal outright would create more risk than benefit at this stage. Cardano needs uninterrupted maintenance coverage. The operational scope is real, the expertise required is significant, and the network should not be placed in a position where essential maintenance becomes uncertain while alternative structures are still maturing.
For these reasons, RCADA votes YES, while strongly emphasising that future maintenance funding should become more transparent, more measurable, more modular where practical, and more explicitly oriented toward distributed stewardship. Cardano should continue funding the maintenance it depends on, but it should also use that funding to widen participation, improve documentation, strengthen public accountability, and reduce long-term dependency on any single organisation.
RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/."
- No 12.2M ₳ Rationale
IO received substantial treasury funding in the previous funding cycle, yet many of the promised deliverables remain either incomplete, insufficiently demonstrated, or difficult for the community to independently verify. Against that backdrop, this proposal’s request for ₳62.1M purely for maintenance and operational continuity appears disproportionately expensive in our view.
While we acknowledge that maintenance of Cardano’s core infrastructure is essential, the proposal lacks the level of cost transparency and measurable accountability expected for a treasury request of this magnitude. Critical details such as team composition, resource allocation by workstream, infrastructure cost breakdowns, delivery benchmarks, and clear performance-based accountability mechanisms are too broadly defined to properly assess value for money.
Additionally, many of the proposed outcomes are framed as indirect ecosystem benefits rather than measurable deliverables with objectively verifiable success criteria. This makes it difficult for DReps and the wider community to determine whether the requested funding is justified, cost-efficient, or aligned with the ecosystem’s long-term decentralization and sustainability goals.
As Wada DRep, we recognize the importance of maintaining Cardano’s reliability, security, and operational resilience. However, given the concerns around prior delivery performance, insufficient financial granularity, and the scale of the treasury ask relative to the specificity of the proposal, we are unable to support this funding request in its current form.
- Yes 11M ₳ No rationale
- Yes 10.8M ₳ No rationale
- No 10.5M ₳ Rationale
The issue is that this proposal asks for ₳62,134,630 over roughly 9 months, while giving the community broad scope categories but no public line by line cost breakdown for those categories. The proposal lists nine functional areas but it does not show how much is being spent on bugfixing vs monitoring vs documentation vs release/security vs component maintenance. For a proposal of this size, that is not good enough.
The proposal's main argument is that "every proposal in this portfolio depends on one thing: a stable, reliable, operational Cardano network." That is directionally true. Security, incident response, release engineering and test infrastructure are real dependencies for other proposals. But that argument can also be used to justify almost anything if it is not tightly constrained.
Because other proposals already include their own readiness, integration, validation or ecosystem support work. For example:
the Consensus/Leios proposal includes conformance testing, load testing, adversarial validation, stable client interfaces, tactical support for DB-Sync, Mithril, and Blockfrost, workshops, and hard-fork-enabling work.
the Developer Experience proposal includes documentation, onboarding, outreach, reactive ecosystem work, and portal improvements.
the Blockfrost proposal includes 24/7 incident response, ongoing maintenance, developer support, and infrastructure costs for the free tier.
So when the maintenance proposal also includes documentation, monitoring, release support, component upkeep, open source support, performance, QA, and incident management, it becomes very reasonable to ask - WHERE exactly does maintenance stop and other proposal scope begin?
There is BIG overlap RISK.
That is why I raised the Cardano Blueprint point. If maintenance is paying for Blueprint/documentation related work while there is also a separate documentation developer experience proposal, that starts to look like possible double dipping. And that is exactly the kind of thing voters are supposed to scrutinize.
A maintenance proposal should not become a catch-all bucket where adjacent workstreams get absorbed under the logic that "the network needs everything." That is not disciplined budgeting.
There is also a broader governance issue here.
IOG said it wanted dReps to ask questions. Fine. But when people show up with harder questions - especially around expenditure, FTEs, overlap and accountability - those questions should actually be addressed directly. Instead, they have thrown their own narratives without questions being allowed.
Another issue is that the proposal is structured as continuous support work, not sharply defined milestone based delivery. That makes some sense for maintenance but it also makes accountability harder. If the work is always ongoing, always essential and always broad, then it becomes much harder for the community to measure whether the cost is proportionate. And the cost is NOT small.
At the proposal's own reference rate, this is roughly $14.9 million USD for about 9 months of work. How many FTEs?
That is one of the most basic questions for a proposal of this size. Instead, one of the explanations given was essentially that long running systems accumulate technical debt and that some percentage of that naturally goes into maintenance/support, around 30-40%. I do not think that is the right way to look at it. If the product has 12 million $ADA in revenue, the technical debt shouldn't be more the 5x the revenue.
This proposal is too broad, too expensive, too aggregated and not transparent enough for the amount being requested.
This is why I voted NO
- No 9.6M ₳ No rationale
- Yes 8.8M ₳ Rationale
私はこの提案に賛成します。Cardanoの成長と安定性を支えるためには、新機能開発だけでなく、保守と運用基盤の維持が不可欠だと考えています。特に、Node保守、セキュリティレビュー、障害対応、監視、リリース管理、テストネット維持などは、ネットワークを安全かつ安定的に運用し続けるために重要です。また、LeiosやPerasのような今後の大型アップグレードを安全に導入していくためにも、基盤保守への投資は必要だと考えています。Cardanoの将来的な拡張性と信頼性を支えるうえでも、本提案は重要な取り組みだと考え、支持します。\n\nI support this proposal. To support Cardano’s growth and stability, I believe it is essential not only to develop new features, but also to maintain and sustain its operational infrastructure. In particular, node maintenance, security reviews, incident response, monitoring, release management, and testnet maintenance are all important for operating the network safely and reliably. I also believe that continued investment in infrastructure maintenance is necessary to safely introduce future major upgrades such as Leios and Peras. From the perspective of supporting Cardano’s long-term scalability and reliability, I believe this proposal is an important initiative and therefore support it.
- Yes 8.1M ₳ No rationale
- Yes 7.8M ₳ No rationale
- No 7.8M ₳ No rationale
- Yes 7.3M ₳ No rationale
- Yes 7.3M ₳ No rationale
- No 7.1M ₳ Rationale
NO, with path to YES
IO is requesting ₳62.1m from the Treasury for nine months of maintenance of the primary Cardano node implementation. Effectively, this is around $20m in annualised costs. I cannot justify approving this level of maintenance cost based on the detail currently given in the proposal.
I am voting NO on this proposal (there is a path to YES if it hinges on my vote), not because Cardano maintenance is optional. It clearly is not. The node, releases, security, testnets, monitoring and related infrastructure all need serious support.
My issue is that a ₳62.1m request for nine months is too large to approve without a clearer cost breakdown. I would want to see more detail on team size, rates, infrastructure costs, security and audit costs, overhead, and what is actually being delivered under each workstream. At the moment, too much is bundled together.
After almost a decade of Cardano being live, some ecosystem-facing services should gradually become more modular and open to competitive bidding. This proposal is not only about maintaining IO’s node implementation. It includes work that benefits the whole ecosystem, such as mainnet and mempool monitoring, testnet maintenance, disaster recovery, security support, Cardano Blueprint documentation, conformance testing, DB-Sync, API/CLI maintenance and support for future alternative node implementations. These are shared ecosystem costs, not just IO delivery costs.
That is why I think some of these ecosystem-facing parts should be separated more clearly and, where appropriate, co-funded by the Cardano Foundation. If they are properly scoped, other qualified teams could also bid for some of this work in future cycles. That would reduce dependence on one provider, improve accountability and give the treasury better price discovery.
Core maintenance should be funded, but not as a blank cheque. I would be much more comfortable with a revised proposal that has a clearer budget, clearer milestones, and more visible coordination between IO, relevant Intersect technical and assurance experts, and the Cardano Foundation. There should also be a clearer path for possible co-funding of ecosystem-facing parts. It is time to create a path for some of these bundled services to become less dependent on one provider over time.
I would vote YES, if the proposal is resubmitted with consideration given to the points above. - Abstain 6.2M ₳ Rationale
- 전체 금액에 대한 price breakdown이 보다 필요하다 판단됨
- Yes 6M ₳ Rationale
I am voting Yes.
Simply put, this is necessary to keep Cardano functioning as expected. While it doesn’t move the ecosystem forward on its own, nothing else meaningfully works without it.
Support here should not remove the need for ongoing scrutiny around cost, efficiency, and long-term decentralization of these responsibilities, but at a base level, this is a requirement.
- Yes 5.5M ₳ No rationale
- Yes 5.5M ₳ No rationale
- Yes 5.3M ₳ Rationale
Voting YES. Maintenance is non-discretionary infrastructure work - every other proposal in this batch and every future feature on Cardano depends on a stable, secure, well-maintained platform underneath. The nine-area scope (bug fixing, DevOps, monitoring, Cardano Blueprint documentation, open-source support, performance, QA, release management, component maintenance) is the complete support envelope, not a wish list. The Ensurable Systems collaboration begins distributing infrastructure stewardship away from sole IO custody, consistent with the Cardano 2030 distributed-ownership direction.
The treasury safeguards are the same gold-standard Sundae Labs framework as the rest of the batch: TRSC/PSSC architecture, five-entity Oversight Committee, third-party milestone assurance, proportional refund of unspent funds, NCL compliance. The ₳62.1M ask is large but proportionate when assessed against scope (nine functional areas, nine months, full-stack node infrastructure) and against IO's prior maintenance receipts disclosed in the proposal.One substantive caveat: the deliverables section lists everything as "continuous" with no quarterly gating, which is operationally honest for maintenance work but reduces the natural milestone checkpoints that protect treasury funds on smaller technical proposals. The third-party assurer function and the public dashboard are doing more of the accountability work here than on time-boxed deliverables, so DRep and community vigilance on the dashboard reporting cadence will matter more for this proposal than most.
Peter Horsfall - Independent DRep, Oceania.
- Yes 5.3M ₳ Rationale
STORM Partners votes YES on the IO & Ensurable Systems Cardano Maintenance Initiative.
This is a large ask and creates real pressure on the Net Change Limit. That should not be ignored. However, core maintenance is not optional for a production blockchain. Every user, SPO, developer, and future protocol upgrade depends on reliable releases, bug fixing, security, monitoring, and operational continuity.
We support this proposal because the cost of under-maintaining the core platform would be higher than the cost of funding it. That said, the size of the request raises the reporting bar. We expect clear public updates, strong accountability on delivery, and disciplined handling of unused funds. - Yes 4.8M ₳ No rationale
- Yes 4.8M ₳ No rationale
- Yes 4.5M ₳ No rationale
- Yes 4.4M ₳ No rationale
- Yes 4.2M ₳ Rationale
[Portuguese]
Optamos por votar "SIM" nesta ação de governança "IO & Ensurable Systems: Cardano Maintenance Initiative" (gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3qx4njfhm), pois entendemos que a manutenção contínua da Cardano é essencial para garantir estabilidade, segurança, previsibilidade de releases e suporte operacional à rede. Embora o valor solicitado, de ₳62.134.630, seja significativo, ele cobre áreas críticas como correções de bugs, infraestrutura, monitoramento, QA, segurança, suporte a incidentes, documentação técnica e manutenção de componentes centrais — entregas que sustentam todo o ecossistema e tornam o custo-benefício do orçamento justificável. Também pesou a favor o fato de a proposta prever mecanismos de controle e transparência, como marcos de entrega, aceite por terceiro independente, administração pela Intersect, uso de smart contracts, dashboards públicos/on-chain, relatórios à comunidade e devolução de valores não utilizados ao Tesouro. Ainda que os entregáveis sejam contínuos e não estejam organizados em metas trimestrais rígidas, há áreas funcionais e KPIs suficientes para acompanhar o progresso, desde que a comunidade cobre relatórios periódicos claros sobre execução, qualidade e impacto.
[English]
We chose to vote "YES" on this governance action "IO & Ensurable Systems: Cardano Maintenance Initiative" (gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3qx4njfhm), because we understand that continuous Cardano maintenance is essential to ensure stability, security, release predictability, and operational support for the network. Although the requested amount of ₳62,134,630 is significant, it covers critical areas such as bug fixes, infrastructure, monitoring, QA, security, incident support, technical documentation, and maintenance of core components — deliverables that support the entire ecosystem and make the budget’s cost-benefit ratio justifiable. We also view favorably that the proposal includes control and transparency mechanisms, such as delivery milestones, acceptance by an independent third party, administration by Intersect, use of smart contracts, public/on-chain dashboards, community reporting, and the return of unused funds to the Treasury. While the deliverables are continuous and not organized into rigid quarterly targets, there are sufficient functional areas and KPIs to track progress, provided that the community demands clear periodic reports on execution, quality, and impact. - Yes 4.2M ₳ No rationale
- Yes 4M ₳ No rationale
- Yes 3.8M ₳ Rationale
Critical maintenance function, but marred by incorrect and short term procurement and vendor management process.
A PDF version of this rationale is also made available.
This proposal is for necessary maintenance and operational continuity work for the core Cardano ecosystem and is clearly treasury appropriate in principle. Maintenance of core infrastructure is a legitimate public good and cannot realistically be left to uncertain volunteer coordination or purely market-driven incentives. If the ecosystem expects reliability, security, and operational continuity, then ongoing maintenance funding is unavoidable.
I also believe the timing is appropriate. This is not optional future-facing work or speculative expansion. Maintenance is required for the system to continue functioning safely and reliably. Governance systems that underfund maintenance while prioritizing only visible innovation eventually accumulate systemic fragility and operational debt.
The underlying work itself appears legitimate and necessary.
My concerns are primarily structural and governance-related.
The current treasury process is poorly suited for evaluating and negotiating operational maintenance contracts of this nature. DReps are effectively being asked to approve or reject critical maintenance funding packages without having the institutional mechanisms, procurement tooling, or negotiation authority necessary to properly challenge assumptions, pricing, staffing allocation, or operational scope. In practice, this creates a dynamic where the treasury is partially held hostage by the necessity of the work itself.
I am particularly concerned that there appears to be insufficient independent line-item scrutiny and vendor negotiation before proposals reach the voting stage. Core maintenance proposals should ideally pass through some form of qualified operational or procurement review structure capable of challenging costs, validating assumptions, benchmarking rates, and negotiating on behalf of the ecosystem before escalation to governance voting.
The referenced analysis suggesting that a significant portion of the budget is Cardano-specific overhead also raises legitimate questions around allocation methodology and potential padding that should receive deeper scrutiny. Even if the work is necessary, governance should not normalize weak financial transparency or assume that all quoted operational costs are automatically efficient simply because the work is critical.
More importantly, this proposal highlights a structural weakness in the current treasury model. Direct DRep voting is not optimized or appropriate for operational procurement oversight at this level of complexity and necessity. Cardano immediately needs mature intermediary governance and procurement structures capable of handling maintenance contracting, vendor management, and financial review with greater rigor.
Despite these concerns, I believe the maintenance work itself is essential, treasury appropriate, and necessary for ecosystem continuity, which leads me to support the proposal while signaling serious reservations about the current procurement and governance process surrounding these types of operational funding requests.
- Yes 3.7M ₳ Rationale
I approve IOG’s proposal for the ongoing maintenance of Cardano Core, in collaboration with Ensurable Systems. Cardano has successfully withstood numerous attacks in the past, demonstrating strong resilience and we must continue investing in its security to ensure it remains robust and unhackable in the face of evolving threats.
==========================================
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
- No 2.8M ₳ Rationale
I have to vote NO on this proposal in its current form. I am all for continuing to maintain Cardano, but there are no clear details of what exactly we are getting that costs 62 Million ADA. This cost is exorbitantly high for only maintaining existing tooling, and seems more like a proposal to fund IOG’s overall operations for 9 months. This also means that IOG’s entire operational structure is too expensive to continue like it is if Cardano is the only source of revenue for this company.
When current annual treasury revenue only amounts to approx 2.6 Million ADA, you can’t have a 9 month operational maintenance cost of 62 Million ADA.
This is a concern that must be addressed for the continued longevity of the Cardano blockchain, and if IOG cannot perform maintenance in the range of less than ½ the revenue of the blockchain per year, something needs to change, possibly the company that performs the maintenance for Cardano. At the very least we need a plan on how we can make annual Cardano blockchain maintenance sustainable. I am very surprised that so many DReps voted Yes for this proposal in its current form, as the cost is not justifiable as is.
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
I don't like the flood of maintenance proposals but this is necessary
- Yes 2.5M ₳ Rationale
この提案は評価が難しい典型的な内容ですが、その本質は明確です。Cardanoにおけるあらゆる機能・アップグレードは、安定した基盤の上にのみ成立します。「Maintenance is not discretionary（保守は選択ではない）」という認識に強く賛同します。目に見える成果が限定的であっても、継続的な保守・運用はネットワークの信頼性・安全性・可用性を支える不可欠な投資であり、結果としてエコシステム全体の発展を下支えするものです。以上の理由から、本提案に賛成します。
This proposal is a typical example of something difficult to evaluate, but its core is clear. All features and upgrades in Cardano depend on a stable and well-maintained foundation. I strongly agree with the view that “maintenance is not discretionary.” Even if the outcomes are not always visible, continuous maintenance is essential to ensure the reliability, security, and availability of the network, and ultimately supports the overall growth of the ecosystem. For these reasons, I support this proposal.
- No 2.5M ₳ Rationale
There is no doubt in my mind that IO is the most capable to handle Cardano maintenance. I am doing everything in my power to keep this in mind while assessing this proposal. This is IOs work to lose. I do like the idea of IO bringing in a specialist team instead of keeping everything in-house aligning with Pillar 5 and the 2030 Vision.
With that said, this proposal is lacking details to justify the size of the spend. I cannot vote YES on this proposal until the following points are addressed:
-FTE Rates
-More Advanced Budget and Spend breakdown
-High level hand-off plan on how this work actually transfers to Ensurable SystemsI would be willing to switch my vote if the above are addressed transparently.
- Abstain 2.4M ₳ No rationale
- Yes 2.4M ₳ No rationale