Smart Contract Audits: What Auditors Check—and What an Audit Does Not Guarantee

Uma auditoria de contrato inteligente é uma análise independente do código e da arquitetura dentro de um escopo definido. Seu objetivo é identificar vulnerabilidades, erros de implementação e divergências entre o comportamento esperado e o real.

Uma auditoria pode reduzir a incerteza, mas não torna um contrato isento de riscos. A orientação oficial de segurança da Ethereum descreve auditorias como uma análise adicional, não como uma solução infalível capaz de detectar todos os erros.

Este artigo tem finalidade exclusivamente educacional. Uma auditoria não garante segurança, recuperação de recursos nem retornos.

O escopo vem primeiro

Um relatório útil identifica exatamente o que foi analisado:

• repositório e hash do commit;
• arquivos e contratos;
• versão do compilador e configurações de compilação;
• dependências;
• arquitetura e funções privilegiadas;
• branch ou versão;
• exclusões, limitações e premissas;
• data da revisão.

Isso importa porque uma auditoria legítima pode abranger uma versão antiga, outra implantação ou apenas uma parte de um sistema maior.

O que os auditores geralmente analisam

1. Comportamento esperado e invariantes

Os auditores comparam o código com sua especificação:

• quem pode chamar cada função;
• como os valores e as taxas são calculados;
• quando ocorrem mudanças de status;
• quais propriedades devem permanecer sempre válidas;
• como casos extremos e falhas são tratados.

Se a especificação omitir um requisito importante, um código tecnicamente correto ainda poderá implementar uma arquitetura insegura ou indesejada.

2. Controle de acesso

Os revisores inspecionam os papéis de proprietário, administrador, operador e outras funções privilegiadas, incluindo poderes para:

• conceder ou revogar permissões;
• pausar o sistema;
• alterar taxas e limites;
• emitir tokens;
• sacar ativos;
• atualizar uma implementação.

Eles também avaliam se uma única chave pode realizar uma alteração crítica e se controles como multisig ou timelock fazem parte da arquitetura.

3. Chamadas externas e reentrância

Durante a execução, um contrato pode transferir o controle para outro contrato. Isso pode permitir reentrância, quando o contrato externo faz uma nova chamada antes da conclusão da transição de estado original. A orientação oficial da Solidity recomenda ordenar cuidadosamente as verificações, os efeitos no estado e as interações externas, quando apropriado.

4. Cálculos e unidades

Os auditores procuram:

• arredondamento e perda de precisão;
• casas decimais divergentes do token;
• ordem incorreta das operações;
• valores-limite;
• divisão por zero;
• unsafe unchecked arithmetic;
• divergências entre as unidades internas e as exibidas.

5. Negação de serviço e gas

Loops sem limite, arrays crescentes, falhas em chamadas externas ou operações dispendiosas podem tornar uma função impraticável. Os revisores testam se a arquitetura continua utilizável à medida que os dados aumentam e diante de entradas incomuns.

6. Proxies e atualizações

Para sistemas atualizáveis, a análise deve abranger:

• contratos proxy e de implementação;
• permissões de atualização ou de administrador;
• inicialização;
• compatibilidade do layout de armazenamento;
• meios de atualização não autorizada;
• o efeito da alteração da lógica após a auditoria.

Um proxy pode preservar o mesmo endereço visível ao usuário enquanto delega a execução a uma nova lógica. Portanto, afirmações de que “o contrato não pode mudar” devem ser verificadas de acordo com a arquitetura real.

7. Integrações

Os contratos podem depender de tokens, oráculos de preço, pontes, DEXs, assinaturas ou outros contratos. Os auditores examinam as premissas sobre essas dependências, dados desatualizados, comportamentos incomuns de tokens e modos de falha externos.

8. Eventos e monitoramento

Os revisores podem verificar se os eventos expõem com precisão ações importantes, como mudanças de papéis, atualizações, pausas e transferências. Os eventos auxiliam o monitoramento, mas não substituem a inspeção do estado.

Métodos usados em uma auditoria

Uma análise geralmente combina:

