---
title: "Como identificar tokens honeypot"
description: "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."
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 identificar tokens honeypot

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

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

## 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.

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

## 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.

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

## 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.

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

## 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.

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

## 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.

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

## Tópicos relacionados

- [Risco de token com taxa de transferência](/pt-br/crypto/fee-on-transfer-token-risk/)
- [Como verificar o endereço do contrato](/pt-br/crypto/token-contract-verification/)
- [Simulação de transações](/pt-br/crypto/transaction-simulation/)
- [Rug pulls](/pt-br/crypto/rug-pull/)
- [Checklist de slippage e rota em DEX](/pt-br/crypto/dex-slippage-route-checklist/)

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

## Fontes

- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (acesso: 2026-08-20)
- [API JSON-RPC](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (acesso: 2026-08-20)
- [Controle de acesso](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin (acesso: 2026-08-20)
- [Padrão de upgrade por proxy](https://docs.openzeppelin.com/upgrades-plugins/proxies) - OpenZeppelin (acesso: 2026-08-20)

Source: https://wiki.fcontext.com/pt-br/crypto/honeypot-token-detection/index.mdx