Token honeypot: li compri ma non li vendi. Come lo fa lo smart contract e come verificarlo

Cos'è un honeypot in una sola frase?

Un honeypot è un token per cui il contratto ti permette l'acquisto, ma la vendita la rende tecnicamente impossibile o la carica di una commissione così alta che dalla vendita non ti resta quasi nulla. Sul grafico sembra un razzo che sale e basta, perché quasi nessuno riesce a vendere.

Importante: in questo testo descriviamo pattern generali nel codice e nei dati, non progetti specifici. Non stiamo dicendo che un qualsiasi token sia una truffa. Mostriamo come funziona il meccanismo e come uno può verificarlo da solo. La meccanica che riportiamo qui deriva dalla documentazione pubblica dello standard ERC-20, dal linguaggio Solidity e dalla documentazione degli exchange decentralizzati (Uniswap, PancakeSwap), a cui rimandiamo nelle fonti.

Come lo fa tecnicamente il contratto?

Un token sulle chain EVM (Ethereum, BNB Chain e simili) è solo uno smart contract. Secondo lo standard ERC-20 il trasferimento del token passa attraverso la funzione transfer o transferFrom (vedi documentazione ERC-20 e OpenZeppelin nelle fonti). Nel corpo di questa funzione il creatore può scrivere in Solidity qualsiasi condizione. Acquisto e vendita, del resto, non sono due funzioni diverse, sono solo trasferimenti tra il tuo wallet e la coppia di liquidità (per esempio su Uniswap o PancakeSwap, la cui meccanica delle coppie è descritta nella loro documentazione). Questa è la chiave: il contratto sa distinguere se i token vanno verso la coppia di liquidità (vendita) oppure dalla coppia verso di te (acquisto), e comportarsi di conseguenza in modo diverso.

I pattern più frequenti che compaiono in questi contratti:

L'elemento comune è che la logica è condizionale e commutabile. Il contratto non deve essere per forza un honeypot dall'inizio. Può diventarlo nel momento in cui il creatore chiama una funzione che limita il trading.

Come appare su un numero concreto?

Immaginiamo un esempio semplificato, puramente illustrativo (non sono dati misurati). Nel contratto immetti 1 ETH e compri 1.000.000 di token. L'acquisto passa senza problemi, perché la tassa d'acquisto è impostata allo 0 %.

Poi provi a rivendere quei 1.000.000 di token. Si presentano due situazioni tipiche:

1. Honeypot duro: la transazione non passa affatto. Il wallet segnala che la transazione è fallita (revert). I tuoi token restano, l'ETH non lo ricevi.
2. Honeypot morbido (a tassa): la vendita passa, ma la tassa sulla vendita è del 99 %. Del valore corrispondente a 1 ETH ti arriva sul conto l'equivalente di 0,01 ETH. Formalmente "potevi vendere", nella realtà hai perso quasi tutto.

La differenza tra questi due casi è importante: l'honeypot morbido spesso supera un test superficiale, perché la vendita tecnicamente funziona. Solo guardando la somma finale si scopre che la tassa ha inghiottito quasi tutto il saldo.

Come si può testare prima di comprare?

Esistono diverse procedure che lavorano solo con dati pubblicamente disponibili. Le descriviamo come strumenti di verifica, non come garanzia.

1. Simulazione della vendita

Alcuni strumenti (honeypot checker, eventualmente simulatori di transazioni) eseguono in un ambiente di test un acquisto simulato e subito una vendita e misurano quanto ritornerebbe. L'output di solito è la tassa d'acquisto stimata, la tassa di vendita e l'informazione se la vendita passa affatto. Limite: la simulazione parte dallo stato attuale del contratto. Se il creatore modifica la logica in seguito, il risultato può non valere più.

2. Lettura del codice sorgente verificato

Sul block explorer (per esempio Etherscan per Ethereum o BscScan per BNB Chain, vedi fonti) per i contratti verificati è visibile il codice Solidity. Pattern da monitorare:

• funzioni che modificano le tasse o le regole di trading dopo il deploy,
• condizioni require all'interno del trasferimento, che sono diverse per acquisto e vendita,
• ruoli di tipo onlyOwner, che permettono al proprietario di intervenire unilateralmente,
• liste di indirizzi (_isBlacklisted e simili).

Se il contratto non è verificato (il codice sorgente non è pubblicato), non si può leggere cosa fa. Questo di per sé non è prova di nulla, ma è un'informazione su ciò che non sai.

3. Sguardo alle vendite reali sulla chain

Nella storia delle transazioni della coppia si può scoprire se qualcuno ha davvero venduto con successo. Quando ci sono molti acquisti e quasi nessuna vendita, è un pattern che merita attenzione. Al contrario, una serie di vendite normali da indirizzi diversi è un segnale che in quel momento la vendita funzionava.

4. Chi detiene e chi può modificare

È utile guardare la distribuzione dei detentori e se la proprietà del contratto è stata rinunciata (renounced), oppure se il proprietario ha ancora il diritto di modificare i parametri. La rinuncia alla proprietà riduce il rischio di una modifica successiva delle regole, ma non esclude che la logica honeypot sia già fissa nel codice.

Perché nemmeno un test pulito è una garanzia?

Perché lo stato del contratto è variabile nel tempo. Tre trappole concrete:

• Modifica temporizzata: oggi acquisto e vendita funzionano entrambi, domani il creatore chiama una funzione che blocca la vendita.
• Tasse a soglia: la tassa aumenta solo dopo aver raggiunto un certo volume o numero di detentori.
• Contratti proxy: la logica si può sostituire tramite un proxy aggiornabile, quindi il codice che hai letto potrebbe non essere più quello che viene eseguito.

Per questo vale il principio che il test dice come si è comportato il contratto al momento del test, non come si comporterà in seguito. Proprio a causa di queste trappole consideriamo il risultato della simulazione e la lettura del codice un forte indizio, non una certezza.

Cosa dovresti ora saper fare e cosa resta incerto

Dopo questa lezione dovresti essere in grado di:

• spiegare perché il contratto riesce a distinguere l'acquisto dalla vendita,
• nominare i pattern base dell'honeypot (blacklist, tassa asimmetrica, blocco della vendita, flag commutabile),
• distinguere l'honeypot duro (la vendita non passa) da quello morbido (la vendita passa, ma la tassa porta via quasi tutto),
• eseguire tre verifiche: simulazione della vendita, lettura del codice verificato e controllo delle vendite reali sulla chain.

Cosa resta incerto e non può essere accertato in modo affidabile in anticipo: come si comporterà il creatore in futuro, se modificherà i parametri e se dietro un contratto proxy non sostituirà la logica. Nessuno strumento dà una certezza al cento per cento, perché lavora con lo stato passato e presente, non con l'intenzione futura.

Questa non è una raccomandazione su cosa fare con i tuoi soldi. È una descrizione della meccanica e dei metodi di verifica, per farti decidere a occhi aperti.