Um exploit de contrato inteligente abusa de uma falha no código, no desenho econômico, nas permissões ou em uma dependência externa para produzir um resultado não previsto — muitas vezes drenando ou congelando ativos. Ele difere do roubo comum de chaves porque o invasor pode usar regras válidas do contrato em uma sequência inesperada.
Comece pelo modelo de risco#
Classes comuns de exploit incluem falhas de controle de acesso, manipulação de oráculo de preços, reentrância, erros contábeis, upgrades inseguros e chaves administrativas comprometidas. A perda visível pode ser apenas a etapa final de uma falha mais longa entre dependências.
Faça uma checagem de autoridade e contenção#
O usuário deve avaliar se o protocolo consegue pausar, atualizar ou recuperar ativos e quem controla esses poderes. Os mesmos controles administrativos podem reduzir um incidente ou criar o risco que o tornou possível.
Siga uma resposta estruturada#
- Identifique o contrato afetado e a versão implantada. Compare endereço, rede e commit com fontes oficiais independentes.
- Interrompa interações e revogue aprovações relacionadas se fontes verificadas recomendarem. Use uma ferramenta confiável e confira cada transação.
- Descubra se o front-end, o contrato ou uma chave administrativa foi afetado. As ações necessárias são diferentes em cada caso.
- Acompanhe atualizações oficiais do incidente e preserve provas das transações. Guarde horários, endereços, hashes e versões sem editar os originais.
- Não confie em links não solicitados de reembolso ou recuperação. Golpistas imitam a comunicação de crise para obter novas assinaturas.
Onde as pessoas erram#
- Presumir que uma auditoria cobriu todas as dependências. Oráculos, bridges, governança e front-end podem estar fora do escopo.
- Depositar durante um incidente não resolvido por causa de rendimento maior. O prêmio pode refletir justamente o risco de insolvência ou congelamento.
- Assinar uma “migração emergencial” vinda de respostas em redes sociais. Volte ao canal oficial por uma rota independente.
- Confundir perda de mercado com exploit de código. Determine a causa antes de trocar chaves, mover fundos ou conceder permissões.
Uma resposta segura não é apenas concluir uma transação. Você precisa confirmar o contrato, reproduzir os fatos e preservar caminhos de recuperação se o serviço falhar.
Confirme o resultado#
Não julgue a resposta apenas pela mensagem da interface. Use evidências que continuem verificáveis depois de fechar a página.
| Ponto de controle | Evidência | Condição para parar |
|---|---|---|
| Identificar contrato e versão | Endereço e URL comparados à documentação | A análise presume que a auditoria cobriu tudo |
| Pausar e revogar quando orientado | Hash e registro no explorador correspondente | O incidente segue aberto, mas incentivam novo depósito |
| Separar front-end, contrato e chave admin | Comunicado oficial e dados on-chain | O link de migração vem de resposta social |
Guarde hashes de transação, protocolos oficiais ou capturas datadas quando ajudarem a documentar o incidente, mas exclua frases-semente, chaves privadas e códigos de autenticação.
Perguntas frequentes#
Um contrato explorado pode ser corrigido?
Sistemas atualizáveis podem ser alterados, enquanto implantações imutáveis talvez exijam migração. A recuperação depende do desenho e do controle restante.
Código aberto impede exploits?
Não. Ele permite revisão, mas não garante que todos os bugs ou interações econômicas sejam encontrados.
Devo revogar aprovações após um exploit?
Se o spender afetado puder usá-las, a revogação reduz exposição futura. Confirme a rede e siga a orientação oficial.
Guias relacionados#
Fontes#
Aviso de risco: Ações com criptomoedas podem ser irreversíveis. Nunca compartilhe frase-semente, chave privada, senha ou código de autenticação e verifique cada domínio e solicitação da carteira de forma independente.
Padrão editorial
Este guia é educativo e baseado em fontes. Controles de segurança, regras das corretoras e exigências legais podem mudar; confirme etapas importantes em fontes oficiais.
