Aller au contenu
Financial Context Wiki

Comment vérifier les décimales d'un jeton

Vérifiez les décimales d'un ERC-20 sur le bon contrat et au bon bloc, puis rapprochez soldes bruts, transferts, autorisations et conversions de pont sans erreur de virgule flottante.

Mis à jour

À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement ou en sécurité. Les décimales ne prouvent ni l’identité, ni la valeur, ni les réserves, ni la sûreté d’un jeton.

Réponse directe

Pour un jeton ERC-20, decimals() est une métadonnée facultative indiquant aux interfaces comment afficher les unités entières. Si elle renvoie d, le montant affiché par convention est raw / 10^d. Elle ne modifie pas l’arithmétique du contrat et n’authentifie pas le jeton. Avant de faire confiance au résultat, vérifiez réseau, adresse exacte, code ou implémentation du proxy et bloc.

Lisez decimals() directement via un RPC indépendant à un bloc donné, décodez le retour ABI comme uint8, puis comparez-le au registre officiel de l’émetteur et à un explorateur fiable. Testez ensuite l’échelle avec les valeurs brutes de balanceOf, transferts, autorisations, reçus et événements. Ne supposez pas 18 si l’appel est absent, échoue, renvoie des données malformées ou contredit d’autres preuves.

Fonctionnement

ERC-20 stocke et transfère des montants entiers non signés. La couche d’affichage insère la virgule ; le contrat reçoit toujours des entiers. Convertissez les entrées avec des chaînes décimales ou des entiers de précision arbitraire, jamais en virgule flottante binaire. Une quantité n’est représentable que si sa multiplication par 10^d donne un entier.

Comme decimals() est facultatif, un jeton conforme peut l’omettre. Une implémentation personnalisée ou évolutive peut renvoyer une valeur inattendue ou changer après une mise à niveau. Pour un proxy ERC-1967, inspectez adresse proxy, implémentation ou beacon, administrateur et événements de mise à niveau ; lisez l’état à l’adresse proxy et fixez toutes les comparaisons au même bloc.

Les autorisations et valeurs ERC-2612 permit sont aussi des entiers bruts. Un transfert bien affiché ne prouve pas qu’une autorisation, un minimum de routeur, un montant de pont ou une base comptable utilise la même échelle. Les contrats source et destination d’un pont peuvent avoir des décimales différentes : comparez valeur lisible et unités brutes de chaque côté selon les règles documentées de conversion et d’arrondi.

Suivez ce processus :

  1. Fixez l’ID de réseau ou domaine, le contrat du jeton, le numéro de bloc, le point RPC et l’heure d’observation.
  2. Confirmez l’adresse dans le registre officiel de l’émetteur ; nom, symbole, icône et résultats de recherche ne font pas autorité.
  3. Vérifiez le code déployé et si l’adresse est un proxy ; notez implémentation ou beacon, administrateur et mises à niveau récentes.
  4. Appelez decimals(), décodez uint8 via ABI et consignez succès, échec, sortie vide ou malformée sans insérer de valeur par défaut.
  5. Lisez balanceOf, totalSupply, autorisation, calldata, reçu et événements bruts à des blocs compatibles ; formatez-les avec l’échelle observée.
  6. Recalculez transferts, autorisations, devis et ponts avec des entiers, y compris frais, arrondis, poussières, rebases ou taxes de transfert.
  7. Simulez et envoyez une petite opération, puis rapprochez les soldes bruts avant et après ; arrêtez-vous si interface, RPC, événement ou solde divergent.

Exemples

  • Une valeur brute, deux échelles. Avec raw = 123456789, d = 6 affiche 123.456789 ; avec d = 18, 0.000000000123456789. L’écart est un facteur de 10^12.
  • La représentabilité compte. Avec d = 6, 1.25 jeton devient 1250000 unités brutes. 0.0000001 jeton vaut moins d’une unité et doit être refusé ou arrondi selon une règle explicite.
  • Autorisation mal dimensionnée. Une autorisation de 100 jetons avec d = 6 vaut 100000000. Encodée avec d = 18, elle devient 100000000000000000000, soit 10^12 fois trop.
  • Changement d’échelle par pont. Si une route documentée 1:1 convertit un jeton source avec d = 6 vers une représentation cible avec d = 18, 2500000 brut représente 2.5 jetons et 2500000000000000000 à destination représente 2.5. Frais, plafonds, poussières et solde reçu restent à vérifier.

Risques

  • La bonne adresse est interrogée sur le mauvais réseau.
  • Un nom, symbole ou icône copié masque un autre contrat.
  • L’implémentation proxy ou le beacon change après la vérification.
  • Le RPC ou l’explorateur sert un état ancien, non finalisé ou incohérent.
  • Des métadonnées absentes ou malformées sont remplacées silencieusement par 18.
  • La virgule flottante binaire arrondit un montant grand ou précis.
  • Le portefeuille formate bien le transfert mais mal l’autorisation ou permit.
  • Une base de données mélange unités brutes et montants lisibles.
  • Un pont suppose des décimales égales ou ne révèle pas l’arrondi des poussières.
  • Frais de transfert, rebase, émission, destruction, pause ou gel empêchent un rapprochement simple.
  • Calldata, événements, reçus et variations réelles de solde ne concordent pas.
  • La vérification des décimales est prise pour une preuve d’émetteur, de réserves, de liquidité ou de sûreté.

Idées reçues

  • Tous les ERC-20 ont 18 décimales. La métadonnée est facultative et une implémentation peut renvoyer une autre valeur.
  • Les décimales sont des bits de précision de l’EVM. C’est une convention d’affichage en base dix ; l’arithmétique reste entière.
  • Le solde formaté de l’explorateur est une confirmation indépendante. Il peut dépendre du même appel et partager la même erreur.
  • Même symbole et mêmes décimales identifient le même actif. Il faut aussi le bon réseau, le contrat exact et des preuves de l’émetteur.
  • Un petit transfert réussi valide toutes les intégrations. Autorisations, routeurs, ponts, plateformes et comptabilité peuvent appliquer leur propre échelle.

Sujets associés

Sources

Navigation

Rechercher dans le wiki...