Proposta de Manutenção de 62M ADA da Cardano Transforma Infraestrutura em Um Teste para o Tesouro
IO e Ensurable Systems estão pedindo 62,1 milhões de ADA para financiar nove meses de manutenção do núcleo da Cardano, colocando os DReps diante de uma pergunta difícil: quanto a governança descentralizada deve pagar por uma infraestrutura que os usuários só percebem quando ela falha?
By SongMarketCap
Updated:
Michael Karg Explica Por Que a Manutenção da Cardano Não é Apenas Trabalho de Retaguarda
O debate sobre governança da Cardano em torno da Iniciativa de Manutenção da Cardano pela IO & Ensurable Systems recebeu um importante contexto técnico durante uma nova sessão do Cardano Governance Hour realizada em 12 de maio de 2026. Em uma discussão moderada por Nicolas Ceani da Cardano Foundation, Michael Karg, Líder de Desempenho e Rastreamento da Cardano na Input Output Engineering, explicou o que a proposta cobre, por que ela solicita mais de 62 milhões de ADA e por que a manutenção não deve ser tratada como trabalho de rotina em segundo plano.
Karg não estava falando como representante de marketing. Ele falava como líder técnico de uma equipe que trabalha em uma das camadas de infraestrutura menos visíveis, mas mais importantes da Cardano. Sua equipe trabalha com a observabilidade do nó da Cardano, incluindo log, métricas, eventos observáveis e benchmarks em nível de sistema. Na prática, isso significa ajudar a medir como mudanças no protocolo, mudanças no nó ou ajustes no orçamento de execução do Plutus afetam os recursos reais utilizados pelos operadores de pools de participação e outros participantes da rede.
Isso é importante porque esta proposta não é apenas sobre se a IO deve receber uma grande retirada do tesouro. Trata-se de quem mantém a infraestrutura central da Cardano, como a segurança da rede é medida, como as versões são preparadas, como a dívida técnica é gerenciada e como a Cardano pode, ao longo do tempo, avançar em direção a uma maior diversidade de nós.
A proposta solicita 62.134.630 ADA e cobre um período de nove meses, do terceiro trimestre de 2026 até o final do primeiro trimestre de 2027. Karg esclareceu durante a discussão que a iniciativa não é uma solicitação de 12 meses, mas um ciclo de manutenção de nove meses.
Seu ponto central foi que a proposta de manutenção da Cardano é diferente de propostas que introduzem novas funcionalidades visíveis. Ele a descreveu como o trabalho na “sala de máquinas” do ecossistema, a parte que os usuários geralmente não percebem quando tudo funciona corretamente. É exatamente por isso que a questão é politicamente sensível. A governança da Cardano não está votando em uma nova carteira, um novo aplicativo DeFi ou uma nova funcionalidade voltada para o usuário. Está votando no trabalho necessário para manter o sistema estável o suficiente para que todo o resto seja construído sobre ele.
No momento da discussão, a proposta ainda estava longe de ser aprovada, mas Karg observou que muitos DReps tendem a esperar até os últimos dias de uma ação de governança antes de votar. Esse padrão de votação torna difícil ler o sentimento inicial, mas também aumenta a pressão sobre propostas técnicas importantes para que se expliquem claramente antes do fechamento da janela de decisão final.
Cardano Blueprint e Diversidade de Nós Ampliam o Debate Sobre Manutenção
A parte mais importante da discussão não foi apenas o alerta de que uma manutenção reduzida poderia aumentar o risco operacional. Karg mostrou que a Iniciativa de Manutenção da Cardano cobre um pacote técnico muito mais amplo, incluindo correção de bugs, arquitetura, infraestrutura DevOps, operações de testnet, sistemas de benchmark, protocolos de recuperação de desastres, ferramentas de monitoramento, suporte a lançamentos, processos de segurança e ferramentas essenciais da Cardano.
Esse escopo inclui operações de relé de bootstrap, manutenção de ambientes de teste como Preview e PreProd, suporte ao compilador Haskell, monitoramento da mainnet, monitoramento global do mempool, suporte em código aberto e trabalho em ferramentas como o interpretador Plutus, DB Sync, Cardano CLI, API da Cardano, guardrails e o script de identidade do Comitê Constitucional.
Um dos tópicos mais importantes foi o Cardano Blueprint. Karg o descreveu como um plano técnico do que constitui a Cardano, incluindo os protocolos que os nós usam para se comunicar entre si, detalhes em nível de byte, funções criptográficas e especificações que existem separadamente do próprio código. Isso não é documentação por si só. O Blueprint é importante porque oferece a outras equipes um framework mais claro para construir suas próprias implementações de nós, potencialmente em Rust, TypeScript ou outras linguagens.
Isso transforma a proposta de manutenção em algo maior do que uma manutenção de rotina. A Cardano frequentemente fala sobre descentralizar governança, operações de pools de participação e a tomada de decisões, mas a diversidade de implementações a longo prazo também faz parte dessa visão. O nó em Haskell continua sendo a implementação de referência hoje, mas um ecossistema mais saudável não deve depender para sempre de um único caminho de código, um único centro de engenharia ou uma única organização.
A inclusão da Ensurable Systems também foi enquadrada nesse contexto. A IO lideraria as entregas durante este ciclo, mas a Ensurable Systems é listada como parceira de entrega com conhecimento de domínio da Cardano e experiência, já que seus fundadores trabalharam anteriormente na IO. Karg conectou isso à descentralização da administração, significando que a manutenção da Cardano não deve permanecer responsabilidade de uma única organização a longo prazo.
Um dos detalhes tecnicamente mais interessantes foi o suporte ao compilador Haskell. Karg disse que o nó da Cardano é provavelmente uma das aplicações Haskell mais complexas existentes. Por causa disso, a IO trabalha de perto com a equipe do compilador Haskell, já que os benchmarks da Cardano podem revelar problemas na geração de código que um conjunto de benchmarks padrão do compilador pode não cobrir, simplesmente porque a base de código da Cardano é tão grande e complexa.
Esse detalhe mostra por que a manutenção não é apenas um item administrativo em uma tabela do tesouro. Para a Cardano, a manutenção inclui disciplina de desempenho, compreensão dos limites do sistema, cooperação com ferramentas fundamentais de desenvolvimento e preparação da rede para futuras atualizações, como Leios, Hydra, funcionalidade de tesouro multiativos e outras mudanças que dependem de um nó central estável.
DReps Estão Votando com Base em Evidências, Não Apenas no Custo
O maior desafio para esta proposta não é apenas se a manutenção importa. O desafio é a confiança. Uma solicitação de mais de 62 milhões de ADA é grande, e o Tesouro da Cardano está atualmente enfrentando muitas propostas de retirada paralelas. Nesse ambiente, os DReps estão certos em exigir uma conexão clara entre orçamento, entregáveis e resultados mensuráveis.
Karg apontou relatórios de benchmarks públicos e atualizações da Cardano como parte dessa transparência. Relatórios de benchmarking comparam lançamentos de nós anteriores e novos, rastreiam o uso de recursos, produção de blocos, difusão de blocos e adoção de blocos, e são frequentemente conectados às notas de lançamento. Para os SPOs e DReps técnicos, isso não é decoração. É uma das formas de tornar visível o trabalho de manutenção por meio do desempenho mensurável da rede.
Esse é um argumento sólido para a proposta, mas não elimina todas as preocupações. O moderador levantou a questão de quantas pessoas trabalham nos nove fluxos de trabalho e como os DReps devem entender a alocação de equipes, capacidade de FTE e prioridades. Karg respondeu que os entregáveis abrangem várias equipes e engenheiros, que a IO usa dados históricos para estimar esforço e tempo e que a proposta é orientada por resultados. Em outras palavras, a IO está assumindo a responsabilidade pelos resultados dentro do valor solicitado.
Essa resposta é tecnicamente razoável, mas não é perfeita como comunicação de governança pública. DReps que desejam um detalhamento orçamentário mais simples, um mapa de FTE mais claro e uma estrutura de custos mais precisa por categoria provavelmente continuarão a fazer perguntas. Isso não torna a proposta fraca, mas significa que sua comunicação deve ser extremamente precisa. Para uma solicitação desse tamanho, dizer que a manutenção é importante não é suficiente. A comunidade precisa ver o que pode ser verificado, onde o progresso será visível e como o financiamento do tesouro se torna produção operacional.
Também há uma questão de prioridade. Se a Cardano financia manutenção, Leios e outras propostas técnicas ao mesmo tempo, a mesma organização e o mesmo talento de engenharia podem estar envolvidos em vários fluxos de trabalho. Karg explicou que a IO gerencia prioridades por meio de avaliações semanais e mensais, interdependências e rastreamento de orçamentos separados por projeto. Isso mostra que um processo interno existe, mas também confirma que a governança da Cardano está entrando em uma fase em que propostas técnicas não podem ser julgadas isoladamente.
É por isso que a votação não é simples. Rejeitar uma solicitação grande do tesouro pode parecer disciplina fiscal. Aprová-la pode parecer financiamento responsável para a infraestrutura. Ambos os lados têm argumentos, mas a versão superficial do debate perde o ponto. A verdadeira questão não é se a comunidade gosta do tamanho do número. A verdadeira questão é se a Cardano pode distinguir entre um custo que parece caro e uma infraestrutura que se torna crítica apenas quando está ausente.
Essa proposta, portanto, deve ser defendida com evidências, não com hype. Se a IO e a Ensurable Systems quiserem ganhar a confiança dos DReps, seu argumento mais forte não será o medo de problemas, mas uma ligação clara entre o valor solicitado, entregáveis públicos, disciplina de benchmarks, documentação Blueprint e descentralização de implementações a longo prazo. A governança da Cardano não está apenas decidindo se irá pagar pela manutenção. Está decidindo se pode financiar de forma responsável a disciplina técnica que determina quão forte será a base sob suas aplicações, pools de participação e futuras atualizações.