Offerta e decimali

EN fonte principale · P08-L02 · 45 minuti stimati · needs_review

Un errore di decimali può trasformare novemila token in nove senza cambiare un solo saldo sottostante. Una definizione di offerta etichettata male può far sembrare contraddittori due calcoli corretti. Prima di valutare un asset o descriverne la distribuzione, stabilire unità, contesto ed esclusioni.

Questa lezione insegna conversione esatta da grezzo a visualizzato e riconciliazione dell’offerta. Si basa sull’identità verificata anziché presumere che ogni token usi diciotto decimali.

Tenere separati interi e presentazione

Sia R un importo intero grezzo e d il numero verificato di decimali. La sua quantità ordinaria visualizzata è R diviso per 10^d. L’unità grezza è l’unità contabile indivisibile in questo modello; i decimali definiscono precisione di presentazione, non numero di proprietari o prezzo di mercato. Lo stato del mint Solana include offerta e decimali [S08-TOKENS]. Il metodo decimals ERC-20 è opzionale nello standard [S08-ERC20]; metadati non disponibili non vanno sostituiti da un valore predefinito indovinato.

Usare stringhe di interi o aritmetica decimale esatta. Un foglio di calcolo o un numero in virgola mobile JavaScript può arrotondare un grande valore grezzo prima che tu lo divida. Memorizzare intero originario, numero di decimali, contesto e valore visualizzato come campi distinti. Se uno strumento riporta un valore visualizzato arrotondato, calcolare dall’input grezzo anziché trattare la visualizzazione come esatta.

Uno zero riportato e un risultato mancante sono diversi. Zero è una misurazione valida secondo una fonte/contesto dichiarati; null o timeout descrive prove mancanti. Un numero di decimali mancante impedisce una conversione affidabile in unità ordinarie anche quando i saldi grezzi restano disponibili. Registrare l’importo grezzo senza dichiarare una quantità di token.

Riconciliare misure prima di confrontarle

L’offerta totale descrive la misura contabile del protocollo a un contesto specificato. L’offerta circolante richiede una policy d’inclusione definita. Inventario di tesoreria, vesting e custodia di bridge possono ricevere trattamenti diversi da editori diversi. Un’etichetta senza policy non può risolvere una discrepanza.

Solana getTokenSupply restituisce importo grezzo e decimali con contesto della risposta [S08-SUPPLY]. Non è una misura circolante definita indipendentemente. Non sottrarre l’offerta già rettificata di un editore dai totali grezzi senza esaminare cosa abbia escluso.

Per un materiale contabile standard chiuso, i saldi dovrebbero riconciliarsi al totale fornito. Indagini reali devono esaminare se l’esportazione sia esaustiva, usi contesti corrispondenti e decodifichi correttamente le estensioni. Alcuni meccanismi di token complicano la semplice somma dei saldi; dichiarare quel limite anziché forzare ogni asset in questo modello.

Le esclusioni non distruggono token. Rimuovere unità di tesoreria da un denominatore analitico produce una statistica rettificata, non un evento del registro che cambia l’offerta. Analogamente, un trasferimento a un indirizzo descritto come indirizzo di burn non è automaticamente una riduzione di totalSupply del protocollo. Il meccanismo effettivo di burn e il cambiamento contabile richiedono prove.

Tracciare cambiamenti senza cambiare l’unità

Un mint aumenta l’offerta contabile totale nel materiale. Un burn del protocollo la riduce. Trasferimenti ordinari tra account inclusi riorganizzano la proprietà senza cambiare il totale. Se la sequenza fornita è completa, la nuova offerta è uguale alla vecchia più unità emesse meno unità distrutte.

Associare contesto a ogni evento e importo. Se un’istantanea successiva differisce dalla somma degli eventi, verificare copertura incompleta, mint incoerente o precisione errata prima di dichiarare manipolazione. Una differenza è una mancata riconciliazione che richiede indagine; non un verdetto sulle intenzioni.

I decimali devono essere verificati per oggetto e contesto esatti. Due asset con lo stesso simbolo possono avere precisioni diverse. Un’impostazione errata del flusso può produrre una discrepanza di un fattore mille quando d differisce di tre. Non «riparare» mai il saldo grezzo per farlo coincidere con un sito.

Usare un ponte di confronto

Quando due rapporti discordano, disporre in colonne importo grezzo, decimali, conversione delle unità, contesto dell’istantanea e policy d’esclusione. Questo rende visibili domande diverse. Un rapporto può essere corretto per offerta totale mentre un altro usa correttamente un denominatore rettificato. Dovrebbero essere nominati separatamente, non mediati.

Se due fonti dichiarano stessa definizione e stesso contesto e discordano ancora, mantenere entrambi i record e una discrepanza irrisolta. Non scegliere il numero maggiore perché sembra più sicuro o il minore perché migliora una percentuale di concentrazione. Un risultato circoscritto dichiara la discrepanza e la verifica successiva.

Le percentuali eliminano un fattore decimale comune soltanto quando numeratore e denominatore si riferiscono alla stessa precisione e ambito del token. Confrontare un numeratore grezzo con un denominatore visualizzato produce un risultato senza significato. Può essere numericamente ordinato e comunque sbagliato.

Comunicare quantità riproducibili

Scrivere unità su ogni riga. «2,500» da solo potrebbe significare unità grezze, token o dollari. Questa lezione usa unità fittizie di token e non fornisce prezzo di mercato o valutazione in dollari. Una riconciliazione corretta dell’offerta non dice nulla su liquidità eseguibile, apprezzamento del prezzo o legittimità dell’emittente.

