Uma auditoria de contrato inteligente é uma tentativa estruturada de descobrir como um contrato pode falhar, ser usado indevidamente ou ser controlado de uma forma que os usuários não esperavam. Não se trata do mesmo que executar um scanner, ler um selo de auditoria ou confirmar que o código-fonte foi verificado. Use o fluxo de trabalho abaixo para revisar um contrato EVM implantado ou uma base de código antes de confiar nele com fundos significativos.
Importante: Este é um guia prático de revisão, não uma garantia de que um projeto seja seguro e não constitui aconselhamento de investimento. Um protocolo de produção de valor substancial deve ser submetido a uma revisão independente por profissionais de segurança experientes. As imagens de interface neste guia são ilustrativas e não devem ser consideradas como evidência sobre qualquer projeto ou implementação específica.
| Etapa | Pergunta principal | Evidências úteis |
|---|---|---|
| 1. Âmbito de aplicação | Estou analisando exatamente o contrato que os usuários solicitam? | Endereço, cadeia, bytecode, proxy e implementação |
| 2. Pontos de entrada | O que cada pessoa que liga pode fazer? | Funções públicas/externas, mudanças de estado, gráfico de chamadas |
| 3. Automação | Que padrões óbvios merecem atenção? | Saída do compilador, resultados do Slither, triagem do detector |
| 4. Segurança manual | Uma sequência de chamadas pode quebrar pressupostos? | Chamadas externas, reentrada, retornos de chamada, tratamento de falhas |
| 5. Lógica | A contabilização permanece correta em casos extremos? | Aritmética, arredondamento, taxas, limites, transições de estado |
| 6. Privilégios | Quem pode mudar ou parar o sistema? | Funções, proprietário, chaves de administrador, proxy, inicializador |
| 7. Testes | O comportamento se mantém mesmo diante de entradas e sequências inesperadas? | Testes de unidade, fuzz, invariante e bifurcação |
| 8. Relatórios | Outra pessoa consegue reproduzir e testar novamente o resultado? | Status de descoberta, impacto, evidência, correção e reteste |
Comece com a cadeia e o endereço exatos. Registre o endereço de implantação, o hash da transação, o número do bloco, a versão do compilador, as configurações do otimizador, os argumentos do construtor e o commit ou release que a equipe indica como implantado. Um projeto pode ter vários endereços para um token, roteador, cofre, proxy, implementação, oráculo ou implantação de teste. Revisar um endereço incorreto não tem utilidade prática.
Verifique se o código-fonte verificado do explorador reproduz o bytecode implantado. A verificação é útil porque permite inspecionar o código-fonte e a ABI, mas é apenas uma verificação de identidade: não comprova que a lógica de negócios seja segura. Se o contrato for atualizável, identifique o proxy e sua implementação atual. Leia o endereço da implementação no mecanismo documentado do proxy ou nas informações do explorador e confirme se a implementação é a que você pretende revisar. O guia oficial de verificação da Foundry do Etherscan documenta a verificação para contratos novos e existentes.
Defina também os limites. Inclua bibliotecas importadas, contratos herdados, bibliotecas vinculadas, contratos auxiliares implantados, adaptadores de oráculo, tokens recebidos de usuários e componentes privilegiados fora da cadeia. Anote o que está fora do escopo e por quê. Isso evita que uma revisão restrita seja confundida com uma revisão de todo o sistema.
Liste todas as funções públicas e externas, incluindo funções herdadas e manipuladores de fallback ou recebimento. Para cada uma, registre se ela pode:
Em seguida, mapeie os ativos e os limites de confiança. Acompanhe um depósito do usuário no armazenamento, passando pelo cálculo de preços e participação, até o saque. Identifique cada endereço fornecido por um solicitante e cada endereço carregado do armazenamento. Questione quais valores são considerados honestos: um oráculo, um token, uma mensagem de ponte, um guardião, um receptor de retorno de chamada ou um administrador. Os alvos de revisão de maior valor são funções que combinam entrada controlada pelo usuário, estado privilegiado, aritmética e uma chamada externa.
Reproduza a compilação do projeto com a versão do Solidity, as versões das dependências, a configuração do otimizador e as suposições da cadeia de destino especificadas. Trate os avisos do compilador como itens de revisão, e não como ruído inofensivo. As considerações de segurança do Solidity recomendam especificamente levar os avisos a sério, manter os contratos compreensíveis e verificar problemas conhecidos do compilador. Consulte a lista oficial de bugs conhecidos do compilador Solidity quando a versão do compilador ou os padrões de código afetados tornarem isso relevante.
Para projetos Hardhat, Foundry ou similares, execute o Slither a partir da raiz do projeto. Sua documentação oficial descreve a ferramenta como um analisador estático para Solidity e Vyper e fornece o seguinte comando comum:
slither .Salve a saída e classifique cada resultado por impacto e confiabilidade. Examine atentamente as descobertas envolvendo envios arbitrários de tokens, upgrades desprotegidos, reentrância, valores de retorno não verificados, delegatecall perigoso, tx.origin, aleatoriedade fraca e interfaces incorretas. Um detector pode reportar um falso positivo, não detectar uma falha econômica específica do projeto ou sinalizar código que foi intencionalmente restringido em outro lugar. A análise estática restringe a busca; ela não substitui o raciocínio manual. O repositório e a documentação do Slither também listam impressoras para pontos de entrada, autorização, grafos de chamadas e resumos de contratos que ajudam a organizar uma revisão.
Para cada chamada externa, pare e rastreie o estado antes, durante e depois da chamada. O destinatário da chamada pode ser um contrato malicioso, um token com ganchos, um receptor de retorno de chamada ou outro protocolo que altera uma dependência compartilhada. A documentação do Solidity explica que uma interação com outro contrato pode transferir o controle para esse contrato e recomenda o padrão Verificações-Efeitos-Interações: valide primeiro, atualize o estado deste contrato em segundo lugar e interaja externamente por último.
Não limite a busca a transferências óbvias de Ether. Verifique hooks no estilo ERC-777, callbacks ERC-1155, callbacks de empréstimos relâmpago, roteadores arbitrários, chamadas a oráculos e chamadas feitas por meio de bibliotecas herdadas. Analise a reentrância entre funções e contratos: um callback pode entrar em uma função diferente que lê um estado intermediário. Confirme se cada chamada de baixo nível verifica seu resultado de sucesso e lida corretamente com o valor retornado. Verifique se um destinatário com falha pode bloquear permanentemente saques ou um loop.
Registre uma sequência de ataque concreta para cada problema plausível. Por exemplo: o atacante deposita, inicia um saque, recebe um retorno de chamada, inicia um segundo saque e somente então permite que a primeira chamada seja concluída. Se a sequência não puder ser executada devido a uma invariante ou proteção específica, anote o motivo. Isso torna a conclusão auditável em vez de especulativa.
Verifique o significado de cada unidade e conversão: wei versus ether, decimais do token, pontos-base, ações versus ativos, valores com sinal e unidades de tempo. Respeite a direção do arredondamento. Uma divisão que arredonda a favor de um depositante, tomador de empréstimo, liquidante ou beneficiário de taxas pode resultar em perda de valor quando repetida. Revise a multiplicação antes da divisão, os valores mínimos e máximos, os limites de taxas, os preços desatualizados, a oferta zero, o saldo zero e o primeiro depositante ou o último sacador.
O Solidity 0.8 e versões posteriores normalmente detectam estouro e subfluxo aritméticos, mas o código dentro de um uncheckedbloco altera esse comportamento deliberadamente. A aritmética verificada também pode fazer com que um protocolo reverta ou se torne inutilizável se os limites não forem projetados corretamente. Teste ambos os resultados: roubo ou contabilização incorreta e negação de serviço causada por um valor que nunca poderá ser processado.
Escreva as invariantes em linguagem clara antes de transformá-las em testes. Exemplos incluem "o total de ações corresponde aos ativos de acordo com a regra de arredondamento estabelecida", "um usuário não pode sacar mais do que o valor registrado em seu pedido", "o fornecimento total de tokens é igual à soma dos saldos onde esse modelo se aplica" e "uma taxa não pode exceder seu limite configurado". Compare os saldos de armazenamento com os saldos reais de tokens, pois os tokens podem ser enviados diretamente para um contrato ou podem se comportar de maneira diferente da implementação ERC-20 presumida.
Construa uma matriz de privilégios. Para cada função administrativa, identifique o papel necessário, o detentor atual, o mecanismo de transferência, o atraso, o controle de assinatura múltipla ou governança e o comportamento em caso de emergência. Dê atenção especial à emissão de tokens, pausas, alterações de taxas, alterações de fontes de oráculo, resgate de fundos, atualização de código e alteração de endereços de tokens ou roteadores confiáveis. A documentação de controle de acesso do OpenZeppelin distingue a propriedade simples de permissões baseadas em funções e descreve o princípio do menor privilégio como uma prática de segurança útil.
Diferencie "o código permite que um administrador faça isso" de "qualquer usuário pode fazer isso". O primeiro pode representar um risco explícito de governança ou custódia; o segundo, uma vulnerabilidade de autorização. Verifique se as verificações de função abrangem todos os caminhos sensíveis, incluindo funções auxiliares internas acessíveis a partir de funções públicas. Verifique se um administrador padrão pode conceder a si mesmo ou a outros poderes adicionais e se a transferência de propriedade pode ser enviada acidentalmente para um endereço inválido.
Para proxies, revise o inicializador, a autorização de implementação, o atraso de atualização, o layout de armazenamento e o plano de reversão ou de emergência. As diretrizes de contrato atualizável do OpenZeppelin explicam por que os construtores não inicializam o armazenamento do proxy, por que os inicializadores devem ser protegidos, por que uma implementação não deve permanecer não inicializada e por que alterar a ordem ou os tipos de armazenamento pode corromper uma atualização. Trate a chave de administrador do proxy como parte do limite de segurança do protocolo, e não como um detalhe de implementação.
Execute testes unitários para o comportamento esperado e, em seguida, adicione testes negativos para chamadas não autorizadas, valores zero, valores máximos, assinaturas expiradas, dados de oráculo desatualizados, transferências com falha e operações repetidas. Realize fuzzing nas entradas em vez de testar apenas alguns números escolhidos a dedo. Inclua contratos com múltiplos atores e receptores maliciosos onde o projeto permitir callbacks.
Use testes de invariantes para propriedades que devem permanecer verdadeiras após várias chamadas aleatórias. A documentação de testes de invariantes do Foundry descreve sequências aleatórias, entradas fuzzificadas, execuções, profundidade, contratos de destino e remetentes de destino. Configure os manipuladores para que as chamadas sejam significativas; se cada depósito fuzzificado reverter porque o ator de teste não possui tokens, um teste de invariante bem-sucedido pode simplesmente significar que nenhum estado útil foi alterado.
Sempre que possível, utilize um fork da rede de destino para testar os endereços implantados, a configuração atual, o comportamento do token e o roteamento do proxy. Mantenha os testes do fork seguros e somente leitura, a menos que esteja usando um fork local isolado. Minimize cada sequência com falha e preserve o contraexemplo, os endereços do chamador, o contexto do bloco, os saldos e os valores de armazenamento relevantes. Um teste aprovado é uma evidência sobre os caminhos testados, não uma prova de todos os caminhos possíveis.
Utilize um registro por ocorrência. Uma constatação prática deve conter:
A gravidade deve refletir o impacto e a explorabilidade realistas, e não o quão alarmante um padrão de código pareça. Explique as premissas. Uma chamada de baixo nível pode ser segura por trás de uma invariante forte; uma alteração de parâmetro aparentemente comum pode ser crítica se controlar um oráculo ou uma atualização. Após uma correção, revise as diferenças, execute novamente o teste relevante, execute novamente o conjunto completo de testes e verifique se há regressões. Se o endereço implantado já tiver sido atualizado ou alterado, teste novamente a implementação e a configuração reais na blockchain.
Você deve ser capaz de responder sim a estas perguntas:
Se alguma resposta for negativa, classifique a auditoria como incompleta e indique as evidências faltantes. Uma limitação transparente é mais útil do que uma conclusão vaga de "seguro". A segurança de contratos inteligentes é um processo contínuo: cada atualização, alteração de dependência, nova integração e mudança de privilégio pode criar um novo limite de revisão.
Aprenda a alocar criptomoedas de acordo com a tolerância ao risco, o horizonte de tempo, a diversificação, a custódia, a liquidez e o rebalanceamento — sem depender de uma fórmula única para todos.
Aprenda passo a passo como auditar o contrato inteligente de um projeto de criptomoedas, desde a verificação da implantação e mapeamento de permissões até os testes de lógica, atualizações e correções.
Construa um portfólio de criptomoedas de longo prazo com uma abordagem de priorização de riscos para alocação, seleção de ativos, custódia, disciplina de compra, rebalanceamento, registros e prevenção de golpes.
Aprenda a ler dados on-chain, rastrear carteiras de grandes investidores, avaliar rótulos de dinheiro inteligente e separar fatos verificáveis da blockchain de inferências antes de agir com base na atividade da carteira.
Aprenda por que as plataformas de futuros de criptomoedas exibem um erro de "Margem Insuficiente", como diagnosticar a causa, corrigi-la com segurança e evitar problemas de margem antes de realizar sua próxima negociação.
Aprenda como funcionam o Binance Launchpad e o Launchpool, como verificar sua elegibilidade, participar com segurança, acompanhar suas recompensas e entender os limites e riscos.
Aprenda o que significa "tolerância de slippage excedida" em CEXs e DEXs, como verificar se uma negociação falhou e quando atualizar a página, reduzir o tamanho da posição, usar uma ordem limite ou ajustar a tolerância.
Aprenda como funciona o Copy Trading da Bybit, como avaliar Traders Mestres, definir parâmetros de cópia, gerenciar riscos e monitorar operações copiadas de contratos perpétuos de USDT.
Aprenda como a oferta, a demanda, os desbloqueios, as emissões, as queimas e a utilidade dos tokens podem afetar o preço de uma criptomoeda — e o que a tokenomics não consegue prever.
Aprenda a comparar o volume de criptomoedas com sua linha de base, confirmar rompimentos de preço, identificar perda de momentum e evitar confundir um pico manipulado com força.
