Contenu éducatif uniquement, sans conseil en investissement. Les cryptoactifs peuvent perdre toute leur valeur.
Réponse directe
Un jeton honeypot est conçu ou configuré pour être acquis mais pas revendu normalement, ou seulement moyennant des frais extrêmes. La restriction peut résider dans la logique de transfert, un contrat externe, une liste d’adresses, un commutateur, une limite ou une implémentation évolutive.
Aucun résultat de scanner isolé ne prouve la sécurité. Vérifiez séparément la chaîne et l’adresse exactes, le code vérifié et les rôles privilégiés ; simulez tout le parcours de vente depuis le portefeuille prévu ; examinez les ventes réelles et la liquidité ; puis seulement envisagez un petit aller-retour dont la perte totale est acceptable.
Un graphique haussier est une preuve faible. Si la majorité ne peut vendre, l’historique peut afficher des achats sans flux concurrentiel de ventes, et le prix affiché renseigne peu sur la valeur pouvant réellement sortir du pool.
La réalisation de cet examen ne prouve pas qu'un actif, une transaction ou un système est sûr.
Fonctionnement
ERC-20 normalise transfer et transferFrom, sans imposer une politique identique. Une implémentation personnalisée peut ajouter des conditions sur l’expéditeur, le destinataire, le montant, l’état du bloc ou un autre contrat. Elle peut donc accepter les transferts vers le pool, mais annuler, confisquer presque tout ou bloquer sélectivement la sortie lors d’une vente.
Examinez le parcours complet, pas seulement un nom de fonction. Une vente sur teneur de marché automatisé peut inclure autorisation, routeur, plusieurs pools et logique du jeton. Recherchez les fonctions contrôlées par propriétaire ou rôle qui suspendent les échanges, modifient frais ou limites, gèrent les listes, remplacent routeur ou paire, émettent des jetons ou changent une dépendance.
La renonciation à la propriété n’est pas concluante. D’autres rôles ou contrôleurs peuvent conserver des droits ; un proxy peut garder l’adresse tout en changeant d’implémentation. OpenZeppelin précise que les fonctions privilégiées peuvent émettre, geler des transferts ou effectuer une mise à niveau ; un délai donne un préavis avant un changement programmé.
La simulation est utile mais limitée. eth_call s’exécute sur l’état d’un bloc choisi sans créer de transaction ; eth_estimateGas ne l’ajoute pas non plus à la chaîne. Définissez expéditeur, parcours, montant et contexte réels. Le succès décrit cet appel dans cet état, pas le bloc suivant ni une action administrative future.
Parcours de vérification
-
Confirmez réseau et adresse complète auprès de sources officielles indépendantes. Dans l’explorateur, vérifiez la correspondance bytecode-source publiée et si l’adresse est un proxy.
-
Suivez
transferettransferFrom, héritage et appels externes inclus. Identifiez réglages de frais, commutateurs, plafonds par portefeuille ou transaction, listes, exemptions, rôles, administrateurs proxy et délais. -
Examinez les ventes récentes d’adresses sans lien. Confirmez l’actif de sortie attendu, pas seulement un statut réussi. Comparez entrée, sortie, événements, frais effectifs, impact et réserves.
-
Simulez la vente exacte depuis le portefeuille prévu dans l’état actuel. Si l’enjeu est important, comparez au moins deux outils ou RPC indépendants ; annulation, sortie inexpliquée ou écart majeur imposent l’arrêt.
-
Si les contrôles sont satisfaisants, testez achat et vente avec une somme entièrement perdable. Vérifiez soldes finaux et reçus. N’augmentez pas plusieurs fois le slippage pour forcer une opération inexpliquée.
La mesure économique pertinente est la valeur récupérable, pas le solde affiché :
Valeur récupérable = sortie attendue du swap - impact sur le prix - frais du protocole - frais du jeton - frais réseau
Les réserves peuvent compliquer la sortie d’un jeton légitime. Estimez la sortie à la taille prévue ; une vente minime ne prouve pas qu’une plus grande passera près du prix affiché.
Signaux d’alerte et limites
-
Les ventes sont constamment annulées alors que les achats réussissent, ou seules les adresses privilégiées et exemptées vendent.
-
Les frais effectifs sont extrêmes, cachés, propres au portefeuille ou immédiatement modifiables.
-
Le code vérifié manque, ne couvre pas l’implémentation active ou dépend d’un contrat externe non vérifié.
-
La liquidité est faible, concentrée chez un contrôleur ou retirable sans verrouillage ni délai de gouvernance significatif.
-
Les simulateurs divergent, le parcours ne fonctionne que dans l’interface du projet ou les preuves de ventes indépendantes récentes manquent.
Arrêtez si l’identité est incertaine, la vente inexpliquée, les privilèges non énumérables ou la perte supérieure au budget. Racheter ne diagnostique rien. Plus de Gas peut favoriser l’inclusion, sans contourner une restriction ; plus de slippage accepte un pire prix et peut aggraver la perte.
Un examen propre et un aller-retour réussi ne prouvent qu’un instant. Réserves, listes, frais, dépendances et logique évolutive peuvent changer. Revérifiez avant toute hausse sensible d’exposition et supposez qu’aucune liste ne supprime les risques de contrat ou de liquidité.
Idées reçues
-
« Source vérifiée signifie sécurité. » La vérification relie source et bytecode ; elle ne prouve ni logique bienveillante ni privilèges limités.
-
« Renoncer à la propriété empêche tout changement. » Rôles, contrôleurs ou administrateurs proxy peuvent conserver l’autorité.
-
« Le scanner indique vendable, donc la prochaine vente marchera. » État, expéditeur, parcours, bloc, liquidité et implémentation peuvent différer.
-
« Une petite vente prouve que toute la position sortira. » Paliers de frais, limites, impact et réserves finies peuvent produire un résultat très différent.
Sujets connexes
- Risque des jetons à frais de transfert
- Vérifier l’adresse du contrat
- Simulation de transaction
- Rug pulls
- Liste slippage et parcours DEX
Sources
- ERC-20: Token Standard - Ethereum Improvement Proposals (consulté le 2026-08-20)
- API JSON-RPC - Ethereum.org (consulté le 2026-08-20)
- Contrôle d’accès - OpenZeppelin (consulté le 2026-08-20)
- Modèle de mise à niveau par proxy - OpenZeppelin (consulté le 2026-08-20)