--- title: "Risco de armazenamento com delegatecall" description: "Delegatecall executa o código de outro contrato sobre o armazenamento do contrato chamador. Entenda como colisões de armazenamento, autoridade de atualização e destinos não confiáveis podem comprometer um proxy ou uma carteira inteligente." 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. # Risco de armazenamento com delegatecall > Somente para fins educacionais; não constitui aconselhamento de investimento. Investir pode causar perdas. ## Resposta direta `delegatecall` executa o código de um contrato de destino no contexto do contrato chamador. O chamador mantém seu próprio armazenamento, saldo e `address(this)`, enquanto `msg.sender` e `msg.value` preservam os valores da chamada original. Esse comportamento viabiliza proxies, bibliotecas e módulos de carteiras inteligentes, mas também concede ao código delegado a autoridade efetiva do chamador. Uma gravação no armazenamento, transferência de ativos, aprovação ou chamada externa é realizada como o chamador, não como o destino que forneceu o código. Trate todo destino acessível por `delegatecall` como código privilegiado. A segurança depende das regras de seleção do destino, da compatibilidade dos layouts de armazenamento, do estado de inicialização, dos controles de atualização e da implementação exata que estiver ativa para a transação. ## Como funciona Em uma chamada externa comum, o contrato chamado lê e grava em seu próprio armazenamento. Com `delegatecall`, o bytecode do destino é executado sobre o armazenamento do chamador: uma instrução `SSTORE` altera um slot pertencente ao chamador. Os nomes das variáveis do destino não importam durante a execução; somente as posições calculadas dos slots importam. Isso cria quatro limites que devem ser auditados: - **Controle do destino:** determine se o destino é fixo, selecionado por um usuário, resolvido por meio de um registro ou alterável por um administrador. - **Compatibilidade do armazenamento:** compare a ordem e os tipos das variáveis, a herança, as lacunas de armazenamento e os slots com namespace ou padronizados entre todas as versões da implementação. - **Inicialização e autorização:** confirme que os inicializadores não possam ser executados novamente e que as funções de atualização ou gerenciamento de módulos exijam o chamador previsto e o atraso de governança definido. - **Tratamento de retornos:** verifique se as falhas são propagadas e se os dados retornados são decodificados como o tipo esperado; chamadas de baixo nível não fornecem as verificações usuais do Solidity sobre o tipo de contrato. O ERC-1967 reduz colisões em proxies ao armazenar endereços de implementação, beacon e administrador em slots padronizados, fora da alocação normal do compilador. Ele não comprova que uma implementação seja segura nem que uma atualização autorizada seja inofensiva. ## Exemplo Suponha que uma carteira armazene `owner` em `slot 0`. Um plug-in compilado com `counter` em `slot 0` incrementa o contador quando a carteira o acessa por meio de `delegatecall`. A gravação altera o valor `owner` da carteira porque o armazenamento pertence à carteira. Se a palavra resultante codificar um endereço controlado por um invasor, verificações de autorização posteriores poderão reconhecer o invasor como proprietário, embora o plug-in nunca tenha mantido sob custódia os ativos da carteira. Um recibo bem-sucedido não distingue alterações de estado intencionais de alterações prejudiciais. Portanto, a simulação da transação deve inspecionar as diferenças de armazenamento, as mudanças em ativos e aprovações, os eventos emitidos e as chamadas subsequentes em relação aos endereços exatos do proxy e da implementação. ## Riscos - **Execução em destino arbitrário:** destinos controlados por usuários ou validados de forma insuficiente podem executar código malicioso com as permissões do chamador. - **Colisão de armazenamento:** uma implementação pode sobrescrever propriedade, saldos, estado de pausa ou até mesmo o slot que seleciona a próxima implementação. - **Atualização insegura:** um administrador ou processo de governança comprometido pode substituir código revisado anteriormente depois que os usuários depositaram ativos ou concederam aprovações. - **Falha de inicialização:** um proxy ou uma implementação não inicializados podem permitir que outra conta reivindique funções privilegiadas ou configure dependências perigosas. - **Inspeção enganosa:** verificar apenas o código-fonte do proxy, a implementação atual ou a interface pode deixar passar um beacon, uma atualização pendente, um registro de módulos ou um caminho de execução alternativo. Antes de assinar, identifique a implementação em um bloco recente, verifique quem pode alterá-la e com qual atraso, inspecione o bytecode verificado e o layout de armazenamento do destino, simule todos os calldata e compare o armazenamento sensível e as aprovações de tokens antes e depois da execução. Para uma carteira inteligente, verifique também como os módulos são habilitados e desabilitados e quais destinos eles podem escolher. ## Equívocos comuns - **“O destino não pode tocar nos ativos do chamador.”** O código delegado é executado como o chamador e pode invocar contratos externos, transferir ativos ou criar aprovações se o chamador tiver essas capacidades. - **“Nomes de variáveis correspondentes evitam colisões.”** A EVM usa slots de armazenamento, não nomes do código-fonte. A ordem do layout, a herança e os tipos devem permanecer compatíveis. - **“O código verificado do proxy significa que o sistema está verificado.”** A implementação ativa, o beacon, o administrador de atualizações, o estado de inicialização e as permissões dos módulos são partes distintas do limite de confiança. ## Tópicos relacionados - [Segurança criptoeconômica](/pt-br/crypto/crypto-economic-security/) - [RPC de transação privada](/pt-br/crypto/private-transaction-rpc/) - [Contrato proxy](/pt-br/crypto/proxy-contract/) - [Contrato inteligente](/pt-br/crypto/smart-contract/) - [Simulação de transações](/pt-br/crypto/transaction-simulation/) ## Fontes - [Introduction to Smart Contracts](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html) - Solidity Documentation (acessado em: 2026-08-20) - [Units and Globally Available Variables](https://docs.soliditylang.org/en/latest/units-and-global-variables.html) - Solidity Documentation (acessado em: 2026-08-20) - [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (acessado em: 2026-08-20) Source: https://wiki.fcontext.com/pt-br/crypto/delegatecall-storage-risk/index.mdx