IO & Ensurable Systems: Cardano Maintenance Initiative
239 DReps voted · 78 with a rationale
Open a row to read the rationale.
- No 2.4M ₳ No rationale
- Yes 2.3M ₳ No rationale
- Yes 2.1M ₳ No rationale
- Yes 2.1M ₳ Rationale
- Abstain 2.1M ₳ No rationale
- Yes 2.1M ₳ No rationale
- Yes 2.1M ₳ Rationale
I voted YES on the Cardano Maintenance Initiative because a stable, secure, and well-maintained Cardano platform is the foundation for every other ecosystem objective. The proposal funds essential work across node bugfixing, security reviews, CI/CD, monitoring, performance, QA, release management, incident response, DB-Sync, APIs, CLI tooling, Plutus Core maintenance, and the Cardano Blueprint. While the ask is large and must be scrutinised carefully, underfunding core maintenance would create unacceptable technical and operational risk for the network. My support is conditional on strong milestone-based disbursement, independent assurance, transparent reporting, and return of unspent funds.
- Yes 2.1M ₳ No rationale
- Yes 2M ₳ Rationale
Approving a massive budget of up to 62.1 million ADA just for 'system maintenance' may seem absurd at first glance, but in reality, we view this as a matter of life-and-death 'insurance policy' that the entire Cardano network is forced to sign.
We believe that it is impossible to build skyscrapers like Ouroboros Leios technology or multi-billion dollar DeFi applications on an uncared-for foundation. In the blockchain world, where the smallest security vulnerability can wipe out user assets and permanently destroy trust, system maintenance is not an 'option', but the oxygen for survival. This proposal provides an invisible yet solid shield to protect the network: from emergency disaster recovery systems and continuous security monitoring, to patching and automated testing. Therefore, we vote YES to build Cardano.
- Yes 2M ₳ No rationale
- Yes 2M ₳ No rationale
- Abstain 1.9M ₳ No rationale
- Yes 1.8M ₳ No rationale
- Yes 1.8M ₳ Rationale
Ongoing maintenance of Cardano’s code base is essential to ensure the system maintains security, reliability, and performance.
- Yes 1.7M ₳ No rationale
- Yes 1.7M ₳ No rationale
- Yes 1.7M ₳ No rationale
- Yes 1.7M ₳ No rationale
- Yes 1.5M ₳ Rationale
I am voting YES on this proposal because long-term maintenance is foundational to Cardano’s stability, security, and operational resilience. The proposal covers critical ongoing responsibilities — including node maintenance, QA, monitoring, release management, security coordination, infrastructure operations, and documentation — that are necessary to sustain a production-grade blockchain ecosystem.
For these reasons, I believe this proposal represents necessary operational investment in Cardano’s core infrastructure and ecosystem continuity.
- Yes 1.5M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- Yes 1.4M ₳ No rationale
- No 1.3M ₳ Rationale
I recognize that Cardano maintenance is essential. Node maintenance, DevOps, monitoring, QA, release support, documentation, and component maintenance are foundational activities that the entire ecosystem depends on.
However, this proposal requests ₳62,134,630, making it one of the largest single funding requests in this round. For a Treasury Withdrawal of this size, I believe the current level of budget disclosure is not sufficient. While the proposal provides high-level categories such as Development, Infrastructure, Engagement, Operations, Security & Audits, and others, it lacks a more detailed cost structure, including team size, role allocation, salary ranges, infrastructure cost breakdowns, audit and testing costs, outsourcing costs, delivery milestones, and specific budgets and acceptance criteria for each functional area.
My concern is not that maintenance is unimportant. My concern is that voters currently do not have enough information to determine whether this ₳62M+ request is reasonable, efficient, and sufficiently accountable. Cardano Treasury funds are public funds. The larger the request, the higher the standard should be for transparency, cost breakdowns, milestones, monthly reporting, and measurable deliverables.
Given the current level of disclosure, I cannot support this proposal in its present form. I would encourage the proposer to provide a more detailed budget breakdown and verifiable deliverables before seeking community approval again.
我認同 Cardano 的維護工作是必要且重要的。節點維護、DevOps、監控、QA、release support、文件維護與各項元件維護，都是整個生態系持續運作所依賴的基礎工作。
然而，本提案申請金額高達 ₳62,134,630，是本輪最大單筆資金申請案之一。對於這種規模的 Treasury Withdrawal，我認為目前的預算揭露程度仍然不足。雖然提案中列出了 Development、Infrastructure、Engagement、Operations、Security & Audits 等高階分類，但仍缺少更細部的成本結構，例如團隊人數、角色分工、薪資區間、基礎設施成本明細、審計與測試成本、外包成本、交付里程碑，以及各 functional area 對應的具體預算與驗收標準。
我的疑慮並不是 maintenance 不重要，而是目前投票人沒有足夠資訊去判斷這筆 ₳62M+ 的支出是否合理、是否有效率，以及是否具備足夠的 accountability。Cardano Treasury 是公共資金，申請金額越大，對透明度、成本拆分、里程碑、月度報告與可衡量交付成果的要求就應該越高。
在目前資訊揭露程度下，我無法支持本提案的現行版本。我建議提案方補充更詳細的預算拆分與可驗收成果後，再重新尋求社群授權。
- Yes 1.2M ₳ No rationale
- Yes 1.2M ₳ Rationale
IOG certainly asks for a lot, although some of the proposals are collaborations with other companies. I will go over the different proposals separately.
✅ Developer Experience
It’s important that developers who want to build on Cardano can do so as easily as possible. While I think this proposal could be done more cheaply, not getting it done would be much worse.✅ Cardano Upgrades
These upgrades will be beneficial for Cardano.✅ Consensus
Implementing Leios is important to handle the transaction volume we’ll have once Cardano is used for many use cases. I would have preferred to see Simple Leios implemented directly (with a longer time frame), though, rather than first spending time and resources on Linear Leios.✅ L2 Scalability
We need solid L2 solutions for high transaction volume applications that would be too expensive on L1 (in terms of resources and fees).❌ Cardano High Assurance
I like this proposal, but unfortunately, under the current available NCL and taking other proposals into account, difficult choices need to be made. I will approve this proposal if it is resubmitted under a new NCL.✅ Cardano Maintenance
This proposal is too expensive for what it delivers, but alternative nodes are not yet mature enough to risk stalling the development of cardano-node.✅ Plutus
Further improvements and extensions of smart contract capabilities are important.➖ Blockfrost
I think the free tier should be subsidized by the revenue Blockfrost generates from its paid tiers, like any other company using a freemium model. I do recognize the decentralization efforts made, although funding for this was already received in the past; hence I will abstain.➖ Pogun
There are multiple alternatives for Bitcoin DeFi on Cardano being developed, and it remains to be seen which one will perform best and attract the most users. The treasury should not provide a grant for this, but since the earnings would be used to repay the funds, it is essentially a loan. Given that additional revenue would later be shared with the treasury, it could even be considered an investment. However, I am not sure whether the current NCL allows for this kind of investment at the moment. If a higher NCL becomes available, I would vote in favor of this proposal, but for now I will abstain. - Yes 1.1M ₳ No rationale
- Yes 1.1M ₳ No rationale
- No 1M ₳ Rationale
I've a strong bias against turning the treasury into a comfort budget. The relevance for maintenance is undeniable. Let's get this straight right away. Furthermore, our constitution explicitly allows budgets for ongoing operation, maintenance, and future development.
And this is where it gets tricky. We must not confuse necessity with value for money. The proposal’s core message is “maintenance is the foundation.” True, and by playing the fear card the proposal gets the label of being immune from scrutiny for most DReps. However, based only on the amount, abstract, motivation, rationale, and supplied support material, I do not see sufficient independent evidence that ₳62M is reasonable. This is a broad bundle, a veggie stew, not a sharpened procurement case, or a tasty recipe.
**This proposal is selling oxygen to DReps afraid of suffocation, especially here and now, with Cardano having dropped out of the top 10 and continuing to fall under increasing sell pressure from the developers we're funding here. We're not yet at a stage where “core maintenance” becomes too important to question. I would rather fund unavoidable critical maintenance through smaller, modular, competitively benchmarked, auditable service contracts, clearly separating safety-critical operations from improvement, documentation, engagement, and ecosystem support, than this behemoth. **
Plus, the question must be addressed why Cardano still can't maintain itself after operating for ten years, and what will happen to the socialist mentality of siphoning funds from the treasury when there's nothing left to extract. That question must be raised, and it must be raised now!
- Yes 1M ₳ No rationale
- Yes 985.7K ₳ Rationale
Important for Cardano's sustainability.
- Yes 955.2K ₳ No rationale
- Yes 947.9K ₳ No rationale
- Yes 922.9K ₳ No rationale
- Yes 860.4K ₳ No rationale
- Yes 818K ₳ Rationale
Our mandate as detailed in our profile within the file "Latam Cardano DREP" forces us to strictly balance our dedication to protocol security against fiscal discipline and the ongoing decentralization of ecosystem resources. Technically, keeping the lights on through the Cardano Maintenance Initiative is vital for the entire global ecosystem.
- Yes 804.1K ₳ Rationale
Every proposal being voted on this cycle depends on what this one funds. Bug fixes, security reviews, release management, incident response, performance monitoring, the full operational layer that keeps Cardano running. None of it is optional and none of it stops when the feature work does.
- No 793K ₳ Rationale
Sounds great, but I don't care. IO was funded during the last major Intersect budget cycle with a long list of deliverables. Why wasn't all of this in competition for funding at that time if it was so bloody important. I'm not interested in cutting any more big checks from the Treasury with ADA at these price levels. Get your shit together and tell us what you want to accomplish as part of the primary budget cycle.
- Yes 785.2K ₳ Rationale
This is non-optional spend — without maintenance, all other funded initiatives degrade or fail.
Covers full-stack operational integrity (node, infra, security, QA, release) → directly tied to uptime and trust.
Enables everything else (Leios, DevX, upgrades); this is the base layer of execution capacity.
However, ₳62M is very large for “maintenance” → weak cost discipline and limited modularization.
Should ideally be broken into smaller, competing contracts over time to avoid IO monopoly risk. - Yes 765.1K ₳ No rationale
- Yes 762.8K ₳ No rationale
- Yes 762.6K ₳ No rationale
- Yes 738.5K ₳ No rationale
- Yes 733.1K ₳ Rationale
Yes!!!
- Yes 670.2K ₳ Rationale
I’m voting yes because this is not just feature funding, it’s the core maintenance layer that keeps Cardano secure, stable, and capable of scaling. It covers critical work like bug fixes, security reviews, CI/CD infrastructure, performance optimisation, monitoring, disaster recovery, and continuous upkeep of core components like Plutus, DB-Sync, and the node. Without this, technical debt and operational risk would build up over time, making future upgrades slower and more fragile even if the chain continues running. I also see this as part of preparing for a more automated future where AI agents increasingly handle infrastructure operations and transaction optimisation. If that trajectory continues, it could significantly improve efficiency, throughput, and economic activity on-chain, strengthening the network’s fee base over time. In that sense, maintaining a strong and reliable foundation now helps position Cardano for a future where automation and higher usage reduce long-term strain on treasury funding needs.
- No 654.5K ₳ Rationale
no
- Yes 624.8K ₳ Rationale
Total ask: ₳62,134,630 | ~$14.9M at $0.24
Development: ₳45,979,626 = 74% Infrastructure: ₳6,213,463 = 10%
Team: Cross-functional spanning all nine areas.
FTE estimate: $11.03M dev ÷ ~50 specialists ÷ 9 months × 12 ≈ $294–441K/engineer/yearA PDF version of this rationale is also made available.
Cardano's entire development pipeline depends on this proposal. Every feature that ships this cycle from Leios, Babel Fees, CIP-159, and the developer tooling I voted for earlier, moves through a release process, runs through a QA framework, gets hardened by security reviews, and operates on infrastructure that this maintenance envelope keeps alive. You cannot selectively defund maintenance. I'm voting yes.
At ₳62,134,630 (~$14.9M at $0.24), this is the largest single ask in the current IO CBU batch. The 74% development allocation is lower than IO's 86% on feature proposals but, is explained by the 10% infrastructure line: CI/CD pipelines, distributed benchmark clusters, testnet operations, and mainnet monitoring all at production scale carry real operating costs. Over nine months with a team spanning consensus, ledger, DevOps, QA, performance, security, documentation, and release management, the implied per-engineer cost lands in an expensive but, defensible range. Two things I'd strengthen in a future submission: explicit SLA targets (incident resolution times, uptime thresholds) in addition to the directional KPI alignment, and a disclosed budget split between IO and Ensurable Systems for a co-delivery of this scale.
Two elements align directly with priorities I've stated publicly. The Cardano Blueprint, the implementation-independent specifications covering consensus, network, ledger, and Plutus, is precisely the documentation that makes Amaru, Dingo, and Gerolamo viable. Alternative node clients need complete, authoritative specs to implement against; this is where those specs live. The guardrails and CC identity script maintenance is governance infrastructure I depend on directly as a DRep, and that work is non-discretionary.
The collaboration with Ensurable Systems is worth naming: IO is deliberately distributing infrastructure stewardship, reducing single-entity concentration risk over time. This is the right direction for the ecosystem. Standard milestone-based Intersect governance and I expect to see more diversification year over year as stated by IO. Vote yes. - Yes 589.2K ₳ Rationale
Gotta keep the best chain running on our path to Crypto Eating Legacy - we're going for #1
- Abstain 536.5K ₳ Rationale
This proposal is critical, since maintenance is non-optional for that reason I cannot in good conscience vote against it
On the other side it is:
Ridiculously overpriced, it is essentially highway robbery exploiting our need for it
Contains work items that should have been delivered as part of the cardano-node development , how on hell did IOG perform principles first formal verification on the node if “comprehensive specifications covering consensus” was not created beforehand ?
The Cardano-node is supposedly built with high-reliability methodology , namely “formal verification/proofs”, the result of that should be a node that requires less maintenance, yet we are stuck here with a bill for maintenance that is 10x what other node teams are asking for developmentFor this 3 reasons I cannot vote YES, leaving me with the only option as abstain!