Détection de rug pull : guide des red flags on-chain

Les rug pulls ne sont pas de la malchance aléatoire. Ils sont designés en amont. Le contrat est écrit pour que l'équipe puisse drainer le protocole, et on-chain on peut presque toujours le voir avant que le rug n'arrive, si on sait où regarder. Cet article détaille les red flags rug-pull qu'on vérifie sur chaque mission de due diligence, et les heuristiques que tout retail peut appliquer avec un explorer et 15 minutes.

Ce que veut dire « rug pull »

Le terme est utilisé largement. Taxonomie utile :

• Hard rug : le contrat a des fonctions explicites qui permettent au déployeur de drainer la liquidité, mint des tokens à l'infini, ou bloquer la vente. La sortie est codée. C'est ce que la plupart des gens entendent par « rug pull ».
• Soft rug : l'équipe abandonne le projet après avoir levé des fonds. Moins malicieux, mais les holders restent avec un token sans support.
• Slow rug : l'équipe vend ses holdings progressivement, retire la liquidité par tranches, arrête de livrer. Le prix descend en spirale. Difficile à distinguer d'un échec organique.

Cet article se concentre sur les hard rugs, ceux où le contrat lui-même est l'arme du crime.

Red flag 1 : fonctions de mint privilégiées

Le pattern hard-rug n°1 : une fonction onlyOwner (ou équivalent) qui peut mint des montants arbitraires de token, sans cap. Parfois nommée mint, parfois cachée derrière claimRewards, airdrop, ou setBalance.

Ce qu'il faut vérifier sur un contrat de token :

• Est-ce que totalSupply est cappé, ou est-ce que l'owner peut mint plus ? Cherchez une constante MAX_SUPPLY ou équivalent.
• Les rôles capables de mint sont-ils transférables ? Un mint onlyOwner où l'ownership est renoncée à address(0) est bien plus sûr qu'un où l'ownership est sur un EOA.
• Y a-t-il un timelock ? onlyOwner avec un délai de 30 secondes, c'est fonctionnellement onlyOwner sans délai.

Un token propre n'a soit pas de fonction mint après déploiement (supply fixe), soit une fonction mint gatée par un multi-sig timelocké avec une politique publiée.

Red flag 2 : liquidité qu'on peut retirer

Le rug classique : l'équipe fournit toute la liquidité au pool AMM, puis la retire. À vérifier :

• Concentration des holders de liquidité : qui détient les LP tokens ? Si une seule adresse (surtout le déployeur) détient >50 %, ils peuvent drainer.
• Lock de liquidité : les projets légitimes lockent les LP tokens dans un contrat de lock vérifiable (Unicrypt, Team.Finance) pour une durée affichée. Le lock est une adresse publique vérifiable directement.
• Durée du lock : un lock de 30 jours n'est pas un lock. Les vrais projets lockent pour 1 an+.
• Plusieurs pools : si la liquidité est répartie sur plusieurs paires (token/ETH, token/USDC, token/WBTC), retirer toutes simultanément est plus difficile à masquer.

Pour un token qui revendique « la liquidité est lockée », vérifiez que le contrat de lock détient bien les LP tokens, que la durée correspond au claim, et que la date de unlock est réelle.

Red flag 3 : fonctions blacklist et pause qui bloquent la vente

Un rug favori, c'est un contrat de token qui peut pauser les transferts ou blacklister des adresses : utilisé légitimement par l'équipe pour « bloquer les bots » avant le launch, utilisé maliciously pour empêcher les holders de vendre une fois que le prix a été pumpé.

À vérifier :

• Fonctions pause() / unpause() contrôlées par un EOA ou un rôle à action rapide.
• Fonctions blacklist(address) qui empêchent une adresse spécifique de transférer.
• Logique de transfer qui inclut des reverts conditionnels basés sur un état owner-set.

Un token propre n'a soit pas de fonction pause (après le launch), soit elle est gatée par un process de gouvernance timelocké avec des cas d'usage documentés.

Red flag 4 : chemins d'upgrade malicieux

Pour les contrats upgradeables (proxies), le chemin d'upgrade est le contrat. L'implémentation actuelle peut être remplacée par une malicieuse en une seule transaction.

