Ir para o conteúdo
Financial Context Wiki

Como identificar tokens honeypot

Checklist prático para detectar tokens que podem ser comprados, mas não vendidos, cobrindo identidade do contrato, restrições, poderes administrativos, simulação, liquidez e teste de ida e volta.

Atualizado

Conteúdo exclusivamente educacional; não é recomendação de investimento. Criptoativos podem perder todo o valor.

Resposta direta

Um token honeypot é projetado ou configurado para permitir a aquisição, mas impedir a venda normal, ou só permiti-la após uma taxa extrema. A restrição pode estar na lógica de transferência, em contrato externo, lista de endereços, chave de negociação, limite ou implementação atualizável.

Nenhum resultado isolado de scanner prova segurança. Confirme rede e endereço exatos, examine código verificado e papéis privilegiados, simule toda a rota de venda a partir da carteira pretendida, confira vendas reais e liquidez e só então considere uma pequena ida e volta cuja perda integral seja aceitável.

Um gráfico ascendente é evidência fraca. Se a maioria não vende, o histórico pode exibir compras sem fluxo competitivo de vendas, e o preço mostrado pouco revela quanto valor consegue sair do pool.

Como identificar tokens honeypot
0 / 5
0 itens revisados; 5 itens ainda não resolvidos

A conclusão desta revisão não prova que um ativo, transação ou sistema seja seguro.

Como funciona

O ERC-20 padroniza transfer e transferFrom, mas não exige política idêntica. Uma implementação personalizada pode condicionar remetente, destinatário, valor, estado do bloco ou outro contrato. Assim, pode aceitar transferências ao pool e reverter, confiscar quase tudo ou bloquear seletivamente a saída pela rota de venda.

Revise toda a execução. Uma venda em formador de mercado automatizado pode envolver aprovação, roteador, vários pools e a lógica do token. Procure funções controladas por proprietário ou papel que pausam operações, alteram taxas ou limites, gerenciam listas, substituem roteador ou par, emitem oferta ou mudam dependências.

Renúncia à propriedade não é conclusiva. Outros papéis ou controladores podem permanecer, e o proxy pode manter o endereço enquanto troca a implementação. A documentação da OpenZeppelin observa que privilégios podem emitir, congelar transferências ou atualizar; um timelock dá aviso antes de uma mudança programada.

A simulação tem limites. eth_call executa no estado de um bloco escolhido sem criar transação; eth_estimateGas também não a inclui na rede. Defina remetente, rota, valor e contexto reais. O sucesso descreve aquela chamada naquele estado, não o próximo bloco ou ação administrativa futura.

Fluxo de verificação

  • Confirme rede e endereço completo em fontes oficiais independentes. No explorador, verifique correspondência entre bytecode e código publicado e se o endereço é proxy.

  • Rastreie transfer e transferFrom, incluindo herança e chamadas externas. Identifique ajustes de taxa, chaves, máximos por carteira ou transação, listas, isenções, papéis, administradores de proxy e atrasos.

  • Examine vendas recentes de endereços sem relação. Confirme a geração do ativo esperado, não apenas status de sucesso. Compare entrada, saída, eventos, taxa efetiva, impacto e reservas.

  • Simule a venda exata da carteira pretendida no estado atual. Compare pelo menos duas ferramentas ou RPC independentes quando relevante; reversão, saída sem explicação ou grande diferença é sinal para parar.

  • Se tudo estiver satisfatório, teste compra e venda com valor que possa perder integralmente. Confira saldos finais e recibos. Não aumente repetidamente a slippage para forçar operação inexplicada.

A medida econômica relevante é o valor recuperável, não o saldo exibido:

Valor recuperável = saída esperada do swap - impacto no preço - taxa do protocolo - taxa do token - taxa de rede

Reservas também podem dificultar a saída de token legítimo. Estime a saída no tamanho pretendido; uma venda mínima não prova que outra maior execute perto do preço exibido.

Sinais de alerta e limites

  • Vendas revertem enquanto compras funcionam, ou apenas endereços privilegiados e isentos vendem.

  • A taxa efetiva é extrema, não divulgada, específica da carteira ou alterável imediatamente.

  • Não há código verificado, ele não cobre a implementação ativa ou depende de contrato externo não verificado.

  • A liquidez é rasa, controlada por uma parte ou removível sem bloqueio ou atraso de governança relevante.

  • Simuladores divergem, a rota só funciona em interface do projeto ou faltam vendas independentes recentes.

Pare se a identidade for incerta, a venda não puder ser explicada, privilégios não puderem ser enumerados ou a perda superar o orçamento. Comprar mais não é diagnóstico. Mais Gas pode ajudar inclusão, não contornar restrição; mais slippage aceita preço pior e pode ampliar perdas.

Revisão limpa e ida e volta bem-sucedida só provam um instante. Reservas, listas, taxas, dependências e lógica atualizável podem mudar. Revise antes de aumentar materialmente a exposição e presuma que nenhum checklist elimina risco de contrato ou liquidez.

Equívocos comuns

  • “Código verificado significa seguro.” A verificação liga código e bytecode; não prova lógica benigna nem privilégios limitados.

  • “Renunciar à propriedade impede mudanças.” Papéis, controladores ou administradores de proxy podem manter autoridade.

  • “O scanner diz vendável, então a próxima venda funciona.” Estado, remetente, rota, bloco, liquidez e implementação podem diferir.

  • “Uma venda pequena prova que toda a posição sai.” Faixas de taxa, limites, impacto e reservas finitas podem gerar resultado muito diferente.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...