Para onde foram os contratos inteligentes imutáveis?

Quando o DeFi começou a ganhar impulso, um de seus pontos de venda mais fortes era a imutabilidade. Defensores contrastavam contratos inteligentes com serviços centralizados como exchanges ou cassinos.

A narrativa era simples e convincente.

• Exchanges centralizadas, cassinos, processadores de pagamento e serviços similares exigem confiança em seus proprietários. O dono pode congelar sua conta, alterar taxas, fugir com sua criptomoeda ou entregá‑la ao governo ao primeiro pedido.
• O DeFi, em contrapartida, deveria exigir confiança apenas na confiabilidade do código do contrato inteligente. Um contrato inteligente era apresentado como uma máquina de venda automática encapsulada no concreto da blockchain. Suas regras eram conhecidas de antemão, e ninguém — nem o desenvolvedor, nem a polícia, nem um tribunal — poderia mudá‑las após o lançamento.

Alguns anos se passaram. Hoje, essa narrativa está efetivamente morta, embora raramente se reconheça isso abertamente. A grande maioria dos protocolos DeFi modernos (Aave, Compound, Uniswap V3, Sky Protocol, várias bridges e soluções L2) são, do ponto de vista técnico, atualizáveis. Seus administradores detêm chaves que transformam um contrato inteligente em algo mais próximo de um servidor web comum, cujo backend pode ser atualizado a qualquer momento.

Como aconteceu essa revolução silenciosa? Como exatamente os desenvolvedores aprenderam a contornar a imutabilidade da blockchain? E ainda existe algo verdadeiramente imutável no que continuamos a chamar de “finanças descentralizadas”?

Anatomia do Controle: Como Funcionam os Contratos Proxy

Muitos leitores podem objetar neste ponto: “Espere um segundo. A ideologia do DeFi surgiu dentro do Ethereum. E depois do polêmico episódio The DAO, ninguém ousaria reescrever nada naquela blockchain novamente. Então o código de qualquer contrato inteligente deve permanecer imutável após o deploy.”

Isso é verdade. Não apenas o Ethereum, mas qualquer blockchain é um banco de dados de acréscimo apenas. Ninguém pode apagar um contrato depois que ele foi escrito na cadeia.

No entanto, os desenvolvedores encontraram uma solução elegante que eventualmente se tornou um padrão da indústria: o Proxy Pattern.

Imagine que uma aplicação não consiste em um único contrato, mas em dois.

• O Proxy é a interface externa. Tem um endereço on‑chain fixo com o qual os usuários interagem, e é ali que todos os tokens e registros de saldo são armazenados. Mas esse contrato é deliberadamente raso: não contém lógica financeira central.
• A Implementation é o mecanismo interno. É onde vivem as fórmulas: como o juro é calculado, como tokens são trocados, quem pode sacar quanto. Mas esse contrato não detém criptomoeda em si.

Quando você deposita ou retira tokens, você interage com o Proxy. O Proxy usa uma instrução de baixo nível chamada delegatecall para ler o contrato Implementation e executar seu código no contexto do próprio armazenamento do Proxy.

Dentro do contrato Proxy, existe uma variável (frequentemente exposta via uma função interna _implementation) que armazena o endereço da Implementation atual. Há também uma função especial, acessível apenas ao administrador: upgradeTo(newAddress).

Em qualquer momento, o administrador do Proxy pode:

• implantar um novo contrato Implementation na blockchain (por exemplo, com um novo recurso ou correção de bug);
• chamar upgradeTo no Proxy e apontá‑lo para o novo endereço da Implementation.

Depois disso, o Proxy passa a usar imediatamente a nova lógica.

Do ponto de vista do usuário, nada mudou. O endereço do contrato é o mesmo, e sua criptomoeda continua armazenada ali. Na realidade, porém, as regras do sistema podem ter mudado completamente.

Se o administrador implantar uma Implementation maliciosa (por exemplo, uma que permita ao admin retirar todos os fundos), o Proxy entregará obedientemente toda a criptomoeda — porque ele executa cegamente qualquer código que lhe for indicado.

Por que Aceitamos Isso?

A mudança da imutabilidade para a atualizabilidade não nasceu da malícia — foi impulsionada pela necessidade.

Primeiro, lembremos da história do The DAO. Uma vulnerabilidade no seu contrato inteligente permitiu que um hacker drenasse uma enorme quantia de fundos. Para reverter isso, os operadores de nós do Ethereum tomaram uma medida que foi heresia para os puristas do cripto: reescreveram o histórico da blockchain para desfazer a transação do hacker. Todo o episódio deixou uma coisa clara — código imutável significa bugs imutáveis. Se um contrato tem uma falha, ela não pode ser corrigida. Isso deixa apenas duas opções: controle centralizado sobre toda a rede (como aconteceu com o Ethereum naquele momento), ou controle centralizado sobre contratos individuais. Com o tempo, a indústria se acostumou com o que parecia o mal menor: permitir controle centralizado no nível do contrato enquanto preserva a aparência de descentralização no nível do ecossistema.