• análise manual do código e da arquitetura;
• testes unitários e de integração;
• análise estática e dinâmica;
• fuzzing com dados de entrada gerados;
• testes baseados em propriedades;
• verificações de classes conhecidas de vulnerabilidades;
• revisão da compilação e da implantação;
• em alguns casos, verificação formal de propriedades selecionadas.

Nenhum método isolado cobre tudo. A verificação formal pode provar que um código atende a uma especificação formal; ela não pode provar uma propriedade que a especificação não expressou.

Como um usuário deve interpretar uma auditoria

1. Compare com a versão analisada

Localize o hash do commit e determine:

• se a implementação atual foi compilada a partir desse código;
• se ocorreram atualizações após a data do relatório;
• se a rede e os endereços implantados correspondem;
• se dependências críticas foram incluídas no escopo.

Se isso não puder ser comprovado, o relatório fornecerá evidências limitadas sobre a implantação ativa.

2. Leia as constatações, não apenas o resumo

Para cada constatação, analise:

• gravidade e cenário;
• código afetado;
• recomendação;
• resposta dos desenvolvedores;
• status atual;
• se o auditor testou novamente a correção.

Consertado ou Resolvido is meaningful only when tied to a specific corrected version.

3. Leia as limitações

Os relatórios podem excluir:

• sistemas de frontend e backend;
• gerenciamento de chaves;
• arquitetura econômica;
• contratos de terceiros;
• infraestrutura de implantação;
• configuração de produção;
• questões jurídicas e operacionais.

Os usuários interagem com o sistema inteiro, não apenas com seus arquivos Solidity.

4. Analise o risco administrativo

Pergunte:

• quem controla as atualizações;
• se as operações podem ser pausadas;
• se taxas ou endereços vinculados podem mudar;
• se existe um timelock;
• se uma multisig é usada;
• como os usuários são informados sobre as alterações.

Essas são questões de governança e confiança, mesmo quando nenhuma vulnerabilidade foi identificada no código.

5. Verifique a segurança depois da auditoria

Entre as medidas contínuas úteis estão:

• testes de cada versão;
• análise de atualizações significativas;
• um programa de recompensa por vulnerabilidades;
• monitoramento de funções e implementações;
• procedimentos de resposta a incidentes;
• limitação do volume de ativos expostos.

O que uma auditoria não garante

Uma auditoria não garante:

• ausência de qualquer erro;
• segurança do código alterado após a revisão;
• segurança do site, da carteira, do DNS ou dos servidores;
• segurança das chaves privilegiadas;
• correção de tokens externos, oráculos e bridges;
• resistência a todos os ataques econômicos;
• integridade de uma equipe;
• conformidade legal;
• liquidez do token;
• devolução de recursos;
• retornos fixos ou de qualquer outro tipo.

Perguntas que um usuário cauteloso deve fazer

Is an auditor’s logo enough?
No. Find the report from the auditor’s own source and check its scope, commit, date, and findings.

If every finding was fixed, is the contract safe?
It means the listed findings were addressed in a stated version. Unknown issues and out-of-scope risks remain.

Are several audits automatically better?
The count alone says little. Coverage, quality, independence, recency, and version matching matter more.

Does an audit still apply after a proxy upgrade?
Only if the new implementation and configuration are covered by the reviewed version.

Lista de verificação do relatório

• O relatório está disponível com o auditor.
• O repositório e o hash do commit estão informados.
• Os contratos e as dependências críticas estão dentro do escopo.
• A versão revisada corresponde à implantação em produção.
• O proxy, a implementação e o administrador estão cobertos.
• O status da constatação e o novo teste estão documentados.
• As premissas e exclusões foram lidas.
• Os riscos externos ao código foram avaliados separadamente.

Fontes e Leitura Complementar

1. Ethereum.org — Segurança de Contratos Inteligentes
2. Ethereum.org — Teste de Contratos Inteligentes
3. Ethereum.org — Verificação Formal de Contratos Inteligentes
4. Solidity Documentation — Considerações de Segurança
5. OpenZeppelin Docs — Padrão de Atualização por Proxy