---
title: "Como interpretar uma auditoria de smart contracts"
description: "Uma auditoria de smart contracts é uma revisão delimitada de código, builds, implantações, premissas e propriedades especificadas; achados e correções devem ser conciliados com o sistema em produção."
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 interpretar uma auditoria de smart contracts

> Somente para fins educacionais; não constitui aconselhamento de investimento ou segurança. Relatório, resultado de ferramenta, achado resolvido ou fonte correspondente não é certificação, seguro, indenização nem prova de segurança da implantação.

<a id="answer"></a>

## Resposta direta

Uma auditoria examina, por período declarado, requisitos, código, entradas de build, lógica de implantação e premissas especificadas. Métodos complementares identificam defeitos, demonstram exploits, avaliam impacto e conferem correções. A conclusão vale apenas para o snapshot e as evidências do relatório.

O snapshot fixa repositório e commit ou tree hash, submódulos, dependências, compilador, configurações, código gerado, scripts, chains, endereços, proxy, implementação ou beacon, constructor ou initializer, bibliotecas, administradores, timelocks e bloco ou hora. Exclusões importam: frontend, keeper, oracle, bridge, governança ou signatário off-chain podem dominar o risco fora do escopo.

São necessários threat model e especificação: ativos, atores, papéis, fronteiras de confiança, capacidades, ordenação, reorgs, dependências, transições e propriedades de safety e liveness. Invariante sem unidades, precondições, quantificadores e exceções pode verificar perfeitamente a conduta errada.

Use quatro registros: identidade de escopo, build e implantação; requisitos, ameaças e invariantes; achados, evidências e reteste; risco residual, aceitação e divulgação. Ausência de `critical` não certifica segurança, `resolved` não implica implantação e uma prova cobre apenas propriedade, modelo e premissas codificados.

<a id="mechanism"></a>

## Como funciona

Revisão manual acompanha arquitetura, fundos, estado entre funções e intenção econômica. Análise estática detecta padrões e fluxos, mas gera falsos positivos e negativos. Testes unitários, integração, fork e diferenciais comparam condutas concretas. Fuzzing com estado e invariantes dependem de handlers, seletores, seeds, corpus, execuções, profundidade e ambiente modelado.

Execução simbólica e verificação formal demonstram asserções selecionadas sob semântica e premissas compatíveis. Resultado `unknown`, timeout ou comportamento sem suporte não é prova. Mesmo uma propriedade provada pode omitir economia do oracle, governança, configuração, chain ou requisito pretendido. A revisão humana responde pela especificação; observação de IA não é método independente.

Cada achado identifica artefato e implantação, pré-requisito, PoC mínimo, caminho, alcance, privilégios, capital, repetibilidade, impacto, rubrica e recomendação. Explorabilidade ou probabilidade e impacto são dimensões separadas. Máximo teórico, nome da falha ou etiqueta de ferramenta não estabelece perda executável.

`open`, `acknowledged`, `risk accepted`, `partially fixed`, `resolved` e `retested` não são padrões universais. Fechamento defensável liga o problema ao commit exato, registra caminhos alterados e adjacentes e quem retestou o quê e quando. Risco aceito continua risco; reteste limitado não amplia o escopo.

Implantações atualizáveis exigem conciliação: slots do proxy, implementação ou beacon e admin; initializer/reinitializer, bloqueio da implementação, compatibilidade de storage, autorização, timelock ou bypass, migração e rollback. Reproduza bytecode de criação e runtime e compare bibliotecas, parâmetros, papéis e estado em cada chain.

O relatório final informa revisão, auditores, datas, escopo, métodos, configurações, limites, achados, evidências, remediação, riscos e divulgação. Depois, monitore hashes, papéis, parâmetros, dependências e incidentes. Mudança material cria novo delta; badge antigo não acompanha código futuro.

Fluxo:

1. Congele manifesto: repositório, commit, dependências, compilador, configurações, código gerado e de implantação, chains, endereços, proxy, parâmetros, bloco, revisão, inclusões e exclusões.
2. Defina ativos, atores, papéis, fronteiras, capacidades, ciclo de vida, ordenação, liveness, dependências e invariantes mensuráveis.
3. Reproduza o build e mapeie arquitetura, storage, dados, fundos e controle; concilie fonte, artefatos, bibliotecas, bytecode, initializer, papéis e implantação.
4. Execute métodos manuais, estáticos, unitários, integração, fork, diferenciais, fuzz, invariantes, simbólicos ou formais, registrando versões, configurações, seeds, corpus, cobertura, timeouts e incógnitas.
5. Registre artefato, pré-requisito, prova, explorabilidade, impacto, severidade, exposição, recomendação e evidência confidencial sem tratar etiqueta como julgamento.
6. Congele a correção e reteste problema, caminhos e invariantes; valide storage, inicialização, migração, rollback, build e recibos antes de atribuir status.
7. Publique escopo, métodos, limites e riscos; concilie artefatos em cada chain e mantenha monitoramento, divulgação, resposta e bug bounty atuais.

<a id="example"></a>