Segundo, muitos projetos DeFi são efetivamente startups. Eles precisam evoluir — adicionar novas estratégias, suportar novos tokens, corrigir casos de borda. Sem contratos proxy, cada atualização forçaria os usuários a sacar fundos de um contrato antigo e depositá‑los em um novo. Isso é trabalhoso, caro e ruim para adoção.

Terceiro, os reguladores entraram em cena. O DeFi depende fortemente de stablecoins, e reguladores insistem que estes devem incluir recursos como blacklist de endereços e lógica atualizável para cumprir regras financeiras. Até o MakerDAO — emissor do DAI, outrora cartaz das stablecoins descentralizadas — teve que ceder. Quando rebatizou sob o Sky Protocol, adicionou funcionalidades controladas por administradores à sua nova stablecoin, USDS.

E os usuários? Votaram com suas carteiras. Altos retornos (APY) e interfaces atraentes importam para a maioria das pessoas mais do que ideais abstratos como descentralização.

A Ilusão da Descentralização: Quem Segura o “Botão Vermelho”?

Muitos projetos afirmam ser descentralizados simplesmente porque sua chave de admin não é controlada por um único indivíduo. Mas isso realmente muda algo?

Quando a chave de upgrade é detida por um único desenvolvedor, esse é claramente o cenário mais arriscado. Se essa pessoa for hackeada ou pressionada (fisicamente ou legalmente), os fundos dos usuários podem desaparecer num instante. E ainda assim essa configuração é comum — especialmente em contratos de meme coins, que muitas vezes são tratados com desdém.

Às vezes a chave é dividida em várias partes — digamos, cinco pessoas (frequentemente fundadores e primeiros investidores) cada uma com uma parte, e são necessárias três assinaturas para fazer mudanças. Mas isso ainda é centralizado. Conluio é possível. Intervenção estatal também.

Uma opção um pouco mais segura é o mecanismo Timelock. Aqui, um admin pode agendar uma atualização, mas ela só entra em vigor após 24–48 horas. Isso dá aos usuários tempo para revisar o novo código e sacar seus fundos se a mudança for maliciosa. Mas, na realidade, ninguém monitora contratos inteligentes 24/7. E em emergências (como um exploit ativo), 24–48 horas é tempo mais que suficiente para um atacante drenar tudo.

O mal menor é a governança baseada em DAO. Em protocolos como Compound e Uniswap, a autoridade de upgrade é tratada por contratos inteligentes vinculados à votação dos detentores de tokens. Mudanças só acontecem se votos suficientes forem a favor. Em teoria, isso é um passo rumo à verdadeira descentralização. Mas na prática, grandes fundos de VC (como a16z ou Polychain) detêm tantos tokens de governança que podem aprovar quase qualquer decisão. Além disso, a participação dos eleitores costuma ser mínima, tornando o processo fácil de controlar.

Ilhas de Imutabilidade: Quem Ainda Permanece Inalterado?

Existem ainda serviços DeFi onde “código é lei”? Sim — mas agora eles ocupam um nicho muito estreito no ecossistema. São exemplos raros de contratos inteligentes verdadeiramente imutáveis.

Uniswap V1 / V2
As pools de liquidez nessas versões são completamente imutáveis. Nem desenvolvedores, nem investidores, nem mesmo governos podem retirar fundos, alterar fórmulas ou mudar regras. Os contratos inteligentes estão gravados em pedra — sem chave de admin, sem caminho de upgrade.

Liquity USD (LUSD)
O contrato LUSD não tem chaves de admin nem função de upgrade. Os parâmetros do sistema foram codificados matematicamente no lançamento e nunca podem ser alterados. Isso o torna uma das stablecoins mais resilientes do DeFi. Não é amplamente usado — talvez porque as pessoas presumam que lhe falta liquidez. Mas isso é um equívoco:

• No nível do protocolo, todo LUSD pode sempre ser resgatado pelo ETH que o lastreia.
• No rabbit.io, LUSD pode ser trocado por qualquer cripto sem limites ou restrições.

Tornado Cash V1 / V2
As versões iniciais dos contratos do Tornado Cash inicialmente tinham chaves de admin — necessárias para corrigir bugs em ambiente ao vivo. Mas, uma vez que o protocolo se mostrou estável, o controle foi renunciado: a chave de admin foi dada ao endereço 0x00...0000, tornando os contratos totalmente imutáveis.

Essa decisão destacou uma verdade fundamental sobre a imutabilidade: ela protege contra ataques de governança.

