Analyser un token on-chain (holders, liquidité, contrat)

L’essentiel

Ce guide est une information générale à visée pédagogique. Il ne constitue pas un conseil en investissement.

Pourquoi analyser un token « on-chain » ?

Un site web, un compte X ou un groupe Telegram présentent un projet comme ses créateurs le souhaitent. La blockchain, elle, enregistre ce qui se passe réellement : les transferts, les soldes de chaque adresse, le code du contrat qui gère le token.

Analyser un token on-chain (« sur la chaîne ») signifie aller lire ces données directement, avec des outils publics, plutôt que de se fier au discours marketing. L'objectif n'est pas de prédire le prix, mais de répondre à quatre questions simples :

1. Le token est-il concentré entre quelques mains ?
2. Peut-on réellement le revendre, et à quel prix ?
3. Le contrat donne-t-il des pouvoirs dangereux à quelqu'un ?
4. Des quantités importantes vont-elles être débloquées prochainement ?

Les outils de base

Vous n'avez pas besoin d'être développeur. Quelques familles d'outils suffisent. Les noms ci-dessous sont des exemples courants, cités à titre d'illustration.

Première règle : partez toujours de l'adresse du contrat, jamais du nom ou du ticker. N'importe qui peut créer un token qui s'appelle comme un projet connu. L'adresse officielle se trouve dans la documentation du projet, et vous pouvez la recouper sur plusieurs sources. Si vous débutez avec les explorateurs, le guide lire un explorateur de blocs détaille leur fonctionnement.

Étape 1 : la répartition des holders

Un holder est une adresse qui détient le token. Sur un explorateur comme Etherscan, l'onglet des holders d'un token liste les adresses par solde décroissant, avec le pourcentage de l'offre détenu par chacune.

Ce qu'il faut regarder

• La part des 10 premiers holders. Si quelques adresses détiennent la majorité de l'offre, elles peuvent faire chuter le prix en vendant.
• La nature de ces adresses. Une grosse adresse n'est pas forcément un individu. Ce peut être le pool de liquidité, un contrat de vesting (blocage progressif), une trésorerie de projet ou le portefeuille d'un exchange centralisé. Les explorateurs affichent souvent une étiquette ; sinon, cliquez sur l'adresse pour voir s'il s'agit d'un contrat.
• Les liens entre adresses. Dix adresses qui détiennent chacune 3 % peuvent en réalité appartenir à la même personne, qui les a alimentées depuis un portefeuille commun.

Visualiser les liens

C'est l'intérêt d'outils comme Bubblemaps : chaque « bulle » représente un des principaux holders (sa taille dépend du solde), et les traits entre bulles indiquent des transferts entre ces adresses. Des bulles reliées forment un cluster. Selon la documentation de l'outil, les adresses d'exchanges centralisés, de pools DEX et de contrats sont masquées par défaut, pour se concentrer sur les vrais détenteurs.

Un cluster n'est pas une preuve de fraude : une équipe qui paie ses membres ou un fonds qui distribue des tokens crée aussi des liens. Mais un gros cluster non expliqué, surtout alimenté juste avant le lancement, mérite une vraie prudence.

Étape 2 : la liquidité et son verrouillage

La liquidité est la quantité d'actifs disponibles pour acheter ou vendre le token sans faire bouger le prix de manière excessive. Pour un token échangé sur un DEX (exchange décentralisé), elle se trouve dans un pool : un contrat qui contient à la fois le token et un actif de contrepartie (ETH, SOL, USDC…).

La profondeur

Sur un agrégateur comme DEX Screener, chaque paire affiche la liquidité totale du pool, le volume et l'historique des transactions. Comparez la liquidité à la capitalisation affichée :

• Une capitalisation de plusieurs millions avec quelques dizaines de milliers d'euros de liquidité signifie qu'une vente moyenne suffit à faire s'effondrer le prix.
• Vérifiez aussi qu'il ne s'agit pas d'une seule petite paire parmi d'autres : additionnez les principales paires.

Pour bien comprendre la mécanique des pools, voyez le guide pools de liquidité et impermanent loss.

Qui peut retirer la liquidité ?