À vérifier :

• Qui peut upgrade ? Un proxy contrôlé par EOA est un rug en attente.
• Y a-t-il un timelock sur les upgrades ? 24 à 48 heures minimum donne aux utilisateurs le temps de sortir.
• L'admin du proxy a-t-il renoncé au contrôle ? Parfois affiché comme « ownership renounced » : vérifiez le slot admin, pas seulement le owner() de l'implémentation.
• Les events d'upgrade sont-ils suivis publiquement ? Les projets légitimes communiquent les propositions d'upgrade.

L'upgradabilité n'est pas mauvaise en soi. Elle permet bug fixes et évolution feature. Mais la concentration du contrôle d'upgrade est le chemin le plus courant de « contrat audité » à « protocole drainé ».

Red flag 5 : audits manquants ou superficiels

Un rapport d'« audit de smart contract » qui :

• Liste seulement de la sortie d'outil auto (dump Slither, Mythril).
• N'a pas de scope statement.
• Ne nomme pas d'auditeurs spécifiques.
• A été réalisé quelques semaines avant le launch sans temps pour les correctifs.
• N'a pas de section re-audit.

…est plus proche d'une checkbox marketing que d'un artefact de sécurité. Notre guide sur la lecture des rapports d'audit détaille ce que contiennent vraiment les rapports crédibles.

La présence d'un audit n'est pas la sécurité. Son absence est un red flag, mais un audit faible peut être pire que pas d'audit. Il donne une fausse confiance au retail.

Red flag 6 : concentration des holders

Un coup d'œil à la distribution des holders en dit long :

• Les 10 plus gros holders ne devraient pas contrôler >50 % du supply.
• Le wallet du déployeur doit être soit renoncé, soit détenir une petite allocation.
• Les wallets « marketing » ou « treasury » concentrés sur des EOA sont un risque de slow rug.
• Les contrats de vesting qui détiennent l'allocation team sont bons : vérifiez que le contrat de vesting, le cliff et la durée sont réels.

L'onglet « Holders » d'Etherscan sur n'importe quel ERC-20 vous donne ça en 30 secondes.

Red flag 7 : mismatch de code source

Vérifiez sur le block explorer que le contrat déployé est vérifié (source publiée) et correspond à ce qui a été audité. Patterns courants :

• Contrat non vérifié : vous n'avez aucune idée de ce qui tourne.
• Contrat vérifié mais source qui diverge du commit hash de l'audit.
• Plusieurs targets de proxy existent ; l'audit a couvert l'un mais pas l'actuel.

Etherscan / Routescan / explorers équivalents affichent « Contract Source Code Verified » sur la page du contrat. S'il manque, le projet a choisi de livrer du bytecode opaque. Ce choix a des implications.

À quoi ressemble la trace on-chain après un rug

Pour être complet, le pattern post-rug est consistant :

1. La liquidité est retirée en une seule transaction (ou une petite rafale).
2. Le token est dump dans le pool résiduel.
3. Les fonds passent par un mixer (Tornado, eXch) ou sont bridgés vers une autre chaîne.
4. Les comptes sociaux du déployeur s'éteignent, parfois supprimés.
5. Une nouvelle « team » émerge des semaines plus tard sous un nouveau nom de projet, avec les mêmes patterns de wallet.

C'est là que la réponse à incident et la forensique on-chain entrent en jeu : tracer les fonds à travers mixers et bridges, coordonner avec les off-ramps, et produire la documentation qui rend la recovery possible des semaines ou des mois plus tard.

Quand engager une due diligence professionnelle

Pour les allocateurs institutionnels, une vérification individuelle ne suffit pas. Une due diligence pré-investissement formelle sur un protocole DeFi couvre tout ce qui précède plus :

• Revue de code des contrats du périmètre.
• Analyse on-chain des wallets de déploiement liés et des projets antérieurs.
• Vérification du background de l'équipe.
• Modélisation de la soutenabilité de la liquidité.

Si vous déployez un capital significatif dans une position DeFi, une mission de due diligence cadrée est une assurance pas chère par rapport à la taille de la position.