Comment identifier un jeton frauduleux ? (Vérification du contrat)

Comprendre la vérification du contrat de jeton

1. Un contrat de token légitime doit être vérifié publiquement sur les explorateurs de blockchain tels que Etherscan ou BscScan. Les contrats non vérifiés manquent de transparence et empêchent les utilisateurs d'inspecter la logique de base.

2. Les contrats vérifiés affichent le code source, les paramètres du constructeur et les détails de la version du compilateur lisibles. L’absence de ces éléments signale un obscurcissement ou une dissimulation intentionnelle.

3. L'adresse du titulaire du contrat doit être clairement visible dans l'onglet « Contrat ». Si l’on renonce à la propriété, cela indique une décentralisation ; sinon, le propriétaire conserve le contrôle total sur les fonctions critiques.

4. Des fonctions telles que transferOwnership , renounceOwnership ou setApprovalForAll nécessitent un examen minutieux : les jetons malveillants les utilisent souvent à mauvais escient pour geler des fonds ou permettre des retraits de tapis.

5. Les dépendances des bibliothèques externes doivent être auditées séparément. Les contrats faisant référence à des bibliothèques non vérifiées ou personnalisées augmentent considérablement les risques.

Analyser les mécanismes de propriété et de contrôle

1. Le statut de propriété détermine si un développeur peut modifier l'offre de jetons, suspendre les transferts ou retirer des liquidités. Les jetons à propriété active sont intrinsèquement vulnérables.

2. La présence de fonctions de pause ou de retrait d'urgence sans verrouillage horaire ni gouvernance multisig permet une intervention unilatérale.

3. L'historique des transferts de propriété révèle des signaux d'alarme : des changements fréquents, des transferts vers des portefeuilles brûleurs ou des adresses liées à des escroqueries connues indiquent une manipulation.

4. Les contrats autorisant la frappe après le déploiement sans divulgation publique violent les principes de confiance. Les jetons légitimes plafonnent l’offre au lancement ou utilisent des protocoles de frappe transparents et gouvernés.

5. La renonciation à la propriété doit être confirmée via les journaux de transactions en chaîne, et pas seulement revendiquée dans des livres blancs ou des publications sur les réseaux sociaux.

Examen de la logique de liquidité et de tokenomics

1. Les liquidités bloquées dans les échanges décentralisés devraient être vérifiables via des plateformes comme Team Finance ou Unicrypt. Les faux certificats de verrouillage sont courants et facilement falsifiés.

2. Les données de distribution des jetons doivent s'aligner sur les avoirs en chaîne. Les écarts entre les allocations réclamées et les soldes réels des portefeuilles révèlent de faux récits.

3. Les restrictions de transfert, telles que les listes noires, les listes blanches ou les frais dynamiques, doivent être divulguées dans le code source et dans la documentation de correspondance. Les restrictions cachées n'apparaissent souvent qu'après l'achat.

4. Une tolérance élevée au dérapage combinée à une faible profondeur de liquidité suggère une vulnérabilité précoce et une inflation artificielle des prix.

5. Le contrat ne doit pas contenir d'adresses de portefeuille codées en dur recevant des frais automatiques, sauf indication contraire explicite et justifiée dans une logique auditée.

Détection des signaux d'alarme au niveau du code

1. L'utilisation d'opcodes d'autodestruction ou de suicide permet aux développeurs d'effacer le contrat et de disparaître avec les fonds.

2. Les noms de variables obscurcis comme _a , _x123 ou func_0x89ab entravent l'auditabilité et suggèrent une intention malveillante.

3. Les vulnérabilités de réentrée, les appels externes non contrôlés ou les opérations arithmétiques dangereuses (par exemple, SafeMath manquant) exposent les jetons à des exploits.

4. Les contrats déployant des contrats supplémentaires de manière dynamique, en particulier avec l'assemblage en ligne ou CREATE2, peuvent cacher des portes dérobées ou des escroqueries imbriquées.

5. Les émissions d’événements manquantes pour des actions critiques telles que les transferts, les approbations ou les changements de propriété violent les normes Ethereum et entravent les outils de surveillance.

Foire aux questions

Q : Un token peut-il être sûr même si son contrat n'est pas audité par un tiers ? R : Non. L’absence d’audit indépendant ne garantit pas la sécurité. De nombreux jetons non audités fonctionnent sans problèmes immédiats mais s'effondrent sous des conditions de stress ou d'exploitation. Les audits fournissent des preuves (et non une assurance) mais leur absence supprime une couche critique de validation.

Q : Que signifie réellement « renonciation à la propriété » sur la chaîne ? R : Cela signifie que l'adresse du propriétaire a exécuté une fonction qui définit la variable interne du propriétaire sur l'adresse zéro (0x0). Cette action est irréversible et visible dans les variables d'état du contrat sur les explorateurs blockchain.

Q : Pourquoi certains jetons frauduleux affichent-ils de faux verrous de liquidité ? R : Les attaquants génèrent des certificats de verrouillage contrefaits à l'aide d'interfaces frontales compromises ou clonées. Les vrais verrous nécessitent des signatures cryptographiques du service de verrouillage et une preuve en chaîne visible dans les enregistrements de solde du contrat de pool de liquidité.

Q : Est-il sûr de faire confiance à un jeton simplement parce qu'il apparaît sur une liste DEX majeure ? R : Pas nécessairement. Les inscriptions sur des bourses décentralisées comme Uniswap ou PancakeSwap n'impliquent pas de vérification. N'importe qui peut déployer une paire et ajouter des liquidités, même avec une valeur réelle nulle ou un code malveillant caché.