---
title: "Incompatibilités de décimales des oracles"
description: "Une incompatibilité de décimales applique la mauvaise échelle d'unité à la réponse d'un oracle, au montant d'un token, au taux d'un wrapper ou à une valeur du protocole, provoquant des erreurs de plusieurs ordres de grandeur dans les emprunts, émissions, remboursements et liquidations."
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.
# Incompatibilités de décimales des oracles
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
Une incompatibilité de décimales d'oracle survient lorsqu'un contrat interprète un entier brut avec un mauvais exposant d'unité, une mauvaise direction de prix ou une mauvaise échelle interne. Les décimales du flux, du token et du token de cotation, les échelles des taux de wrapper ou de parts et les conventions WAD ou RAY du protocole sont indépendantes. Une interface apparemment correcte ne prouve pas que le contrat consommateur applique la même arithmétique.
Pour un montant brut de token de base `A_raw` comportant `d_t` décimales et une réponse positive du flux `P_raw` cotant un token de base en tokens de cotation avec `d_p` décimales, le montant brut de tokens de cotation avec `d_q` décimales vaut `V_raw = round(A_raw * P_raw * 10^d_q / 10^(d_t + d_p))`. Cette formule ne vaut que pour la direction indiquée et après validation du flux, des unités, des types et de la règle d'arrondi. Un adaptateur ayant déjà normalisé une valeur ne doit pas la remettre à l'échelle.
Dans ERC-20, `decimals()` est une métadonnée d'affichage facultative, et non une garantie universelle de 18 décimales. Le `decimals()` d'un flux décrit sa réponse, pas l'échelle du token ou du protocole. L'arithmétique contrôlée peut arrêter un overflow par un revert, mais elle ne détecte pas une formule dimensionnellement erronée et peut transformer un résultat représentable en déni de service si un produit intermédiaire déborde.
## Fonctionnement
1. Fixer la chaîne, le bloc, le consommateur, l'adaptateur, le proxy et l'agrégateur du flux, le token ou vault, les versions du compilateur et de la bibliothèque mathématique et l'état de la mise à niveau.
2. Inventorier chaque entier avec son type et son unité : montant brut, décimales du token, réponse signée et décimales du flux, orientation base/cotation, taux du wrapper ou de la part, échelle interne et décimales du token de sortie.
3. Valider la source avant conversion : adresse et direction correctes, réponse positive, horodatage et statut, ancienneté et plage acceptables, sémantique du repli et règles de délai de grâce du séquenceur L2.
4. Dériver une formule dimensionnelle unique des unités brutes d'entrée aux unités brutes de sortie. Traiter explicitement les augmentations et réductions d'échelle, borner chaque exposant de dix et normaliser chaque composante une seule fois.
5. Utiliser une multiplication-division éprouvée en précision complète ou une simplification bornée. Éviter le troncage dû à une division anticipée, l'overflow intermédiaire contrôlé, le wraparound unchecked et les conversions signées ou restrictives dangereuses.
6. Définir l'arrondi inférieur, supérieur ou au plus proche pour chaque action. Garantie, dette, emprunt, émission, remboursement, frais, liquidation et conversion de parts peuvent exiger des directions prudentes différentes.
7. Tester des vecteurs de référence et des propriétés avec montants extrêmes, combinaisons de décimales, réciproques, flux composés, réponses nulles, négatives et obsolètes, mises à niveau et dust ; rapprocher les résultats onchain d'un modèle indépendant en haute précision et plafonner l'exposition.
La normalisation relève de l'analyse dimensionnelle, pas du formatage. `BTC/USD` et `USD/BTC` nécessitent des formules réciproques ; modifier un libellé n'inverse pas un prix. Les flux composés exigent l'échelle et l'horodatage de chaque composante. La division entière de Solidity tronque vers zéro, de sorte que des réarrangements algébriquement équivalents peuvent produire des résultats onchain différents. Un `mulDiv` en précision complète résout le problème de largeur intermédiaire, mais exige toujours le bon numérateur, dénominateur, les bonnes unités, bornes et direction d'arrondi.
## Exemples détaillés
- **Huit contre dix-huit décimales.** Un flux BTC/USD renvoie `6,000,000,000,000` avec `d_p = 8`, donc le prix est `60,000 USD/BTC`. Interpréter la réponse brute avec 18 décimales donne `0.000006 USD/BTC`, une sous-évaluation par `10^10`, et non `10^9`. La mise à l'échelle WAD donne `6,000,000,000,000 * 10^(18 - 8) = 60,000,000,000,000,000,000,000`.
- **Unités de montant, prix et sortie.** `A_raw = 2,500,000` représente `2.5` tokens avec `d_t = 6` ; `P_raw = 200,000,000` représente `2` tokens de cotation avec `d_p = 8`. Pour une valeur interne à 18 décimales, `2,500,000 * 200,000,000 * 10^18 / 10^(6 + 8) = 5,000,000,000,000,000,000`, soit `5 quote tokens`. Omettre le dénominateur du token surévalue la position par `10^6`.
- **Réciproque et troncage.** ETH/USD à l'échelle WAD vaut `2,000 * 10^18`. USD/ETH à la même échelle vaut `floor(10^36 / (2,000 * 10^18)) = 500,000,000,000,000`, soit `0.0005 ETH/USD`. Par ailleurs, avec `A_raw = 999,999`, `d_t = 6` et un prix de `2 * 10^18`, la multiplication-division complète donne `1,999,998,000,000,000,000` ; diviser d'abord le montant par `10^6` donne `0` et détruit toute la valeur.
- **Overflow intermédiaire et arrondi.** Soient `x = 2^200`, `y = 2^100` et le dénominateur `2^100`. Le résultat exact `2^200` tient dans `uint256`, mais `x * y = 2^300` n'y tient pas. La multiplication contrôlée effectue un revert et la multiplication unchecked fait un wrap ; un `mulDiv` en précision complète renvoie `2^200`. La division entière `5 / 2` arrondit vers le bas à `2`, tandis qu'une règle au plafond renvoie `3` ; l'arrondi fait donc partie de l'invariant économique.
## Risques
- Mauvaise adresse de chaîne, flux, proxy, adaptateur, token, vault ou consommateur.
- Orientation base/cotation inversée sans conversion réciproque.
- Token supposé avoir 18 décimales ou métadonnées facultatives absentes ou erronées.
- Flux supposé avoir 8 décimales au lieu de les lire et de les figer.
- Décimales du token de cotation confondues avec l'échelle WAD, RAY, de marché ou comptable.
- Décimales du wrapper, de la part, de l'indice ou du taux de change omises.
- Facteur d'échelle appliqué deux fois après normalisation par l'adaptateur.
- Facteur d'échelle ou dénominateur requis omis.
- Réponse signée convertie en unsigned avant vérification de sa positivité.
- Résultat nul, obsolète, incomplet, plafonné ou invalide accepté.
- Exposant décimal ou puissance de dix en underflow, overflow ou hors limites.
- Produit intermédiaire en overflow alors que le quotient final tient.
- Arithmétique unchecked, décalage de bits ou conversion restrictive provoquant wrap ou troncage silencieux.
- Division avant multiplication détruisant la précision ou réduisant le dust à zéro.
- Mauvais arrondi inférieur, supérieur ou au plus proche pour l'action.
- Conversions répétées accumulant perte de précision ou fuite systématique de valeur.
- Prix, plafonds, ratios, pourcentages, points de base, WAD et RAY comparés dans des unités différentes.
- Mises à niveau du flux, token, proxy, adaptateur ou vault invalidant les hypothèses de décimales mises en cache.
- Formatage du frontend, wallet, RPC ou indexeur masquant un calcul onchain différent.
- Mauvaise valorisation amplifiant emprunts, émissions, remboursements, liquidations, plafonds, créances irrécouvrables ou émission inéquitable de parts.
## Idées reçues
- **« Tous les tokens ERC-20 utilisent 18 décimales. »** La méthode de métadonnées ERC-20 est facultative, et les actifs déployés utilisent des valeurs et comportements différents.
- **« Tous les flux de prix en USD utilisent 8 décimales. »** La précision est une propriété de l'interface du déploiement exact et doit être lue et versionnée.
- **« Un entier brut élevé prouve une manipulation. »** Sa grandeur n'a aucun sens sans unités, direction, décimales, horodatage et échelle du consommateur.
- **« Solidity 0.8 rend la mise à l'échelle correcte. »** L'overflow contrôlé peut effectuer un revert, mais ne corrige ni unités, troncage, conversions ni politique d'arrondi.
- **« Multiplier avant de diviser ou ajouter des décimales améliore toujours la précision. »** Cela peut déborder, doubler l'échelle ou conserver la mauvaise unité ; même la précision complète exige une formule correcte.
## Thèmes associés
- [Vérification des décimales d'un token](/fr/crypto/token-decimals-verification/)
- [Oracle](/fr/crypto/oracle/)
- [Attaques d'oracle](/fr/crypto/oracle-attack/)
## Sources
- [Data Feeds API Reference](https://docs.chain.link/data-feeds/api-reference) - Chainlink Documentation (consulté le 2026-08-13)
- [Chainlink Data Feeds](https://docs.chain.link/data-feeds) - Chainlink Documentation (consulté le 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulté le 2026-08-13)
- [Types](https://docs.soliditylang.org/en/latest/types.html) - Solidity Documentation (consulté le 2026-08-13)
- [Expressions and Control Structures](https://docs.soliditylang.org/en/latest/control-structures.html#checked-or-unchecked-arithmetic) - Solidity Documentation (consulté le 2026-08-13)
- [Utils](https://docs.openzeppelin.com/contracts/5.x/api/utils) - OpenZeppelin Contracts Documentation (consulté le 2026-08-13)
- [Oracles](https://aave.com/docs/aave-v3/smart-contracts/oracles) - Aave Protocol Documentation (consulté le 2026-08-13)
- [Compound v2 Price Feed](https://docs.compound.finance/v2/prices/) - Compound Documentation (consulté le 2026-08-13)
Source: https://wiki.fcontext.com/fr/crypto/oracle-decimal-mismatch/index.mdx