## Exemplos

- **Inflação de vault exige registro completo.** O atacante deposita `1 asset`, recebe `1 share` e doa `1,000,000 assets`; ficam `1,000,001 assets` e `1 share`. A vítima deposita `500,000 assets`; o piso inseguro dá `floor(500,000 * 1 / 1,000,001) = 0 shares`. Se aceito, há `1,500,001 assets`; o atacante resgata e ganha `500,000 assets` sobre sua contribuição de `1,000,001-asset`. Se zero shares reverte, a perda não ocorre.
- **Cobertura de arquivos não é cobertura da implantação.** Há `24 source units`, `4 deployment scripts` e `3 keeper services`: `31 items`. Entram `20 source units` e `2 scripts`; cobertura `22 / 31 = 70.96774194%`, com `9 items` excluídos. Se o proxy usa unidade excluída, a implementação tem `0%` apesar de `70.96774194%`.
- **Fuzz não prova ausência.** A execução faz `2,000 sequences * 64 calls = 128,000 calls`; falha em `3 sequences`, ou `3 / 2,000 = 0.15%`. Após correção, `10,000 sequences * 64 calls = 640,000 calls` não falham. É zero no corpus; sob independência e gerador estável, o limite aproximado de `95%` é `3 / 10,000 = 0.03%` por sequência.
- **Fechamento e identidade são independentes.** Há `12 findings`: `2 critical`, `3 high`, `4 medium`, `3 low`. Fecham `2 + 2 + 3 + 2 = 9`: `9 / 12 = 75%`; restam high, medium e low. Hash auditado `H1`, implantação `H2`: verificação falha. Trocar por `H1` e conciliar slot, initializer e papéis prova identidade só no bloco.

<a id="risks"></a>

## Riscos

- Repositório, commit, submódulo ou fonte gerada são ambíguos.
- Compilador, otimizador, bibliotecas ou dependências não estão fixados.
- Scripts, constructor, initializer ou salt CREATE2 são excluídos.
- Chain, endereço, proxy, beacon ou implementação errados são inspecionados.
- Fonte, artefato e bytecode não conciliam.
- Threat model omite ator, privilégio, ativo ou fronteira.
- Especificação ou invariante tem unidades, precondições ou exceções erradas.
- Caminhos de admin, guardian, timelock, pausa, upgrade ou migração são omitidos.
- Premissas de oracle, token, bridge, keeper, governança ou chain falham.
- Análise estática gera falso positivo sem triagem.
- Revisão, teste ou fuzzing omite caminho não gerado.
- Harness, selector, seed, corpus, profundidade ou modelo são enviesados.
- Timeout, semântica sem suporte ou `unknown` são tratados como prova.
- Prova correta formaliza requisito ou sistema incompleto.
- Severidade é ancorada no nome, não em explorabilidade e impacto.
- Valor teórico é confundido com perda alcançável ou lucro.
- Correção introduz regressão ou quebra invariante econômico.
- Storage, initializer, upgrade ou migração corrompem estado.
- Problema aceito, aberto ou parcial é ocultado pelo badge.
- Relatório é tratado como seguro, certificação ou cobertura permanente.

<a id="misconceptions"></a>

## Erros comuns

- **“Sem critical, o contrato é seguro.”** Só descreve achados no escopo, tempo e métodos.
- **“Alta cobertura ou zero falhas fuzz provam ausência.”** Medem código e caminhos selecionados.
- **“Verificação formal prova todo o protocolo.”** Prova propriedades do modelo sob premissas.
- **“Resolved significa todas as implantações corrigidas.”** Exige reteste e conciliação de build, bytecode, proxy, parâmetros e papéis.
- **“Auditor reputado garante indenização ou upgrades.”** Responsabilidade depende do contrato e mudanças posteriores ficam fora.

<a id="related"></a>

## Tópicos relacionados

- [Smart contract](/pt-br/crypto/smart-contract/)
- [Contrato atualizável](/pt-br/crypto/upgradeable-contract/)
- [Bug bounty](/pt-br/crypto/bug-bounty/)

<a id="sources"></a>

## Fontes

- [OWASP Smart Contract Security Verification Standard (SCSVS)](https://scs.owasp.org/SCSVS/) - OWASP (acessado em: 2026-08-13)
- [Security Considerations](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity (acessado em: 2026-08-13)
- [Slither, the smart contract static analyzer](https://github.com/crytic/slither) - Crytic (acessado em: 2026-08-13)
- [Invariant Testing](https://www.getfoundry.sh/guides/invariant-testing) - Foundry (acessado em: 2026-08-13)
- [Certora User's Guide](https://docs.certora.com/en/latest/docs/user-guide/index.html) - Certora (acessado em: 2026-08-13)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (acessado em: 2026-08-13)
- [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (acessado em: 2026-08-13)
- [Contract Metadata](https://docs.soliditylang.org/en/latest/metadata.html) - Solidity (acessado em: 2026-08-13)

Source: https://wiki.fcontext.com/pt-br/crypto/contract-audit/index.mdx