---
title: "Como monitorar upgrades de contratos proxy"
description: "Monitore mudanças de implementação, beacon e controle em proxies atualizáveis e, depois da execução, verifique código, compatibilidade de armazenamento, inicialização, permissões e comportamentos críticos."
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.
# Como monitorar upgrades de contratos proxy
> Apenas para fins educacionais; não constitui recomendação de investimento. Investimentos podem resultar em perdas.
## Resposta direta
Monitore o caminho de controle de um sistema atualizável, além do endereço do proxy. Um alerta deve identificar quem pode autorizar e executar um upgrade, qualquer atraso obrigatório, as implementações antiga e nova e os calldata de inicialização. Após a execução, leia de forma independente a configuração on-chain e teste os comportamentos críticos.
O endereço do proxy e seus saldos podem permanecer iguais enquanto o código delegado altera permissões, taxas, contabilidade, pausas ou lógica de saque. Uma auditoria anterior não cobre automaticamente uma nova implementação nem sua inicialização.
## Como funciona
Primeiro, identifique o padrão de proxy. O ERC-1967 define slots de armazenamento separados para `eip1967.proxy.implementation`, `eip1967.proxy.beacon` e o slot opcional `eip1967.proxy.admin`. Alterações diretas da implementação devem emitir `Upgraded`; mudanças do endereço do beacon, `BeaconUpgraded`; e mudanças do slot de administrador, `AdminChanged`. Em um proxy beacon, também chame `implementation()` no beacon, pois ele pode trocar sua implementação sem alterar o slot beacon do proxy.
Não deduza o modelo completo de autoridade pelo slot de administrador. Um proxy Transparent pode ser controlado por um `ProxyAdmin`, enquanto a autorização de upgrade UUPS é implementada no contrato lógico atual por meio de `_authorizeUpgrade`. Rastreie proprietários, papéis, limites de multisig, timelocks, governadores, caminhos de emergência e a capacidade de alterar esses controles.
Use assinaturas de eventos e leituras periódicas de estado. O ERC-1967 recomenda os eventos, mas não obriga toda implementação a emiti-los. Registre cadeia, bloco, transação, proxy, implementação ou beacon, hash do código em execução, executor e estado de controle relevante a partir de endpoints RPC independentes. Alerte sobre operações agendadas, canceladas e executadas e aguarde a política de confirmação ou finalidade escolhida para a cadeia antes de considerar o estado definitivo.
## Exemplo
Um proxy de empréstimos é controlado por um multisig 3 de 5 por meio de um timelock de 24 horas. Quando um upgrade é agendado, o monitor registra o identificador da proposta, alvo, calldata, horário mínimo de execução, implementação atual, implementação proposta e situação da verificação do código-fonte. Os revisores comparam o código e os layouts de armazenamento, inspecionam a chamada de inicialização e verificam mudanças em papéis, chamadas externas, taxas, regras de pausa e caminhos de saque.
Após a execução, o monitor relê o slot ERC-1967 relevante, verifica o código implantado em execução e confere pós-condições esperadas, como versão da implementação, administradores ou detentores de papéis, estado de pausa, contabilidade dos ativos e prévia de saque somente para leitura. Um novo alerta é disparado se o endereço ou hash observado divergir da proposta revisada ou se a consulta periódica encontrar uma mudança não informada por evento.
## Riscos
- **Risco de controle:** Um multisig nominal pode ser contornado por outro proprietário, papel, módulo, governador, chave de emergência ou timelock mutável. Siga cada caminho até os signatários finais e o atraso.
- **Risco de código e armazenamento:** Código não verificado, layouts incompatíveis, inicialização insegura ou dependência alterada podem corromper o estado ou conceder autoridade indevida. Valide o artefato exato implantado, não apenas uma branch ou o nome de uma auditoria.
- **Risco de monitoramento:** Um único RPC, indexador apenas de eventos, front-end ou explorador de blocos pode atrasar ou errar. Concilie eventos com armazenamento, bytecode, recibos de transação e estado do protocolo em fontes independentes.
- **Risco de resposta:** Um alerta sem responsável e procedimento testado pode chegar tarde demais. Defina quem revisa, pausa integrações, comunica ou sai durante o atraso e reconheça que aprovações apressadas e links não oficiais de recuperação acrescentam risco.
Procedimento mínimo:
1. Inventarie cada proxy, beacon, implementação, administrador, papel e ponto de entrada de upgrade em cada cadeia.
2. Salve uma referência válida de slots, hashes de código, estado de controle e resultados críticos somente para leitura.
3. Alerte antes da execução quando o agendamento por governança ou timelock permitir e novamente na execução ou no cancelamento.
4. Compare o alvo, calldata, implementação, bytecode, layout de armazenamento e estado pós-upgrade executados com a proposta revisada.
5. Escale mudanças inesperadas, pós-condições com falha, ausência de verificação do código-fonte ou atraso reduzido ou contornado; não trate o endereço inalterado do proxy como prova de segurança.
## Equívocos comuns
- **Mito 1: "Monitorar `Upgraded` é suficiente."** Mudanças na implementação do beacon e proxies fora do padrão podem exigir o monitoramento de outro contrato ou consultas de estado; concilie eventos com leituras diretas.
- **Mito 2: "O slot de administrador mostra quem controla todo upgrade."** O slot é opcional, e projetos Transparent, UUPS, beacon, de governança e personalizados colocam a autoridade em contratos e funções diferentes.
- **Mito 3: "Código verificado ou auditoria anterior prova que o upgrade é seguro."** Verifique bytecode implantado, premissas do compilador e construtor, compatibilidade de armazenamento, inicialização, configuração e comportamento da versão exata.
## Tópicos relacionados
- [Risco de módulo multisig](/pt-br/crypto/multisig-module-risk/)
- [Contrato proxy](/pt-br/crypto/proxy-contract/)
- [Colisão de armazenamento do proxy](/pt-br/crypto/proxy-storage-collision/)
- [Pausa emergencial do protocolo](/pt-br/crypto/protocol-emergency-pause/)
- [Contrato atualizável](/pt-br/crypto/upgradeable-contract/)
## Fontes
- [ERC-1967: slots de armazenamento de proxy](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (acessado: 2026-08-21)
- [Proxy](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (acessado: 2026-08-21)
- [Como escrever contratos atualizáveis](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (acessado: 2026-08-21)
- [Controle de acesso](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin (acessado: 2026-08-21)
Source: https://wiki.fcontext.com/pt-br/crypto/proxy-upgrade-monitoring/index.mdx