Cardano’s 62M ADA Maintenance Proposal Turns Infrastructure Into a Treasury Test

Michael Karg Explains Why Cardano Maintenance Is Not Just Back Office Work

Cardano’s governance debate around the IO & Ensurable Systems Cardano Maintenance Initiative received important technical context during a new Cardano Governance Hour session held on May 12, 2026. In a discussion moderated by Nicolas Ceani from the Cardano Foundation, Michael Karg, Cardano Performance & Tracing Lead at Input Output Engineering, explained what the proposal covers, why it asks for more than 62 million ADA, and why maintenance should not be treated as routine background work.

Karg was not speaking as a marketing representative. He was speaking as the technical lead of a team working on one of Cardano’s least visible but most important infrastructure layers. His team works on observability for the Cardano node, including logging, metrics, observable events and system level benchmarks. In practice, that means helping measure how protocol changes, node changes or Plutus execution budget adjustments affect the real resources used by stake pool operators and other network participants.

That matters because this proposal is not only about whether IO should receive a large treasury withdrawal. It is about who maintains Cardano’s core infrastructure, how network safety is measured, how releases are prepared, how technical debt is managed and how Cardano can move over time toward stronger node diversity.

The proposal asks for 62,134,630 ADA and covers a nine month period, from Q3 2026 through the end of Q1 2027. Karg clarified during the discussion that the initiative is not a 12 month request, but a nine month maintenance cycle.

His central point was that the Cardano Maintenance proposal is different from proposals that introduce visible new features. He described it as work in the ecosystem’s “engine room”, the part users usually do not notice when everything works correctly. That is exactly why the issue is politically sensitive. Cardano governance is not voting on a new wallet, a new DeFi app or a new user facing feature. It is voting on the work required to keep the system stable enough for everything else to be built on top of it.

At the time of the discussion, the proposal was still far from approval, but Karg noted that many DReps tend to wait until the final days of a governance action before voting. That voting pattern makes early sentiment difficult to read, but it also increases the pressure on large technical proposals to explain themselves clearly before the final decision window closes.

Cardano Blueprint and Node Diversity Expand the Maintenance Debate

The most important part of the discussion was not only the warning that reduced maintenance could increase operational risk. Karg showed that the Cardano Maintenance Initiative covers a much wider technical package, including bug fixing, architecture, DevOps infrastructure, testnet operations, benchmark systems, disaster recovery protocols, monitoring tools, release support, security processes and key Cardano tooling.

That scope includes bootstrap relay operations, maintenance of test environments such as Preview and PreProd, Haskell compiler support, mainnet monitoring, global mempool monitoring, open source support and work on tools such as the Plutus interpreter, DB Sync, Cardano CLI, Cardano API, guardrails and the Constitutional Committee identity script.

One of the most important topics was Cardano Blueprint. Karg described it as a technical blueprint of what constitutes Cardano, including the protocols nodes use to communicate with each other, byte level details, cryptographic functions and specifications that exist separately from the code itself. This is not documentation for its own sake. Blueprint matters because it gives other teams a clearer framework for building their own node implementations, potentially in Rust, TypeScript or other languages.

That turns the maintenance proposal into something larger than routine upkeep. Cardano often talks about decentralizing governance, stake pool operations and decision making, but long term implementation diversity is also part of that picture. The Haskell node remains the reference implementation today, but a healthier ecosystem should not depend forever on one code path, one engineering center or one organization.

The inclusion of Ensurable Systems was also framed in that context. IO would lead delivery during this cycle, but Ensurable Systems is listed as a delivery partner with Cardano domain knowledge and experience, since its founders previously worked at IO. Karg connected this to the decentralization of stewardship, meaning that Cardano maintenance should not remain the responsibility of only one organization over the long term.

One of the most technically interesting details was Haskell compiler support. Karg said the Cardano node is probably one of the most complex Haskell applications in existence. Because of that, IO works closely with the Haskell compiler team, since Cardano benchmarks can reveal code generation issues that a standard compiler benchmark suite may not cover, simply because Cardano’s codebase is so large and complex.

That detail shows why maintenance is not just an administrative line item in a treasury table. For Cardano, maintenance includes performance discipline, understanding system limits, cooperation with foundational developer tooling and preparing the network for future upgrades such as Leios, Hydra, multi asset treasury functionality and other changes that depend on a stable core node.

DReps Are Voting on Evidence, Not Only on Cost

The biggest challenge for this proposal is not only whether maintenance matters. The challenge is trust. A request of more than 62 million ADA is large, and the Cardano Treasury is currently facing many parallel withdrawal proposals. In that environment, DReps are right to demand a clear connection between budget, deliverables and measurable outcomes.

Karg pointed to public benchmark reports and Cardano Updates as part of that transparency. Benchmarking reports compare previous and new node releases, track resource usage, block production, block diffusion and block adoption, and are often connected to release notes. For SPOs and technical DReps, that is not decoration. It is one of the ways maintenance work becomes visible through measurable network performance.

That is a strong argument for the proposal, but it does not remove every concern. The moderator raised the issue of how many people work across the nine workstreams and how DReps should understand team allocation, FTE capacity and priorities. Karg answered that the deliverables stretch across multiple teams and engineers, that IO uses historical data to estimate effort and time, and that the proposal is outcome oriented. In other words, IO is taking responsibility for the results within the requested amount.

That answer is technically reasonable, but it is not perfect as public governance communication. DReps who want a simpler budget breakdown, a clearer FTE map and a more precise cost structure by category will likely continue asking questions. That does not make the proposal weak, but it means its communication must be extremely precise. For a request of this size, saying that maintenance is important is not enough. The community needs to see what can be verified, where progress will be visible and how treasury funding becomes operational output.

There is also a priority question. If Cardano funds maintenance, Leios and other technical proposals at the same time, the same organization and the same engineering talent may be involved in several workstreams. Karg explained that IO manages priorities through weekly and monthly assessments, interdependencies and separate budget tracking by project. That shows an internal process exists, but it also confirms that Cardano governance is now entering a phase where technical proposals cannot be judged in isolation.

This is why the vote is not simple. Rejecting a large treasury request can look like fiscal discipline. Approving it can look like responsible infrastructure funding. Both sides have arguments, but the shallow version of the debate misses the point. The real question is not whether the community likes the size of the number. The real question is whether Cardano can distinguish between a cost that looks expensive and infrastructure that becomes critical only when it is missing.

This proposal should therefore be defended with evidence, not hype. If IO and Ensurable Systems want to earn DRep trust, their strongest argument will not be fear of problems, but a clear link between the requested amount, public deliverables, benchmark discipline, Blueprint documentation and long term implementation decentralization. Cardano governance is not only deciding whether to pay for maintenance. It is deciding whether it can responsibly fund the technical discipline that determines how strong the foundation will be beneath its applications, stake pools and future upgrades.