﻿---
title: "Come identificare i token honeypot"
description: "Checklist pratica per rilevare token acquistabili ma non vendibili: identità del contratto, restrizioni, privilegi, simulazione, liquidità e prova di andata e ritorno."
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.

# Come identificare i token honeypot

> Solo a scopo didattico; non è una consulenza finanziaria. Le cripto-attività possono perdere tutto il valore.

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

## Risposta diretta

Un token honeypot è progettato o configurato per poter essere acquistato ma non venduto normalmente, oppure per essere vendibile solo pagando una commissione estrema. La restrizione può trovarsi nella logica di trasferimento, in un contratto esterno, elenco di indirizzi, interruttore, limite o implementazione aggiornabile.

Nessun singolo risultato di uno scanner dimostra sicurezza. Verifica separatamente rete e indirizzo esatti, codice verificato e ruoli privilegiati; simula l'intero percorso di vendita dal wallet previsto; esamina vendite reali e liquidità; solo dopo valuta un piccolo giro completo la cui perdita totale sia sostenibile.

Un grafico crescente è una prova debole. Se la maggioranza non può vendere, lo storico può mostrare acquisti senza un flusso competitivo di vendite, mentre il prezzo indicato dice poco sul valore realmente estraibile dal pool.

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

## Come funziona

ERC-20 standardizza `transfer` e `transferFrom`, ma non impone la stessa politica a ogni token. Un'implementazione personalizzata può aggiungere condizioni su mittente, destinatario, importo, stato del blocco o altro contratto. Può quindi accettare trasferimenti nel pool e, sul percorso di vendita, annullare, trattenere quasi tutto o bloccare selettivamente l'uscita.

Esamina l'intero percorso di esecuzione. Una vendita su market maker automatizzato può coinvolgere allowance, router, più pool e logica del token. Cerca funzioni controllate da proprietario o ruolo che sospendono scambi, cambiano commissioni o limiti, gestiscono elenchi, sostituiscono router o coppia, coniano offerta o modificano dipendenze.

La rinuncia alla proprietà non è conclusiva. Altri ruoli o controllori possono mantenere poteri e un proxy può conservare l'indirizzo cambiando implementazione. OpenZeppelin precisa che funzioni privilegiate possono coniare, bloccare trasferimenti o aggiornare; un timelock concede preavviso su una modifica programmata.

La simulazione è utile ma limitata. `eth_call` esegue sullo stato di un blocco scelto senza creare transazione; anche `eth_estimateGas` non la inserisce nella chain. Imposta mittente, percorso, importo e contesto reali. Il successo descrive quella chiamata in quello stato, non il blocco seguente o una futura azione amministrativa.

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

## Procedura di verifica

- Conferma rete e indirizzo completo da fonti ufficiali indipendenti. Nell'explorer controlla corrispondenza tra bytecode e sorgente pubblicato e se l'indirizzo è un proxy.

- Segui `transfer` e `transferFrom`, inclusi ereditarietà e richiami esterni. Individua impostazioni delle commissioni, interruttori, massimi per wallet o transazione, elenchi, esenzioni, ruoli, amministratori proxy e ritardi.

- Esamina vendite recenti di indirizzi non collegati. Conferma l'asset di output previsto, non solo lo stato riuscito. Confronta input, output, eventi, commissione effettiva, impatto e riserve.

- Simula la vendita esatta dal wallet previsto nello stato corrente. Se il risultato conta, confronta almeno due strumenti o RPC indipendenti; annullamento, output inspiegabile o forte differenza sono segnali di arresto.

- Se i controlli sono soddisfacenti, prova acquisto e vendita con una somma perdibile integralmente. Verifica saldi finali e ricevute. Non aumentare ripetutamente lo slippage per forzare un'operazione inspiegata.

Il dato economicamente rilevante è il valore recuperabile, non il saldo mostrato:

Valore recuperabile = output swap previsto - impatto sul prezzo - commissione del protocollo - commissione del token - commissione di rete

Le riserve possono rendere difficile l'uscita anche da un token legittimo. Stima l'output alla dimensione prevista; una vendita minima non prova che una maggiore si chiuda vicino al prezzo mostrato.

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

## Segnali d'allarme e limiti

- Le vendite falliscono mentre gli acquisti riescono, oppure vendono solo indirizzi privilegiati o esenti.

- La commissione effettiva è estrema, nascosta, specifica per wallet o modificabile subito.

- Manca il sorgente verificato, non copre l'implementazione attiva o dipende da contratto esterno non verificato.

- La liquidità è scarsa, concentrata presso un controllore o rimovibile senza blocco o ritardo di governance significativo.

- I simulatori discordano, il percorso funziona solo nell'interfaccia del progetto o mancano vendite indipendenti recenti.

Fermati se l'identità è incerta, la vendita è inspiegabile, i privilegi non sono enumerabili o la perdita supera il budget. Ricomprare non è diagnostica. Più Gas può favorire l'inclusione, non aggirare restrizioni; più slippage accetta un prezzo peggiore e può ampliare la perdita.

Una revisione pulita e un giro riuscito provano solo un istante. Riserve, liste, commissioni, dipendenze e logica aggiornabile possono cambiare. Ricontrolla prima di aumentare sensibilmente l'esposizione e considera che nessuna checklist elimina il rischio di contratto o liquidità.

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

## Errori comuni

- **«Sorgente verificato significa sicuro».** La verifica collega sorgente e bytecode; non prova logica benevola né privilegi limitati.

- **«Rinunciare alla proprietà impedisce modifiche».** Ruoli, controllori o amministratori proxy possono mantenere autorità.

- **«Lo scanner dice vendibile, quindi la prossima vendita riuscirà».** Stato, mittente, percorso, blocco, liquidità e implementazione possono differire.

- **«Una piccola vendita prova che uscirà tutta la posizione».** Fasce di commissione, limiti, impatto e riserve finite possono produrre risultati molto diversi.

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

## Argomenti correlati

- [Rischio dei token con commissione di trasferimento](/it/crypto/fee-on-transfer-token-risk/)
- [Come verificare l'indirizzo del contratto](/it/crypto/token-contract-verification/)
- [Simulazione delle transazioni](/it/crypto/transaction-simulation/)
- [Rug pull](/it/crypto/rug-pull/)
- [Checklist slippage e percorso DEX](/it/crypto/dex-slippage-route-checklist/)

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

## Fonti

- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultato: 2026-08-20)
- [API JSON-RPC](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consultato: 2026-08-20)
- [Controllo degli accessi](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin (consultato: 2026-08-20)
- [Modello di aggiornamento proxy](https://docs.openzeppelin.com/upgrades-plugins/proxies) - OpenZeppelin (consultato: 2026-08-20)

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