---
title: "Contrato inteligente atualizável"
description: "Um contrato inteligente atualizável preserva o endereço e o estado de um proxy enquanto agentes autorizados substituem ou redirecionam sua implementação. Essa flexibilidade acrescenta riscos de armazenamento, inicialização, governança e monitoramento."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Contrato inteligente atualizável
> Somente para fins educacionais; não constitui aconselhamento de investimento ou segurança. A capacidade de atualização pode dar a agentes privilegiados poder para mudar o comportamento do contrato e causar perdas.
## Resposta direta
Um contrato inteligente atualizável é um sistema implantado cuja lógica efetiva pode mudar sem transferir usuários para outro endereço principal nem descartar o estado ali guardado. Em redes compatíveis com Ethereum, um proxy normalmente mantém o estado e encaminha chamadas por `delegatecall` a um contrato de implementação. Uma atualização autorizada troca a implementação; endereço, armazenamento e saldo do proxy permanecem.
O bytecode imutável não é reescrito: acrescenta-se uma camada de indireção. Ela pode corrigir falhas e adicionar recursos, mas cria um caminho privilegiado capaz de alterar saques, taxas, permissões ou contabilidade. É preciso avaliar o código atual e as regras para o código futuro.
Nem todo proxy é atualizável e nem todo sistema mutável usa proxy. Alguns projetos implantam novos contratos e migram o estado; outros desativam atualizações definitivamente. Arquitetura e autoridade reais on-chain importam mais que o rótulo da interface.
## Como funciona
O proxy lê o endereço de implementação e executa seu código no contexto de armazenamento do proxy por `delegatecall`. Leituras e escritas afetam o proxy, preservando remetente e valor originais. ERC-1967 padroniza slots de implementação, beacon e administrador.
Proxies transparent separam chamadas administrativas e de usuário. Proxies UUPS colocam a lógica de atualização na implementação e usam compatibilidade ERC-1822, tornando a autorização crítica. Proxies beacon obtêm a implementação de um beacon; uma mudança pode afetar muitos proxies.
Compatibilidade de estado é a principal restrição. Reordenar, remover ou mudar tipos de variáveis, ou alterar herança, pode corromper dados. Layouts somente aditivos, lacunas reservadas ou armazenamento em namespaces ERC-7201 ajudam, mas ainda exigem validação entre versões.
Construtores inicializam a implementação, não o proxy. Por isso chama-se uma vez um inicializador como `initialize`. A implementação deve bloquear inicialização direta, e migrações posteriores devem usar reinicializadores limitados. Um inicializador público ou repetível pode entregar o controle.
Um processo defensável é:
1. Fixar fontes, compilador, dependências, layouts, endereços e bytecode esperado das duas implementações.
2. Revisar diferenças, compatibilidade, inicialização ou migração, autorização, dependências e rollback; testar a transação completa em um fork.
3. Publicar proposta e endereço e aplicar multisig, governança e timelock declarados sem bypass oculto.
4. Executar e verificar slot de implementação ou beacon, eventos, bytecode, estado inicializado, papéis e invariantes em um bloco registrado.
5. Monitorar slots, papéis e parâmetros e planejar incidentes sem presumir que reverter será sempre seguro.
## Exemplo
Um protocolo de empréstimo precisa de nova função de pagamento. Seu proxy delega à implementação A. A equipe implanta B, confirma que B apenas acrescenta armazenamento e prepara a migração. A governança publica o bytecode e põe a atualização após um timelock de 48 horas. Depois, o mesmo endereço delega a B e os saldos continuam no proxy.
Usuários devem confirmar a mudança do slot de A para B, a execução única da migração e os papéis e saldos. Se um guardião contorna o timelock ou um signatário substitui B por código arbitrário, esse poder integra o modelo de confiança.
## Riscos
- **Substituição privilegiada:** administrador, multisig, governador ou chave comprometida pode instalar lógica maliciosa ou defeituosa.
- **Corrupção de armazenamento:** layout incompatível pode reinterpretar saldos, proprietários, mappings ou contas.
- **Falha de inicialização:** inicializador omitido, repetido ou exposto pode travar o sistema ou transferir controle.
- **Falha específica do padrão:** transparent, UUPS, beacon e proxies personalizados falham de formas diferentes; o nome não prova correção.
- **Governança de fachada:** timelock ou votação pode ter bypass emergencial, prazo curto, poder concentrado ou signatários frágeis.
- **Migração ou rollback inseguro:** o estado pode mudar irreversivelmente; código antigo não necessariamente restaura seu significado.
- **Lacuna de verificação:** fonte verificada não prova que o proxy a usa nem que administrador e estado são os esperados.
- **Risco de monitoramento e integração:** exploradores, interfaces, auditores e integrações podem seguir versão antiga ou perder mudança do beacon.
## Equívocos comuns
- **“O contrato neste endereço é imutável.”** O bytecode do proxy pode ser imutável enquanto o slot de implementação ou beacon muda seu comportamento.
- **“Um multisig descentraliza atualizações.”** Só reduz dependência de uma chave com signatários independentes, limiar, operação e substituição sólidos.
- **“Um timelock impede atualização maliciosa.”** Ele oferece tempo de observação e saída, mas não torna o código seguro.
- **“Passar na verificação de armazenamento prova segurança.”** Ela cobre layout, não lógica, autorização, oráculos, migração ou economia.
- **“Renunciar a atualizações sempre elimina controle.”** Administrador, beacon, governador, autorização UUPS e caminhos alternativos devem ser verificados on-chain.
## Tópicos relacionados
- [Contrato inteligente](/pt-br/crypto/smart-contract/)
- [Como ler uma auditoria de contrato](/pt-br/crypto/contract-audit/)
- [Carteira multisig](/pt-br/crypto/multisig-wallet/)
- [Timelock](/pt-br/crypto/timelock/)
## Fontes
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (acessado: 2026-08-22)
- [ERC-1822: Universal Upgradeable Proxy Standard (UUPS)](https://eips.ethereum.org/EIPS/eip-1822) - Ethereum Improvement Proposals (acessado: 2026-08-22)
- [ERC-7201: Namespaced Storage Layout](https://eips.ethereum.org/EIPS/eip-7201) - Ethereum Improvement Proposals (acessado: 2026-08-22)
- [Proxy Upgrade Pattern](https://docs.openzeppelin.com/upgrades-plugins/proxies) - OpenZeppelin Docs (acessado: 2026-08-22)
- [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin Docs (acessado: 2026-08-22)
- [Proxy](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin Docs (acessado: 2026-08-22)
- [Layout of State Variables in Storage and Transient Storage](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html) - Solidity Documentation (acessado: 2026-08-22)
Source: https://wiki.fcontext.com/pt-br/crypto/upgradeable-contract/index.mdx