Offre et décimales

Source maître EN · P08-L02 · 45 minutes estimées · needs_review

Une erreur de décimales peut transformer neuf mille jetons en neuf jetons sans changer un seul solde sous-jacent. Une définition d’offre mal étiquetée peut faire paraître contradictoires deux calculs corrects. Avant de valoriser un actif ou de décrire sa distribution, établir unités, contexte et exclusions.

Cette leçon enseigne la conversion exacte du brut à l’affichage et un rapprochement d’offre. Elle s’appuie sur une identité vérifiée plutôt que de supposer que chaque jeton utilise dix-huit décimales.

Distinguer entiers et présentation

Soit R un montant entier brut et d le nombre vérifié de décimales. Sa quantité ordinairement affichée est R divisé par 10^d. L’unité brute est l’unité comptable indivisible dans ce modèle ; les décimales définissent la précision de présentation, pas le nombre de propriétaires ni un prix de marché. L’état de mint Solana inclut offre et décimales [S08-TOKENS]. La méthode decimals ERC-20 est facultative dans la norme [S08-ERC20] ; les métadonnées indisponibles ne doivent pas être remplacées par une valeur par défaut devinée.

Utiliser des chaînes d’entiers ou une arithmétique décimale exacte. Un tableur ou un nombre JavaScript à virgule flottante peut arrondir une grande valeur brute avant la division. Stocker l’entier original, le nombre de décimales, le contexte et la valeur affichée comme champs distincts. Si un outil rapporte une valeur affichée arrondie, calculer depuis l’entrée brute plutôt que de traiter l’affichage comme exact.

Un zéro rapporté et un résultat manquant sont différents. Zéro est une mesure valide selon une source/un contexte déclarés ; null ou un délai dépassé décrit des preuves manquantes. Un nombre de décimales manquant empêche la conversion fiable en unités ordinaires même lorsque les soldes bruts restent disponibles. Consigner le montant brut sans revendiquer une quantité de jetons.

Rapprocher les mesures avant de les comparer

L’offre totale décrit la mesure comptable du protocole dans un contexte précisé. L’offre en circulation exige une politique d’inclusion définie. Les stocks de trésorerie, l’acquisition progressive et la garde de pont peuvent être traités différemment selon l’éditeur. Un libellé sans politique ne peut résoudre un écart.

Solana getTokenSupply renvoie montant brut et décimales avec contexte de réponse [S08-SUPPLY]. Ce n’est pas une mesure de circulation définie indépendamment. Ne pas soustraire l’offre déjà ajustée d’un éditeur des totaux bruts sans inspecter ce qu’elle exclut.

Pour un jeu comptable standard fermé, les soldes doivent se rapprocher du total fourni. Les investigations réelles doivent inspecter si l’export est exhaustif, utilise des contextes correspondants et décode correctement les extensions. Certains mécanismes de jetons compliquent la simple somme des soldes ; indiquer cette limite au lieu de forcer chaque actif dans ce modèle.

Les exclusions ne détruisent pas les jetons. Retirer des unités de trésorerie d’un dénominateur analytique produit une statistique ajustée, pas un événement de registre modifiant l’offre. De même, un transfert vers une adresse décrite comme adresse de destruction ne réduit pas automatiquement le totalSupply du protocole. Le mécanisme réel de destruction et le changement comptable exigent des preuves.

Suivre les changements sans changer l’unité

Une émission augmente l’offre comptable totale dans le jeu. Une destruction protocolaire la diminue. Les transferts ordinaires entre comptes inclus redistribuent la propriété sans changer le total. Si la séquence fournie est complète, la nouvelle offre égale l’ancienne plus les unités émises moins les unités détruites.

Associer le contexte à chaque événement et montant. Si un instantané ultérieur diffère de votre somme d’événements, tester une couverture incomplète, un mint incohérent ou une précision incorrecte avant de déclarer une manipulation. Une différence est un échec de rapprochement exigeant une investigation ; ce n’est pas un verdict d’intention.

Les décimales doivent être vérifiées pour l’objet et le contexte exacts. Deux actifs de même symbole peuvent avoir des précisions différentes. Un réglage incorrect de flux peut produire un écart d’un facteur mille lorsque d diffère de trois. Ne jamais « réparer » le solde brut pour le faire correspondre à un site.

Utiliser un tableau de rapprochement

Lorsque deux rapports divergent, placer montant brut, décimales, conversion d’unités, contexte d’instantané et politique d’exclusion en colonnes. Cela rend visibles les différentes questions. Un rapport peut être correct pour l’offre totale tandis qu’un autre utilise correctement un dénominateur ajusté. Les nommer séparément, pas en faire la moyenne.

Si deux sources affirment la même définition dans le même contexte et divergent encore, conserver les deux enregistrements et un écart non résolu. Ne pas sélectionner le nombre supérieur parce qu’il paraît plus sûr ni l’inférieur parce qu’il améliore un pourcentage de concentration. Un constat circonscrit précise la discordance et la prochaine vérification.

Les pourcentages annulent un facteur décimal commun uniquement si numérateur et dénominateur concernent la même précision et le même périmètre de jeton. Comparer un numérateur brut à un dénominateur affiché produit un résultat sans sens. Il peut être numériquement élégant et pourtant faux.

Communiquer des quantités reproductibles

Écrire les unités sur chaque ligne. « 2,500 » seul pourrait signifier unités brutes, jetons ou dollars. Cette leçon utilise des unités fictives de jeton et ne fournit aucun prix de marché ni valorisation en dollars. Un rapprochement correct d’offre ne dit rien sur la liquidité exécutable, l’appréciation du prix ou la légitimité de l’émetteur.

