Qu'est-ce qu'un honeypot en une phrase ?
Un honeypot est un token pour lequel le contract vous permet d'acheter, mais rend techniquement impossible la vente, ou la greve d'un frais si eleve qu'il ne vous reste presque rien de la vente. Sur le graphique, cela ressemble a une fusee qui ne fait que monter, parce que presque personne ne peut vendre.
Important : dans ce texte, nous decrivons des schemas generaux dans le code et dans les donnees, pas des projets concrets. Nous ne disons pas que tel ou tel token est une arnaque. Nous montrons comment le mecanisme fonctionne et comment on peut le verifier soi-meme. La mecanique presentee ici s'appuie sur la documentation publique du standard ERC-20, du langage Solidity et de la documentation des bourses decentralisees (Uniswap, PancakeSwap), a laquelle nous renvoyons dans les sources.
Comment le contract s'y prend-il techniquement ?
Un token sur les chaines EVM (Ethereum, BNB Chain et similaires) n'est qu'un smart contract. Selon le standard ERC-20, le transfert d'un token passe par la fonction transfer ou transferFrom (voir la documentation ERC-20 et OpenZeppelin dans les sources). Dans le corps de cette fonction, le createur peut inscrire en Solidity n'importe quelle condition. L'achat et la vente ne sont d'ailleurs pas deux fonctions differentes, ce ne sont que des transferts entre votre portefeuille et la paire de liquidite (par exemple sur Uniswap ou PancakeSwap, dont la mecanique des paires est decrite dans leur documentation). C'est la cle : le contract sait distinguer si les tokens partent vers la paire de liquidite (vente) ou de la paire vers vous (achat), et se comporter differemment selon le cas.
Les schemas les plus frequents qui apparaissent dans de tels contracts :
| Schema | Ce qu'il fait | Comment il se manifeste |
|---|---|---|
| Blacklist / whitelist | Seules les adresses autorisees peuvent transferer | Votre vente revert (echoue) |
| Taxe asymetrique | Achat 0 %, vente 99 % | Vous vendez, mais vous recevez des miettes |
| Blocage lors de la vente vers la paire | require qui echoue quand le destinataire est le liquidity pool |
La vente ne passe pas du tout |
| Flag commutable | Le createur desactive apres coup le trading | L'achat fonctionnait, la vente a cesse plus tard |
| Max transaction / cooldown | Limite si basse que la vente ne passe pas | La transaction revert sur la limite |
Le point commun est que la logique est conditionnelle et commutable. Le contract n'est pas forcement un honeypot des le depart. Il peut le devenir au moment ou le createur appelle une fonction qui restreint le trading.
A quoi cela ressemble-t-il sur un chiffre concret ?
Imaginons un exemple simplifie, purement illustratif (il ne s'agit pas de donnees mesurees). Vous deposez 1 ETH dans le contract et achetez 1 000 000 de tokens. L'achat passe sans probleme, parce que la taxe d'achat est fixee a 0 %.
Ensuite, vous essayez de revendre ces 1 000 000 de tokens. Deux situations typiques se presentent :
- Honeypot dur : la transaction ne passe pas du tout. Le portefeuille signale que la transaction a echoue (revert). Vos tokens restent, vous ne recevez pas d'ETH.
- Honeypot doux (fiscal) : la vente passe, mais la taxe de vente est de 99 %. De la valeur correspondant a 1 ETH, l'equivalent de 0,01 ETH arrive sur votre compte. Formellement, vous avez "pu vendre", mais en realite vous avez presque tout perdu.
La difference entre ces deux cas est importante : le honeypot doux passe souvent un test superficiel, parce que la vente fonctionne techniquement. Ce n'est qu'en regardant le montant final que l'on voit que la taxe a englouti presque tout le solde.
Comment peut-on tester cela avant l'achat ?
Il existe plusieurs procedures qui ne travaillent qu'avec des donnees publiquement accessibles. Nous les decrivons comme des outils de verification, pas comme une garantie.
1. Simulation de vente
Certains outils (honeypot checkers, ou simulateurs de transactions) effectuent dans un environnement de test un achat simule puis immediatement une vente et mesurent combien serait recupere. Le resultat est generalement une taxe d'achat estimee, une taxe de vente et l'information de savoir si la vente passe. Limite : la simulation part de l'etat actuel du contract. Si le createur modifie la logique plus tard, le resultat peut ne plus etre valable.
2. Lecture du code source verifie
Sur un block explorer (par exemple Etherscan pour Ethereum ou BscScan pour BNB Chain, voir les sources), le code Solidity est visible pour les contracts verifies. Schemas a surveiller :
- les fonctions qui modifient les taxes ou les regles de trading apres le deploiement,
- les conditions
requirea l'interieur du transfert, qui different pour l'achat et pour la vente, - les roles de type
onlyOwner, qui permettent au proprietaire d'intervenir unilateralement, - les listes d'adresses (
_isBlacklistedet similaires).
Si le contract n'est pas verifie (le code source n'est pas publie), on ne peut pas lire ce qu'il fait. En soi ce n'est pas une preuve de quoi que ce soit, mais c'est une information sur ce que vous ne savez pas.
3. Regard sur les ventes reelles sur la chaine
Dans l'historique des transactions de la paire, on peut verifier si quelqu'un a reellement reussi a vendre. Quand il y a beaucoup d'achats et presque aucune vente, c'est un schema qui merite attention. A l'inverse, une serie de ventes normales provenant de differentes adresses est un signal qu'a ce moment la vente fonctionnait.
4. Qui detient et qui peut modifier
Il est utile de regarder la repartition des detenteurs et de savoir si la propriete du contract est abandonnee (renounced), ou si le proprietaire a toujours le droit de modifier les parametres. L'abandon de la propriete reduit le risque d'une modification ulterieure des regles, mais n'exclut pas que la logique honeypot soit deja figee dans le code.
Pourquoi meme un test propre n'est-il pas une garantie ?
Parce que l'etat du contract est variable dans le temps. Trois pieges concrets :
- Changement programme : l'achat et la vente fonctionnent aujourd'hui, demain le createur appelle une fonction qui bloque la vente.
- Taxes a seuil : la taxe augmente seulement apres avoir atteint un certain volume ou un certain nombre de detenteurs.
- Contracts proxy : la logique peut etre remplacee via un proxy upgradable, de sorte que le code que vous avez lu n'est peut-etre plus celui qui s'execute.
De ce fait, un test dit comment le contract s'est comporte au moment du test, pas comment il se comportera plus tard. C'est justement a cause de ces pieges que nous considerons le resultat d'une simulation et de la lecture du code comme un indice fort, pas comme une certitude.
Ce que vous devriez maintenant savoir faire et ce qui reste incertain
Apres cette lecon, vous devriez etre capable de :
- expliquer pourquoi le contract sait distinguer l'achat de la vente,
- nommer les schemas de base du honeypot (blacklist, taxe asymetrique, blocage de la vente, flag commutable),
- distinguer le honeypot dur (la vente ne passe pas) du honeypot doux (la vente passe, mais la taxe prend presque tout),
- effectuer trois verifications : la simulation de vente, la lecture du code verifie et le controle des ventes reelles sur la chaine.
Ce qui reste incertain et ne peut pas etre etabli de maniere fiable a l'avance : comment le createur se comportera a l'avenir, s'il modifiera les parametres, et s'il ne remplacera pas la logique derriere un contract proxy. Aucun outil ne donne une certitude a cent pour cent, parce qu'il travaille avec l'etat passe et present, pas avec l'intention future.
Ceci n'est pas une recommandation sur ce qu'il faut faire de votre argent. C'est une description de la mecanique et des methodes de verification, pour que vous decidiez les yeux ouverts.