Auditoria de smart contracts: método e limites

“Auditado por especialistas” aparece em quase todo site de projeto cripto. A frase passa a ideia de que o código foi aprovado e é seguro. A documentação de desenvolvedores do Ethereum diz o contrário: auditorias “não vão pegar todos os bugs” e não devem ser tratadas como solução definitiva (ethereum.org, Smart contract security).

Este texto explica como uma auditoria de contratos inteligentes costuma funcionar, que técnicas ela usa e quais são os seus limites. O objetivo é ajudar você a ler um relatório de auditoria com olhar crítico. O que é um contrato inteligente e por que um erro nele é difícil de desfazer está em O que são contratos inteligentes e como funcionam.

O que é uma auditoria de smart contract

Uma auditoria é uma revisão independente do código de um ou mais contratos inteligentes, feita antes ou depois da publicação na blockchain, para encontrar falhas de segurança e erros de lógica. O resultado é um relatório: uma lista de achados, cada um com descrição, gravidade e recomendação de correção.

A revisão importa mais aqui do que em software comum por três razões, todas descritas na documentação do ethereum.org:

• o código é público: qualquer pessoa, inclusive um atacante, pode estudá-lo;
• o código guarda valor: um contrato pode controlar milhões em tokens, e uma falha explorada transfere esse valor de forma imediata;
• o código é, por padrão, imutável: depois de publicado, não dá para simplesmente corrigir. Padrões de atualização existem, mas trazem riscos próprios, como veremos.

A mesma página estima que o valor perdido por defeitos de segurança em contratos inteligentes passa “facilmente de 1 bilhão de dólares”.

Como uma auditoria costuma ser feita

Não existe uma norma única que padronize o trabalho. A descrição abaixo, na avaliação da redação, reúne as etapas mais comuns e as técnicas que a documentação técnica descreve.

1. Definição do escopo

Tudo começa por delimitar o que será revisado: quais arquivos, em qual versão. Em projetos sérios, a versão é identificada por um hash de commit, um código único que aponta para um estado exato do repositório. O escopo também diz o que não será revisado, como interfaces, scripts de publicação ou contratos de terceiros. Esse detalhe é decisivo depois, na leitura do relatório.

2. Entendimento do que o código deveria fazer

Auditor não consegue apontar erro de lógica sem saber qual era a intenção. Por isso pede documentação, diagramas e, idealmente, uma especificação: a lista do que o sistema deve e não deve permitir. Exemplo: “nenhum usuário consegue sacar mais do que depositou”. Nessa etapa também se monta um modelo de ameaças, isto é, quem poderia atacar e por onde.

3. Revisão manual

É o centro da auditoria. Pessoas leem o código linha a linha procurando padrões conhecidos de falha e, principalmente, erros específicos daquele projeto, que nenhuma ferramenta conhece. Catálogos públicos ajudam a organizar essa busca:

• o OWASP Smart Contract Top 10, na edição de 2025, lista as categorias mais associadas a incidentes: falhas de controle de acesso, manipulação de oráculos de preço, erros de lógica, falta de validação de entradas, reentrância, chamadas externas sem verificação, ataques com empréstimos-relâmpago (flash loans), estouro de inteiros, aleatoriedade insegura e negação de serviço. Segundo o OWASP, a lista foi construída a partir de 149 incidentes que somaram mais de US$ 1,42 bilhão em perdas;
• o SWC Registry classifica fraquezas com códigos, como SWC-107 para reentrância (quando um contrato externo chama de volta a função antes que ela termine de atualizar os saldos). O próprio site avisa que não é mantido ativamente desde 2020, o que é um lembrete de que catálogos envelhecem.

4. Análise estática

A análise estática examina o código sem executá-lo, a partir de representações como o fluxo de controle. O exemplo mais conhecido é o Slither, ferramenta de código aberto para Solidity e Vyper. O repositório lista cerca de cem detectores, classificados por impacto, e informa que a análise leva em média menos de um segundo por contrato. A ferramenta acha padrões rapidamente, mas cada alerta precisa ser conferido por uma pessoa: parte deles não é um problema real, e erros de regra de negócio passam despercebidos.

5. Testes e fuzzing

A documentação do ethereum.org afirma que testes unitários, sozinhos, são “minimamente eficazes” para segurança, e recomenda combiná-los com testes baseados em propriedades. Nessa técnica, você escreve invariantes, isto é, regras que devem valer sempre, e uma ferramenta tenta quebrá-las.

O fuzzing é a versão automática disso: gerar milhares de sequências aleatórias de chamadas e verificar se alguma viola uma invariante. O Echidna, por exemplo, procura sequências de chamadas que falsifiquem propriedades escritas pelo desenvolvedor. Se encontra, mostra o caminho. Se não encontra, isso aumenta a confiança, mas não é prova de que a falha não existe.

6. Verificação formal

A verificação formal usa métodos matemáticos para provar que o código cumpre uma especificação formal. Segundo a página do ethereum.org sobre o tema, ela pode provar a ausência de erros em relação a essa especificação, algo que testes não fazem. É também cara, exige alta especialização e não se aplica a tudo: algumas propriedades podem ser impossíveis de provar, e as ferramentas esbarram na explosão de estados possíveis. Por isso costuma ser usada em partes críticas, não no sistema inteiro.