Preservare precisione completa nella chiave delle risposte e arrotondare soltanto per visualizzare. Spiegare la policy d’arrotondamento quando una frazione è periodica. Per questo materiale le conversioni terminano esattamente, quindi non va nascosto alcun residuo arrotondato.

• Importo grezzo: unità contabili intere.
• Decimali: precisione di visualizzazione in base dieci.
• Offerta totale: misura contabile del protocollo a un contesto.
• Offerta rettificata: misura di esclusione dichiarata dall’analista.
• Riconciliazione: confronto di somme e cambiamenti compatibili.
• Contesto dell’istantanea: limite di stato per un’osservazione.

ILLUSTRATIVE — FIX-P08-02. MINT-SUPPLY su SIM-SOL-A, modello contabile standard di base, d=6 a S0 sintetico. Sono forniti saldi esaustivi; tutti gli identificatori sono etichette invalide.

Il totale grezzo T0 è 9,000,000,000. Il flusso F1 imposta erroneamente d=9 e visualizza 9. La policy E esclude soltanto B3/B4. Una sequenza sintetica completa di eventi fino a S1 distrugge 500,000,000 unità grezze ed emette 750,000,000; non ci sono altri cambiamenti d’offerta. L’allocazione degli account S1 non è fornita.

OBSERVED nel materiale: Precisione, totale e saldi S0 sono forniti. F1 usa precisione sbagliata.

INFERRED: Il totale S0 è 9,000 token; la quantità rettificata della policy E è 4,000. Eventi completi implicano totale S1 9,250 token.

UNKNOWN: Qualsiasi misura circolante reale, allocazione S1, prezzo o liquidità.

INSUFFICIENT EVIDENCE: Il 4,000 rettificato non è un burn del protocollo o un’offerta circolante universale. La discrepanza dei decimali non è prova di intenzioni malevole.

Presumere diciotto decimali; mescolare unità grezze/visualizzate; contare esclusioni come burn; importare interi arrotondati; confrontare contesti non corrispondenti; e chiamare una misura rettificata secondo policy «l’offerta circolante».

Convertire T0 e tutti e quattro i saldi. Riconciliare S0. Calcolare denominatore della policy E, quota del Proprietario A rispetto a totale e quantità rettificata, e totale S1. Spiegare l’errore di fattore di F1 e se si possa calcolare la concentrazione dei detentori S1.

• Verificare asset esatto e numero di decimali.
• Preservare interi grezzi.
• Etichettare unità e arrotondamento.
• Riconciliare contesti corrispondenti.
• Dichiarare ogni esclusione e la sua policy.
• Tenere sconosciuti saldi successivi mancanti.

Precisione e definizione precedono il confronto dell’offerta. Un’esclusione secondo policy cambia il denominatore analitico; un evento del registro cambia l’offerta contabile.

Unità grezze non sono token visualizzati. Policy diverse dell’offerta rispondono a domande diverse. Un totale corretto non fornisce distribuzione o liquidità correnti.

Mostrare scala di conversione grezzo→visualizzato d=6, riconciliazione dei saldi S0, barre separate per totale 9,000 e policy E4,000. Segnare F1 d=9 come discrepanza di precisione; mostrare totale S1 9,250 senza un grafico inventato dei detentori.

Unità e policy dell’offerta illustrative; nessun prezzo o stima circolante reale.

Usare SVG/HTML deterministici o grafici con alternative testuali, blu navy scuro/nero e accenti sobri ciano, blu elettrico e viola. Etichettare ogni quantità e incertezza. A 390px impilare i pannelli; verifica a 768px/desktop e RTL arabo restano lavoro futuro sulle risorse. Tenere gli identificatori in LTR e invariati assi fattuali/direzioni degli archi. Usare soltanto il marchio ufficiale BlockAssay fornito se viene aggiunto il marchio. Entrambi i record sono specifiche, non risorse consegnate.

Usare RADAR per lo scopo educativo circoscritto della lezione soltanto se sono verificati supporto della rete, identità esatta, campi e provenienza. Questo contenuto non afferma alcun endpoint runtime o capacità del fornitore. Usare il materiale offline incorporato senza accesso a pagamento. I dati mancanti restano sconosciuti; non sono necessari collegamento a wallet, firma di transazioni, lancio di token o operazioni dal vivo. Progressi nell’Academy, pagamenti e referral non cambiano mai le prove di Radar. Un Diagnostic Passport preserva osservazioni e limiti, non una previsione di prezzo o un certificato di sicurezza.

• Asset Solana — Identità di mint/account/programma e decimali; distinguere campi di proprietà degli account. Verificato 2026-09-30.
• Solana getTokenSupply — Offerta grezza, decimali e contesto della risposta RPC; non una definizione di offerta circolante. Verificato 2026-09-30.
• Standard di token ERC-20 — Interfaccia standard; nome, simbolo e decimali opzionali; non certificazione di privilegi o identità. Verificato 2026-09-30.

La documentazione sostiene meccanismi, non valori dei dataset fittizi. Tutti gli esempi e i record degli esercizi sono materiale originale ILLUSTRATIVE, fissato in questo file. S0/S1 sono etichette di contesto sintetiche; observedAt è null perché non è stata raccolta alcuna misurazione di un registro dal vivo o storico. Riesaminare documentazione e comportamento effettivamente distribuito prima di qualsiasi pubblicazione o integrazione.

P08-L03 dopo l’esercizio svolto e la revisione del quiz.