---
title: "Comment vérifier les décimales d'un jeton"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Comment vérifier les décimales d'un jeton
> À 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
- [Vérification du contrat du jeton](/crypto/token-contract-verification/)
- [Décodage de calldata dans le portefeuille](/crypto/calldata-decoding-wallet/)
- [Vérification d'un jeton de pont](/crypto/bridge-token-verification/)
- [Risque des jetons à frais de transfert](/crypto/fee-on-transfer-token-risk/)
- [Contrat proxy](/crypto/proxy-contract/)
## Sources
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulté : 2026-08-21)
- [ERC-20](https://docs.openzeppelin.com/contracts/5.x/erc20) - OpenZeppelin Docs (consulté : 2026-08-21)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - ethereum.org (consulté : 2026-08-21)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consulté : 2026-08-21)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (consulté : 2026-08-21)
Source: https://wiki.fcontext.com/fr/crypto/token-decimals-verification/index.mdx