7. Relatório, correção e nova checagem

Os achados recebem uma gravidade, geralmente de crítica a informativa. A equipe do projeto corrige, ou justifica por que não vai corrigir, e os auditores conferem as correções. Bons relatórios registram o estado final de cada item: corrigido, parcialmente corrigido ou reconhecido sem correção.

O que uma auditoria não garante

Os limites a seguir não são defeitos de um auditor específico. São características do próprio método.

Ela vale para uma versão, numa data. Se o código muda depois, a parte nova não foi auditada. Em contratos atualizáveis, que usam um contrato intermediário (proxy) para trocar a lógica, o código em produção pode deixar de ser o que foi revisado. O ethereum.org lembra ainda que, quando um único dono controla funções administrativas, há risco de centralização: quem tem a chave pode alterar regras ou pausar o sistema. Como isso aparece em ativos tokenizados está em Contratos inteligentes aplicados a ativos reais.

Ela verifica o código contra uma intenção, e a intenção pode estar errada. A página do ethereum.org sobre verificação formal alerta que especificações fracas levam a concluir, de forma equivocada, que o contrato está livre de falhas. O mesmo vale para a revisão manual: se ninguém previu um cenário, ele não foi testado.

Ela pode não cobrir o ambiente econômico. Manipulação de preço em oráculos e ataques com empréstimos-relâmpago aparecem no topo do OWASP Top 10. Nesses casos, cada linha do código pode fazer exatamente o que promete, e mesmo assim o sistema perde dinheiro, porque as regras econômicas permitem um abuso. Avaliar isso exige olhar o protocolo junto com o mercado em que ele opera, como explicado em DeFi: o que são finanças descentralizadas e Oráculos: como o ativo físico chega à blockchain.

O compilador também pode errar. O código que roda na blockchain é o resultado da compilação, não o texto que o auditor leu. A documentação do Solidity mantém uma lista de bugs conhecidos do compilador, por versão, para que ferramentas verifiquem se a versão usada é suspeita. No Vyper, outra linguagem de contratos, um alerta de segurança de agosto de 2023, classificado como crítico, informou que as versões 0.2.15, 0.2.16 e 0.3.0 alocavam de forma incorreta as travas contra reentrância. Um código-fonte que parecia protegido podia não estar.

Ela costuma não incluir o que está fora da blockchain. Chaves privadas de administradores, servidores, interfaces web, validadores de pontes e processos operacionais ficam, em geral, fora do escopo. Em pontes, por exemplo, já houve perdas grandes causadas por chaves comprometidas, sem nenhuma falha no código, como mostra Pontes entre blockchains: como funcionam e onde falham. Golpes que enganam o usuário, como os de phishing em carteiras, também não são assunto de auditoria de código.

Ela não avalia se o projeto é um bom negócio. Auditoria de segurança não analisa modelo econômico, distribuição de tokens, situação jurídica ou capacidade da equipe. Para isso, veja Tokenomics: como analisar antes de avaliar um projeto e Como analisar os riscos de um projeto de tokenização.

Por esses limites, a documentação do ethereum.org trata a auditoria como uma camada entre várias: testes bem feitos, análise automática, programas de recompensa por falhas (bug bounty), com prêmios proporcionais ao valor em risco, e monitoramento dos eventos do contrato depois da publicação, com alertas para movimentos fora do padrão.

Como ler um relatório de auditoria

Se um projeto diz que foi auditado, procure o relatório completo, não só o selo. Perguntas úteis:

• Qual é a data e qual versão foi revisada? Procure o hash de commit e compare com o código verificado no explorador de blocos. Se o projeto não permite essa comparação, a auditoria diz pouco sobre o que está em uso.
• O que estava no escopo? Um relatório pode cobrir só um contrato de um sistema com dez.
• Quais achados ficaram abertos? Itens “reconhecidos” sem correção continuam lá. Leia a justificativa.
• O contrato pode ser alterado? Por quem? Verifique se há proxy, quem detém as chaves de administração, se há assinatura múltipla e prazo de espera antes de mudanças.
• Houve mais de uma revisão e há programa de recompensa por falhas? Revisões independentes e incentivo contínuo à descoberta de falhas reduzem, mas não zeram, o risco.
• O relatório é público e verificável? Desconfie de selos sem link para o documento ou de relatórios que não identificam o código revisado.

A redação não recomenda empresas de auditoria. A qualidade de uma revisão depende do escopo, do tempo dedicado e da documentação recebida, e isso aparece no relatório, não na marca.

O que levar deste texto

• Auditoria é revisão independente de uma versão específica do código, com escopo definido. Combina leitura humana, análise estática, fuzzing e, às vezes, verificação formal.
• Ela reduz o risco, não o elimina. Mudanças posteriores, poderes de administração, ataques econômicos, bugs de compilador e componentes fora da blockchain podem escapar.
• “Auditado” não é selo de segurança nem de qualidade do investimento. Leia o relatório: data, versão, escopo, achados abertos e quem pode alterar o contrato.