Sur de nombreux DEX, la personne qui ajoute la liquidité reçoit des jetons LP (ou une position NFT) qui représentent sa part du pool. Celui qui détient ces jetons peut retirer la liquidité à tout moment. C'est le mécanisme classique du « rug pull » : les créateurs retirent la liquidité et le token devient invendable.

Trois situations se rencontrent souvent :

• Liquidité verrouillée : les jetons LP sont déposés dans un contrat de blocage jusqu'à une date donnée. Vérifiez la date de fin et la part verrouillée, pas seulement le mot « locked ».
• Liquidité brûlée : les jetons LP ont été envoyés vers une adresse inutilisable. Le retrait devient impossible.
• Liquidité libre : les jetons LP sont dans un portefeuille ordinaire. Le risque de retrait est entier.

Allez vérifier la transaction de blocage ou de brûlage sur l'explorateur, plutôt que de vous fier à une capture d'écran.

Étape 3 : le contrat du token

Le code est-il vérifié ?

Un contrat déployé sur la blockchain n'est, à l'origine, que du bytecode illisible. La vérification du code source consiste à publier le code lisible et à prouver qu'il correspond exactement au bytecode déployé. Comme l'explique ethereum.org, cela permet à chacun de contrôler que le code annoncé est bien celui qui s'exécute.

Sur Etherscan et les explorateurs similaires, un contrat vérifié affiche un onglet « Contract » avec le code source et une coche. Un token dont le code n'est pas vérifié ne permet aucune analyse sérieuse : c'est un signal d'alerte majeur.

Les privilèges du propriétaire

Beaucoup de contrats désignent un owner (propriétaire), une adresse qui peut appeler certaines fonctions réservées. Dans la bibliothèque OpenZeppelin, très utilisée, ces fonctions sont marquées par le modificateur onlyOwner. Dans l'onglet « Read Contract », la fonction owner indique l'adresse actuelle du propriétaire.

Dans le code ou l'onglet « Write Contract », repérez les fonctions qui permettent de :

• créer de nouveaux tokens (mint) : diluer les holders à volonté ;
• mettre en pause les transferts (pause) ;
• bloquer des adresses (blacklist) : vous empêcher de vendre ;
• modifier les taxes d'achat ou de vente (setFee, setTax) : une taxe de vente portée à 99 % rend le token invendable en pratique ;
• limiter la taille des transactions ou des portefeuilles.

