Pourquoi vérifier un token compte plus que lire un graphique
La plupart des gens qui perdent de l'argent sur un nouveau token n'ont pas mal lu le graphique. Ils ont acheté le mauvais token. Les moteurs de recherche, les groupes Telegram et les bots de réponse sont inondés de tickers imités, et un seul caractère erroné dans une adresse collée envoie les fonds vers un contrat que l'acheteur ne pourra jamais vendre. Ce schéma est si courant que les firmes d'analyse on-chain le qualifient désormais de première catégorie de pertes retail en 2024 et 2025, devant les liquidations et devant les ordres limites qui échouent.
La bonne nouvelle, c'est que la vérification ne demande pas de compétences en sécurité. Elle demande de la patience et une volonté de renoncer à un trade lorsqu'une vérification échoue. La mauvaise nouvelle, c'est que chaque étape a un véritable mode d'échec, et sauter l'une d'elles laisse un trou dans lequel un attaquant se fera un plaisir de s'engouffrer. La liste ci-dessous est le minimum que les traders DEX expérimentés exécutent réellement, dans l'ordre où ils l'exécutent.
Ce qui peut mal tourner : le panorama des risques avant de commencer
Il existe quatre formes d'arnaque qu'une checklist de vérification est conçue pour détecter, et une cinquième qu'aucune checklist ne détecte. Connaître la différence est ce qui sépare un acheteur occasionnel de quelqu'un qui protège ses fonds.
L'arnaque au copier-coller. Un token portant le même nom et le même ticker qu'un projet légitime est déployé quelques heures avant un lancement très attendu. L'adresse est postée dans les réponses, sur Telegram et dans des annonces sponsorisées. L'achat fonctionne, le prix bouge pendant dix minutes, puis les ventes échouent. Le contrat est un honeypot, la liquidité appartient à une seule adresse, et le déployeur a déjà orchestré de nombreux rug pulls identiques.
Le contrat avec mint caché. Un token est lancé avec une offre équitable, fonctionne pendant quelques semaines, puis l'équipe frappe un nouveau lot massif dès que le volume grimpe. Les nouveaux tokens arrivent dans le pool, le prix s'effondre à zéro, et les détenteurs initiaux découvrent que l'équipe peut imprimer de l'offre à volonté. Le contrat disposait dès le départ d'une fonction mint ; personne n'a lu le code source.
Le déversement via portefeuille d'équipe verrouillé. Un token est lancé avec les tokens de l'équipe verrouillés dans un contrat de vesting. Le prestataire du verrouillage est compromis, ou le déverrouillage est un multisig contrôlé par l'équipe, ou la date de déverrouillage a été mal lue. L'équipe vend lors du premier vrai rallye et le graphique ne s'en remet jamais.
Le déployeur compromis. Un projet légitime est lancé, gagne en traction, puis le hot wallet d'un membre de l'équipe est victime de phishing. L'attaquant utilise les privilèges du déployeur pour appeler des fonctions sensibles, souvent en pause du trading, en modification des frais ou en retrait de la liquidité. Le contrat est exactement celui que l'équipe a écrit ; il n'a jamais été sûr de faire confiance à une clé chaude.
Ce qu'aucune checklist ne détecte : une équipe honnête qui simplement n'a plus d'argent, qui se fait écraser par les market makers, ou qui décide d'arrêter de soutenir le projet. La vérification vous protège du contrat. Elle ne vous protège pas d'un mauvais business.
Étape 1 : obtenir l'adresse depuis la source officielle du projet
La première règle de la vérification de contrat, c'est qu'on ne vérifie jamais un contrat sans avoir une adresse fiable à laquelle le comparer. Les résultats de recherche, les réponses sur X, les messages épinglés sur Telegram et les annonces Discord venant de quelqu'un d'autre qu'un membre de l'équipe principale ne sont pas des sources fiables, car ils peuvent être modifiés, usurpés ou achetés. L'adresse de départ doit provenir de l'un de ces trois endroits : le site officiel du projet, un domaine que l'équipe contrôle depuis avant le lancement du token, ou une page d'explorateur de blocs vers laquelle l'équipe renvoie depuis ce domaine.
Ouvrez le site du projet dans un nouvel onglet. Tapez le domaine à la main, ne suivez pas un lien. Cherchez une page « token », « contrat » ou « trade ». L'adresse qui s'y trouve est votre point de départ. Si le site n'affiche pas d'adresse de contrat, c'est déjà en soi un signal d'alerte : les projets légitimes indiquent presque toujours l'adresse de manière visible. Si une publicité dans les résultats de recherche est le seul endroit où apparaît une adresse de contrat, traitez l'ensemble du projet comme suspect.
Une fois l'adresse obtenue, copiez-la avec soin. Toute adresse de style Ethereum comporte 42 caractères et commence par 0x. Un seul caractère erroné envoie la transaction vers un contrat qui renverra probablement une erreur, mais une faute de frappe qui tombe sur un vrai contrat contrôlé par un attaquant enverra vos fonds directement à un voleur. Beaucoup de wallets affichent désormais un avertissement sur les contrats inconnus, mais cet avertissement se déclenche après la signature, pas avant. Considérez vos propres yeux comme la première ligne de défense.
Étape 2 : lire la page du contrat sur un explorateur de blocs
Emportez l'adresse sur Etherscan, BscScan, Solscan ou l'explorateur correspondant à la chaîne. La page du contrat est l'endroit où se joue la première vraie vérification. Vous devez y chercher cinq éléments, et si un seul fait défaut, c'est un motif suffisant pour renoncer.
Statut du contrat. L'onglet doit indiquer « Contract » et non simplement « Address ». S'il ne s'agit pas d'un contrat, l'actif n'est pas le type de token échangeable sur un DEX standard. Certaines chaînes et certaines launchpads utilisent des implémentations non standards qui ne fonctionneront pas avec l'agrégateur que vous prévoyez d'utiliser.
Code source vérifié. L'onglet du contrat doit afficher une coche verte et la mention « Contract Source Code Verified ». « Vérifié » signifie que le déployeur a publié le code source et que le bytecode correspond. « Non vérifié » ne veut pas dire automatiquement arnaque, mais cela signifie que vous ne pouvez pas lire ce que fait le code, et la suite de cette checklist suppose que vous puissiez le lire.
Wallet du déployeur. Ouvrez l'adresse du déployeur. Examinez son historique. Ce wallet a-t-il déjà déployé dix autres tokens, tous rug pull ? A-t-il déployé une centaine de contrats copiés-collés ? N'a-t-il jamais déployé le moindre contrat ? Ces trois cas sont des signaux d'alerte. Une équipe qui livre un projet sérieux dispose en général d'un déployeur avec un petit nombre de contrats, souvent reliés à des multisigs connus ou à des fabriques de déploiement comme les helpers Create2.
Date et ancienneté du déploiement. Un contrat déployé le jour même où il est promu est un signal à haut risque. Des contrats plus anciens, avec un historique on-chain, ne sont pas sûrs par défaut, mais l'absence d'historique est un avertissement fort.
Standards du token et décimales. Confirmez que le token est ERC-20 (ou l'équivalent sur la chaîne cible), que le nombre de décimales correspond à ce qu'annonce le projet, et que l'offre totale correspond aux chiffres publiés. Un token qui tourne discrètement sur 9 décimales au lieu de 18 affichera des prix un milliard de fois plus élevés qu'ils ne devraient l'être, et plusieurs tokens d'arnaque ont utilisé cette astuce pour faire passer une microcap pour une affaire.
Étape 3 : simuler une vente avec un détecteur de honeypot
Une fois la page du contrat jugée saine, la vérification suivante consiste à déterminer si vous pouvez réellement vendre. De nombreux contrats frauduleux acceptent les achats mais refusent les ventes, ou prélèvent une taxe punitive à la sortie, ou s'appuient sur une fonction de blacklist que l'équipe peut activer dès la première vente. Rien de tout cela n'est visible sur Etherscan. Il faut tenter la vente dans un bac à sable.
Des outils comme honeypot.is, token-sniffer et le scanner de.fi exécutent un achat puis une vente simulés contre le contrat en ligne et renvoient le résultat. Collez l'adresse du contrat, lancez la simulation et surveillez trois issues : une vente simulée réussie avec une taxe raisonnable (souvent de 0 à 5 %), une taxe partielle correspondant à ce qu'annonce le projet, ou un revert sur la vente. Un revert signifie honeypot. Passez votre chemin.
Les simulateurs de honeypot sont utiles, mais leurs limites comptent. Ils exécutent une seule transaction de test contre l'état actuel du contrat. Un contrat qui passe aujourd'hui peut être mis à niveau demain par une clé admin, l'équipe peut activer une blacklist juste avant la première vraie vente, et le contrat peut embarquer une logique temporelle qui ne s'active qu'avec un volume réel. Considérez le simulateur comme un filtre, pas comme une garantie. Une réussite vous indique que le contrat n'est pas un honeypot classique. Elle ne vous dit pas qu'il est sûr.
Étape 4 : examiner les principaux détenteurs et l'offre déverrouillée
Même un contrat honnête peut être piloté par une équipe qui détient l'essentiel de l'offre et dump sur les premiers acheteurs réels. L'analyse des détenteurs repère cela d'une manière que le contrat lui-même ne permet pas. Sur l'explorateur, ouvrez l'onglet « Holders » et regardez trois chiffres : la part de l'offre détenue par le plus gros portefeuille, la part cumulée des dix plus gros détenteurs, et la part détenue par le reste du marché.
Pour la plupart des tokens, les dix premiers ne devraient pas contrôler plus de 30 à 40 % de l'offre une fois exclus le pool de liquidité, l'adresse de burn et les adresses de contrat clairement liées à du vesting. Si le plus gros portefeuille, à lui seul, contrôle 20 % ou plus et n'est pas un contrat de vesting connu, vous êtes face à un point de défaillance unique. Si les dix premiers contrôlent ensemble plus de 60 %, le marché n'est qu'à une vente coordonnée de zéro.
Examinez ensuite la part déverrouillée. Un token peut afficher sur le papier une distribution saine des détenteurs et rester un piège, car l'équipe conserve le reste dans un contrat qui déverrouille dans 30 jours. Recoupez les principaux détenteurs avec le vesting publié par le projet. Si le vesting prévoit 12 mois et que le déverrouillage tombe dans 30 jours, l'équation a changé et le graphique aussi probablement. Les déverrouillages de tokens et les données de vesting sont des entrées majeures du modèle de sentiment de Zipp, car un déverrouillage programmé modifie l'histoire de l'offre même quand le prix semble stable.
Étape 5 : vérifier la pool de liquidité, le verrouillage et les détenteurs de jetons LP
Le contrat en lui-même ne représente que la moitié de l'équation. L'autre moitié, c'est la liquidité qui permet au jeton d'être échangé. Sur la page du DEX, examinez trois éléments : le volume de liquidité présent dans la pool, l'identité de ceux qui l'ont apportée, et la question de savoir si les jetons LP sont verrouillés.
La taille de la liquidité constitue le plancher de ce qui peut être perdu. Une pool avec quelques milliers de dollars de liquidité est une cible pour une seule transaction, et une seule transaction suffit à un attaquant pour réaliser l'arnaque. La plupart des traders expérimentés considèrent qu'en dessous d'environ 50 000 dollars de liquidité principale, un actif est pratiquement impossible à trader pour leur taille de position.
L'identité de l'apporteur de liquidité compte, car l'équipe peut la retirer. Si la LP a été ajoutée par un portefeuille unique et que les jetons LP ne sont pas verrouillés, l'équipe peut retirer la totalité de la pool en une seule transaction. Si la LP a été déposée auprès d'un service de verrouillage reconnu, rendez-vous sur sa page et vérifiez que le verrouillage porte sur la totalité du montant, que le bénéficiaire est correct, et que la date de déverrouillage est suffisamment éloignée pour couvrir la durée de détention prévue. L'arnaque douce la plus courante est celle d'un jeton qui semble verrouillé, puis qui se déverrouille discrètement 24 heures après le lancement.
Enfin, examinez les détenteurs de jetons LP. Une pool dont les jetons LP sont détenus par une seule adresse, par l'adresse du déployeur, ou par un contrat contrôlé par le déployeur, est une pool qui peut être vidée. Une pool dont la LP est répartie entre de nombreux détenteurs est plus difficile à attaquer, mais un attaquant déterminé disposant d'une part suffisante de LP peut tout de même voter une migration de la pool vers une implémentation malveillante. L'espace est hostile, et les vérifications doivent être à la hauteur de la taille de la position.
Étape 6 : recouper les signaux sociaux et prêter attention au contexte
Les données du contrat vous indiquent ce que fait le code et à quoi ressemble la distribution on-chain. Elles ne vous disent pas qui parle du jeton, pourquoi on en parle, et si les comptes qui le promeuvent sont authentiques. Un minimum de contexte social permet de démasquer une catégorie d'arnaques que les vérifications de contrat ne détectent pas.
Examinez les comptes qui ont mentionné l'adresse du contrat en premier. S'agit-il de comptes récents, ou de comptes actifs depuis des années ? Ce sont des humains qui publient en contexte, ou des comptes qui ne postent qu'un ticker et une adresse de contrat ? La discussion est-elle organique, avec des désaccords et des questions, ou se résume-t-elle à des louanges à sens unique ? Le shill coordonné n'est pas une preuve d'arnaque, mais l'absence de contestation organique justifie de lever le pied.
Recherchez des analyses de risque indépendantes. Si des analystes ou des sociétés de sécurité reconnus ont signalé le contrat, les alertes sont faciles à trouver en cherchant l'adresse du contrat entre guillemets. Si vous tombez sur un seul avis négatif qui identifie des préoccupations précises, prenez-le au sérieux. Le trader particulier qui a perdu de l'argent est rarement la première personne à avoir repéré le problème.
Enfin, effectuez la vérification élémentaire consistant à s'assurer que les canaux officiels sont bien les canaux officiels. Un projet avec une véritable communauté possède un historique de publications conséquent sur son propre Discord, son propre compte X et son propre Telegram. Une arnaque dispose souvent d'un compte X fraîchement créé, d'un Telegram avec peu d'abonnés, et d'un site web enregistré il y a moins de deux semaines. Le contrat on-chain peut exister depuis un an, mais l'équipe et la communauté peuvent être toutes neuves. Vérifiez les deux.
Ce que les vérifications de contrat ne peuvent pas détecter
Il faut être honnête sur les limites de chacune des étapes ci-dessus. La vérification est un filtre, pas une garantie. Les catégories d'échecs qui passent au travers sont bien réelles, et elles ont coûté de l'argent pour de vrai.
Mises à jour après le lancement. De nombreux contrats sont évolutifs, ce qui signifie que l'équipe peut déployer une nouvelle logique à tout moment. Un contrat sûr aujourd'hui peut devenir un honeypot demain. La seule mitigation consiste à acheter des jetons explicitement non évolutifs, ou à accepter qu'un projet qui publie des mises à jour vous demande de faire confiance à l'équipe qui détient les clés.
Clés compromises. Une équipe équipée d'un multisig et de hardware wallets peut tout de même se faire piéger par du phishing. Une trésorerie peut tout de même être vidée. Le contrat est exactement ce que l'équipe a écrit, et l'équipe est exactement celle qu'elle prétend être, et les fonds disparaissent quand même. C'est pourquoi la centralisation est en elle-même un facteur de risque, distinct du code du contrat.
Risque de marché. Même un jeton qui passe toutes les vérifications peut tomber à zéro, simplement parce que le marché n'en veut pas. La vérification vous protège d'une arnaque. Elle ne vous protège pas d'un mauvais trade.
Comment suivre les lancements de jetons de manière intelligente
Les lancements de jetons avancent vite, et l'actualité qui les entoure aussi. Suivre quels contrats sont sûrs, lesquels sont mis en avant, et lesquels sont signalés relève du travail à temps plein si on le fait à la main, et c'est une bataille perdue d'avance si on essaie de suivre depuis son téléphone. Zippfeed met en avant les titres liés aux jetons avec un score de sentiment (bullish, neutral ou bearish) et une note d'importance, afin que vous puissiez repérer les lancements qui suscitent une attention réelle et ceux qui sont pumpés par une poignée de comptes. Combinez ce flux avec la checklist de vérification ci-dessus, et vous disposez d'un moyen plus rapide de décider quels contrats méritent le temps qu'il faut consacrer aux vérifications.