Préserver la pleine précision dans la correction et n’arrondir que pour l’affichage. Expliquer la politique d’arrondi lorsqu’une fraction se répète. Dans ce jeu, les conversions se terminent exactement, donc aucun résidu arrondi n’a besoin d’être caché.

• Montant brut : unités comptables entières.
• Décimales : précision d’affichage en base dix.
• Offre totale : mesure comptable du protocole dans un contexte.
• Offre ajustée : mesure d’exclusion déclarée de l’analyste.
• Rapprochement : comparaison de sommes et changements compatibles.
• Contexte d’instantané : limite d’état pour une observation.

ILLUSTRATIVE — FIX-P08-02. MINT-SUPPLY sur SIM-SOL-A, modèle comptable standard de base, d=6 à S0 synthétique. Des soldes exhaustifs sont fournis ; tous les identifiants sont des libellés invalides.

Le total brut T0 est 9,000,000,000. Le flux F1 fixe par erreur d=9 et affiche 9. La politique E exclut uniquement B3/B4. Une séquence synthétique complète d’événements jusqu’à S1 détruit 500,000,000 unités brutes et en émet 750,000,000 ; aucun autre changement d’offre n’existe. L’allocation des comptes à S1 n’est pas fournie.

OBSERVED dans le jeu : Précision, total et soldes de S0 sont fournis. F1 utilise la mauvaise précision.

INFERRED: Le total S0 est 9,000 jetons ; la quantité ajustée selon politique E est 4,000. Les événements complets impliquent un total S1 de 9,250 jetons.

UNKNOWN: Toute mesure réelle en circulation, allocation S1, prix ou liquidité.

INSUFFICIENT EVIDENCE: Les 4,000 ajustés ne sont pas une destruction protocolaire ni une offre en circulation universelle. La discordance de décimales ne prouve pas une intention malveillante.

Supposer dix-huit décimales ; mélanger unités brutes/affichées ; compter les exclusions comme destructions ; importer des entiers arrondis ; comparer des contextes non correspondants ; et nommer une mesure ajustée selon une politique « l’ » offre en circulation.

Convertir T0 et les quatre soldes. Rapprocher S0. Calculer le dénominateur de la politique E, la part du propriétaire A du total et de la quantité ajustée, et le total S1. Expliquer l’erreur de facteur de F1 et si la concentration des détenteurs à S1 peut être calculée.

• Vérifier l’actif exact et le nombre de décimales.
• Préserver les entiers bruts.
• Étiqueter unités et arrondi.
• Rapprocher les contextes correspondants.
• Indiquer chaque exclusion et sa politique.
• Garder les soldes ultérieurs manquants inconnus.

Précision et définition précèdent la comparaison d’offre. Une exclusion de politique change le dénominateur analytique ; un événement de registre change l’offre comptable.

Les unités brutes ne sont pas des jetons affichés. Les différentes politiques d’offre répondent à différentes questions. Un total correct ne fournit pas la distribution actuelle ni la liquidité.

Montrer une échelle de conversion brut→affichage d=6, le rapprochement des soldes S0, des barres distinctes de total 9,000 et de politique E4,000. Marquer F1 d=9 comme discordance de précision ; montrer le total S1 9,250 sans graphique fabriqué de détenteurs.

Unités et politiques d’offre illustratives ; aucun prix ni estimation réelle de circulation.

Utiliser du SVG/HTML déterministe ou des graphiques avec alternatives textuelles, bleu marine foncé/noir et accents mesurés cyan, bleu électrique et violet. Étiqueter chaque quantité et incertitude. À 390px, empiler les panneaux ; la vérification 768px/ordinateur et RTL arabe reste un travail futur sur les actifs. Garder les identifiants LTR et les axes factuels/sens des arêtes inchangés. Utiliser uniquement la marque officielle BlockAssay fournie si une identité de marque est ajoutée. Les deux enregistrements sont des spécifications, pas des actifs livrés.

Utiliser RADAR pour l’objectif pédagogique circonscrit de la leçon uniquement si la prise en charge du réseau, l’identité exacte, les champs et la provenance sont vérifiés. Ce contenu n’affirme aucun point de terminaison d’exécution ni capacité de fournisseur. Utiliser le jeu hors ligne intégré sans accès payant. Les données manquantes restent inconnues ; aucune connexion de portefeuille, signature de transaction, lancement de jeton ou transaction en direct n’est requis. Les progrès Academy, paiements et recommandations ne changent jamais les preuves Radar. Un Passeport diagnostique préserve observations et limites, pas une prévision de prix ni un certificat de sécurité.

• Actifs Solana — Identité mint/compte/programme et décimales ; distinguer les champs de propriété de compte. Vérifié le 2026-09-30.
• Solana getTokenSupply — Offre brute, décimales et contexte de réponse RPC ; pas une définition d’offre en circulation. Vérifié le 2026-09-30.
• Norme de jeton ERC-20 — Interface standard ; nom, symbole et décimales facultatifs ; aucune certification de privilèges ou d’identité. Vérifié le 2026-09-30.

La documentation étaye les mécanismes, pas les valeurs fictives du jeu. Tous les exemples et enregistrements d’exercice sont du matériel original ILLUSTRATIVE, figé dans ce fichier. S0/S1 sont des libellés synthétiques de contexte ; observedAt est null car aucune mesure de registre en direct ou historique n’a été collectée. Réexaminer la documentation et le comportement réellement déployé avant toute publication ou intégration.

P08-L03 après l’exercice corrigé et l’examen du quiz.