Certaines de ces fonctions existent pour de bonnes raisons (par exemple le gel d'adresses sur certains stablecoins réglementés). La question est : qui les contrôle et avec quelles garanties ?

Renoncement, multisig, proxy

• Propriété abandonnée : la fonction renounceOwnership permet au propriétaire de renoncer définitivement à son rôle. L'adresse owner devient alors l'adresse zéro, et les fonctions réservées ne sont plus appelables par personne. Vérifiez la transaction correspondante.
• Propriété confiée à un multisig : l'owner est un portefeuille qui exige plusieurs signatures (voir le guide multisig). C'est plus sûr qu'une clé unique, sans être une garantie.
• Contrat proxy (upgradeable) : l'adresse que vous voyez est un « proxy » qui redirige vers un contrat d'implémentation. Selon la documentation OpenZeppelin, un administrateur peut remplacer cette implémentation sans changer l'adresse du token. Autrement dit, le code peut changer demain. Les explorateurs signalent généralement ces contrats (« Read as Proxy »). Un contrat renoncé mais upgradeable n'est donc pas figé.

Étape 4 : le calendrier de déblocage

Beaucoup de projets n'émettent pas toute leur offre dès le départ. Les tokens de l'équipe, des investisseurs ou de la trésorerie sont souvent soumis à un vesting : ils sont libérés progressivement selon un calendrier, parfois après une période d'attente appelée cliff.

Ce qu'il faut vérifier :

• la part de l'offre actuellement en circulation par rapport à l'offre totale ;
• les dates des prochains déblocages importants ;
• les adresses des contrats de vesting, que vous pouvez suivre sur l'explorateur.

Un déblocage massif peut exercer une pression vendeuse. Le guide tokenomics, market cap, FDV et unlocks détaille ces notions.

Exemple concret

Imaginons un token fictif, « NOVA », lancé il y a deux semaines sur un réseau compatible Ethereum. Vous voulez vous faire une idée avant d'y toucher.

1. Adresse : vous récupérez l'adresse du contrat dans la documentation officielle et vous la collez dans l'explorateur. Le nom et le symbole correspondent.
2. Code : le contrat est vérifié. La fonction owner renvoie une adresse ordinaire (pas un multisig). Dans le code, vous trouvez une fonction setSellTax sans plafond.
3. Holders : le top 10 détient 62 % de l'offre. La première adresse est le pool DEX (18 %), la deuxième un contrat de vesting (15 %). Les huit suivantes détiennent chacune 3 à 4 %.
4. Clusters : sur une visualisation des holders, six de ces huit adresses sont reliées et ont été alimentées par le même portefeuille la veille du lancement.
5. Liquidité : 40 000 dollars dans le pool principal pour une capitalisation affichée de 8 millions. Les jetons LP sont verrouillés, mais seulement pour 30 jours.
6. Déblocage : le contrat de vesting libère 15 % de l'offre dans trois mois.

Bilan : taxe de vente modifiable sans limite par une seule clé, offre concentrée dans un groupe d'adresses liées, liquidité faible et verrouillée pour peu de temps. Aucun de ces éléments ne prouve une arnaque, mais leur cumul décrit un profil de risque très élevé.

Checklist rapide

• Adresse du contrat obtenue depuis une source officielle et recoupée
• Code source vérifié sur l'explorateur
• Propriétaire identifié : clé unique, multisig ou renoncé
• Contrat proxy (upgradeable) ou non
• Fonctions sensibles : mint, pause, blacklist, taxes modifiables
• Part du top 10 et nature des grosses adresses
• Clusters d'adresses liées expliqués ou non
• Liquidité totale comparée à la capitalisation
• Jetons LP verrouillés (jusqu'à quand) ou brûlés
• Offre en circulation et prochains déblocages

Les erreurs à éviter

• Chercher le token par son nom. Les copies portant le même nom sont fréquentes. Seule l'adresse du contrat fait foi.
• Se fier au mot « audit » ou « SAFU ». Un audit porte sur une version du code à une date donnée ; il ne dit rien des clés qui contrôlent le contrat ni de la répartition des holders.
• Confondre renoncement et immuabilité. Un contrat proxy peut être modifié même si le token affiche un owner renoncé.
• Compter le pool ou le contrat de vesting comme une « baleine ». Identifiez toujours la nature des grosses adresses avant de conclure.
• Oublier la durée du verrouillage. Une liquidité verrouillée pour quelques jours protège peu.
• Tester en achetant. Acheter une petite somme « pour voir si on peut revendre » expose tout de même aux mécanismes piégés. Le guide repérer un rug pull détaille ces signaux.
• Considérer un score automatique comme un verdict. Les outils de notation automatique aident, mais ils peuvent manquer une fonction piégée ou signaler à tort un contrat légitime.

À retenir

• Partez toujours de l'adresse du contrat, jamais du nom du token.
• Un code source non vérifié empêche toute analyse sérieuse et constitue un signal d'alerte fort.
• Regardez qui contrôle le contrat : fonctions réservées au propriétaire, multisig, renoncement, et possibilité de mise à jour via un proxy.
• La répartition des holders doit être lue avec la nature des adresses et leurs liens entre elles.
• Comparez la liquidité à la capitalisation et vérifiez sur l'explorateur que les jetons LP sont verrouillés ou brûlés, et jusqu'à quand.
• Aucune analyse on-chain ne garantit un investissement : elle réduit certains risques, elle ne les supprime pas.

Sources

• ethereum.org — Verifying smart contracts
• OpenZeppelin Docs — Access Control (Ownable, renounceOwnership)
• OpenZeppelin Docs — Proxy Upgrade Pattern
• Bubblemaps Wiki — How does it work?
• Etherscan Docs — Documentation de l'API (données on-chain, code source des contrats)

Comparer les services liés à ce sujet

• Meilleur wallet crypto : comparatif