A versão rápida. Uma auditoria de contrato inteligente é uma revisão com prazo limitado de um código específico, em uma versão específica, por pessoas que caçam classes conhecidas de vulnerabilidade. Uma séria reduz o risco de verdade e vale a pena ler. Não é uma garantia, cobre apenas o que estava no escopo, não diz nada sobre o código alterado depois, e não pode lhe dizer o que a equipe pretende fazer com os poderes que manteve.
O que os auditores de fato fazem
Uma auditoria começa com um escopo. O projeto entrega um conjunto definido de arquivos de contrato em um commit definido, além de documentação descrevendo o que o código deve fazer. Tudo fora dessa lista simplesmente não é olhado.
Os revisores então leem o código contra esse comportamento pretendido, caçando os padrões de falha que a área já conhece. Reentrância, erros de controle de acesso, erros aritméticos e de arredondamento, chamadas não verificadas a outros contratos, fontes de preço que podem ser manipuladas, falhas de inicialização e atualização, e suposições que quebram em silêncio quando um token se comporta de forma incomum.
As boas equipes complementam a leitura com ferramentas. Analisadores automáticos pegam erros mecânicos, o fuzzing lança entradas inesperadas no código para quebrar invariantes declaradas, e métodos formais podem provar propriedades estreitas. Nada disso cobre toda a superfície, e os bugs interessantes geralmente vêm de um humano notar que dois componentes discordam sobre algo.
O que sai é uma opinião especializada produzida sob restrições de tempo e escopo. Isso vale muitíssimo mais do que nada, e consideravelmente menos do que uma prova de segurança.
Como um relatório é montado
Quase todo relatório de boa reputação segue a mesma forma, e conhecê-la permite ler o documento em dez minutos em vez de pulá-lo.
A seção de escopo lista os arquivos revisados, o hash do commit e, muitas vezes, as redes-alvo. A seção de metodologia diz quais técnicas foram aplicadas. A seção de achados é a substância: cada problema recebe uma severidade, uma descrição, uma recomendação e um status mostrando o que o projeto fez a respeito.
Muitos relatórios também trazem uma seção sobre papéis privilegiados ou risco de centralização, descrevendo quais endereços podem pausar o sistema, cunhar, atualizar o código ou mover fundos. Leia essa seção primeiro. Ela costuma lhe dizer mais sobre a sua exposição real do que a lista de vulnerabilidades.
A última página é um aviso legal dizendo que a revisão não é uma garantia de segurança. Os auditores são de forma consistente mais honestos sobre os próprios limites do que o marketing construído sobre o trabalho deles.
As quatro coisas que uma auditoria não significa
Não é uma garantia
Os revisores caçam classes conhecidas de bug dentro de um orçamento fixo. Erros lógicos inéditos, designs econômicos que falham apenas sob condições específicas, e interações com contratos que ninguém pensou em modelar podem todos sobreviver a uma revisão cuidadosa. Código auditado já falhou. Descrever algo como auditado é uma afirmação sobre o processo, não sobre o resultado.
Cobre apenas o que estava no escopo
Um relatório sobre um contrato de token não diz nada sobre o contrato de staking que guarda os depósitos, o front end que decide com qual contrato o seu navegador fala, o keeper fora da rede que dispara as ações, ou o oráculo de preços do qual tudo depende. O escopo é onde acontece a maior parte da leitura errada.
Aplica-se ao código que foi revisado
Os achados estão fixados a um commit. Se o código mudou depois, seja para corrigir achados ou para adicionar funções, os contratos implantados não são os contratos revisados. Sistemas atualizáveis agravam isso, porque a implementação por trás de um endereço pode ser trocada por algo que ninguém revisou.
Não diz nada sobre intenções
Uma auditoria checa se o código faz o que diz. Ela não pode lhe dizer se as pessoas com as chaves de administração vão se comportar bem. Um contrato pode ser escrito de forma impecável e ainda permitir que quem o controla esvazie os depósitos; uma revisão que documenta esse poder cumpriu o seu trabalho ao lhe dizer que ele existe.
Como ler uma corretamente
Comece encontrando o documento real em vez da afirmação sobre ele. Os relatórios normalmente ficam no próprio site do auditor ou em um repositório público. Se um projeto só liga para uma captura de tela ou um logo, sem contrapartida do auditor, trate isso como não verificado.
Depois verifique se o escopo corresponde ao que você usaria. Compare os endereços de contrato ou o hash do commit do relatório contra o código-fonte verificado em um explorador de blocos. Se o código-fonte do contrato implantado não estiver verificado, ninguém fora da equipe pode confirmar o que está rodando.
Percorra os achados por severidade e, mais importante, por resolução. “Corrigido” com um commit de acompanhamento é um resultado real. “Reconhecido” significa que o projeto leu o achado e escolheu conviver com ele, o que às vezes é razoável e às vezes é a linha mais reveladora do documento.
Segurança: Trate uma auditoria como uma entrada, nunca como permissão para pular as suas próprias checagens. Antes de comprometer fundos a qualquer contrato, confirme que você chegou ao site digitando você mesmo o endereço, leia quais aprovações de token ele está pedindo, e comece com um valor cuja perda não mudaria a sua semana. Nosso guia sobre aprovações de token explica por que esse meio-termo importa tanto.
Por que um selo em uma landing page não prova nada
Um logo de auditoria é um arquivo de imagem. Adicionar um a um site leva segundos, não exige permissão e cria uma impressão de escrutínio que pode não ter documento algum por trás.
Mesmo quando um relatório existe, o selo achata todo o detalhe que importava. Ele não lhe diz o escopo, a severidade do que foi encontrado, se algo foi corrigido, ou se a versão revisada é aquela com a qual você interagiria. Vários logos também não são várias garantias, já que várias revisões superficiais do mesmo contrato estreito acrescentam pouco.
A frase “auditoria em andamento” merece um ceticismo particular, porque transforma um processo inacabado em um sinal de confiança. O mesmo vale para uma revisão feita por uma empresa sem um corpo de trabalho publicado.
Onde as auditorias encaixam nas suas próprias checagens
Uma auditoria é evidência de que um projeto gastou dinheiro em escrutínio e publicou os resultados, o que é um sinal significativo sobre a seriedade. Ela fica ao lado das coisas que você pode verificar por conta própria: quem controla as chaves de atualização, se há um timelock, e se o código-fonte do contrato inteligente está verificado.
O hábito que mais ajuda é tratar cada afirmação como algo a confirmar em vez de aceitar, que é o método que estabelecemos em como verificar uma afirmação cripto. Nossa lição sobre avaliar um projeto cripto cobre o quadro mais amplo, e o texto sobre por que as pontes continuam sendo hackeadas mostra como sistemas revisados ainda falham quando um componente é mais fraco do que o resto.
Pontos principais
- Uma auditoria é uma revisão especializada delimitada e com prazo limitado de um código específico em um commit específico, não uma garantia.
- As seções de escopo e de papéis privilegiados costumam lhe dizer mais sobre a sua exposição do que a contagem de severidade da manchete.
- Os achados marcados como reconhecidos em vez de corrigidos são os que vale a pena ler com atenção.
- O código implantado pode diferir do revisado, sobretudo em sistemas atualizáveis, então verifique você mesmo os endereços e o código-fonte verificado.
Perguntas frequentes
Se um protocolo é auditado, o meu dinheiro está seguro?
Não. Uma auditoria reduz a chance de uma classe conhecida de bug sobreviver até a produção, o que é valioso, mas não pode descartar falhas inéditas, fracassos econômicos nem o mau uso dos poderes de administração. Protocolos auditados já foram explorados. Leia o relatório para ver o que foi checado e o que foi deixado de fora, e então decida quanta exposição combina com você.
O que significa quando um achado está reconhecido em vez de corrigido?
Significa que os revisores levantaram um problema e o projeto decidiu não mudar o código. Às vezes isso é razoável, porque a correção custaria mais do que o risco ou o comportamento é intencional. Às vezes significa que uma fraqueza real continua ali por escolha. De todo modo, o risco residual se transfere para você, então leia com atenção o raciocínio declarado.
Como verifico se o contrato implantado corresponde ao código auditado?
Consulte o endereço do contrato em um explorador de blocos para aquela rede e veja se o código-fonte está verificado ali. Compare-o com o commit ou os endereços nomeados na seção de escopo do relatório. Se o contrato for atualizável, descubra quem pode mudar a implementação e se um atraso se aplica, já que isso rege quanto a revisão ainda lhe diz.
Fontes
Conteúdo educativo, não é aconselhamento financeiro. Nunca compartilhe sua frase-semente nem suas chaves privadas com ninguém — nem mesmo com alguém que diga ser a CoinCrafty.
Última atualização 30 julho 2026
Sidhartha Shukla covers crypto and business markets for CoinCrafty.