Pegue o Tornado Cash V3 como conto de advertência. Essa versão introduziu melhorias: tamanhos de depósito flexíveis (não apenas 0.1, 1, 10 ou 100 ETH) e um sistema de transferências privadas baseado em L2 via Gnosis Chain. Para permitir upgrades e patches de segurança para um protocolo tão complexo, a governança foi entregue a uma DAO — especificamente, detentores do token TORN.

Em 2023, um atacante propôs uma atualização de governança aparentemente inofensiva. Oculta no código havia uma backdoor. Uma vez aprovada, deu ao atacante controle total sobre a DAO. Eles sequestraram a lógica do contrato e roubaram parte dos tokens de governança.

Tal ataque teria sido fisicamente impossível nas versões imutáveis. Não havia caminhos de upgrade. Não havia votos. Não havia botões vermelhos.

Além do Ethereum: Como Outros Ecossistemas Lidam com Upgrades de Contratos

Contratos proxy tornaram‑se o padrão de fato nas blockchains compatíveis com EVM. Mas e os ecossistemas não‑EVM?

Solana
Em muitos casos, a imutabilidade é ainda mais fraca do que no Ethereum. Por padrão, contratos em Solana podem ser atualizados usando uma Upgrade Authority. Desenvolvedores podem renunciar a esse poder para tornar um programa imutável, mas na cultura rápida e orientada à inovação da Solana, isso é raro. Situação similar existe no Near Protocol, onde a atualizabilidade também é a norma.

Polkadot e Cosmos
Esses ecossistemas seguem uma abordagem diferente: atualizações acontecem não por funções de admin dentro dos contratos, mas via governança ao nível dos validadores. Quando você deposita fundos em um contrato inteligente nessas redes, você não confia em um admin de contrato — você confia nos validadores de toda a cadeia para agir honestamente.

Cardano
Cardano suporta vários tipos de contratos inteligentes, mas o principal é o dos Plutus scripts, que se baseiam em um modelo estrito de imutabilidade.

• Um script Plutus está ligado a um UTXO específico e seu código é hashado no próprio endereço.
• Uma vez implantado, o código não pode ser alterado — ponto final.
• Se os desenvolvedores precisam corrigir um bug ou mudar a lógica de negócio, devem implantar um novo script com um hash diferente e migrar fundos manualmente.
• Por causa dessa arquitetura, padrões proxy são impossíveis.

Tecnically, Cardano também suporta contratos com lógica off‑chain, que poderiam ser usados para construir sistemas atualizáveis com controle de admin. Mas na prática, tais designs são raros — ao contrário do que ocorre nas chains EVM.

Ecossistema Bitcoin
Sim, o Bitcoin também tem protocolos de contratos inteligentes.

• RGB
  Aqui, tanto o contrato inteligente quanto o estado do token são armazenados localmente nos dispositivos dos usuários em vez de on‑chain. Não há um contrato centralizado que possa ser atualizado por um admin. Se um emissor de token lança novas regras, os usuários devem optar pela atualização — assim como atualizar um app no seu dispositivo. Não existe maneira de forçar mudanças em todos os usuários simultaneamente.
• Stacks
  Todos os contratos inteligentes no Stacks tornam‑se imutáveis uma vez implantados. Atualizações só podem ser introduzidas por uma arquitetura modular: nova funcionalidade é adicionada via contratos separados que interagem com o contrato original, mas não podem sobrescrever ou alterar as regras existentes. Em outras palavras, qualquer atualização é uma adição, não uma modificação. A lógica original permanece intacta e aplicável, e nenhuma parte do contrato implantado pode ser alterada retroativamente.
• Elastos e Rootstock
  São sidechains compatíveis com EVM, portanto seguem os mesmos padrões de upgrade do Ethereum. Desenvolvedores podem implementar contratos proxy e manter controle de admin, assim como em qualquer chain EVM.

Assim, mesmo na comunidade Bitcoin — que tradicionalmente valorizou imutabilidade em detrimento da flexibilidade — hoje existem protocolos de contratos inteligentes que permitem aos operadores de serviços modificar as regras após aceitarem os fundos dos usuários.

Conclusão

Parece que o termo “aplicação descentralizada” muitas vezes é pouco mais do que um truque de marketing. Isso não é necessariamente algo ruim: a capacidade de atualizar contratos inteligentes salvou bilhões de dólares quando vulnerabilidades foram descobertas. Mas os usuários precisam entender os riscos:

• Em um serviço tradicional centralizado, você pode perder sua cripto simplesmente porque não possui as chaves da sua carteira.
• No DeFi moderno, você pode perder sua cripto simplesmente porque o admin pode mudar a fechadura (as regras do contrato inteligente).

A verdadeira imutabilidade permanece no domínio de protocolos conservadores como Tornado Cash Classic, Liquity e soluções nativas em Cardano ou sobre o Bitcoin, que sacrificam flexibilidade em prol da segurança. Todo o resto, em última análise, se resume a confiança — em equipes escondidas por trás do rótulo brilhante de um “DAO”.