---
title: "Disallineamenti dei decimali negli oracoli"
description: "Un disallineamento dei decimali applica la scala di unità errata a una risposta dell'oracolo, una quantità di token, un tasso del wrapper o un valore del protocollo, causando errori di ordini di grandezza in prestiti, emissioni, rimborsi e liquidazioni."
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.
# Disallineamenti dei decimali negli oracoli
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Un disallineamento dei decimali dell'oracolo si verifica quando un contratto interpreta un intero grezzo con l'esponente dell'unità, la direzione del prezzo o la scala interna errati. I decimali del feed, del token e del token di quotazione, le scale dei tassi di wrapper o quote e le convenzioni WAD o RAY del protocollo sono indipendenti. Un frontend apparentemente corretto non dimostra che il contratto consumer esegua la stessa aritmetica.
Per una quantità grezza del token base `A_raw` con `d_t` decimali e una risposta positiva del feed `P_raw` che quota un token base in token di quotazione con `d_p` decimali, la quantità grezza del token di quotazione con `d_q` decimali è `V_raw = round(A_raw * P_raw * 10^d_q / 10^(d_t + d_p))`. La formula vale solo per la direzione indicata e dopo aver validato feed, unità, tipi e regola di arrotondamento. Un adapter che ha già normalizzato un valore non deve scalarlo di nuovo.
In ERC-20, `decimals()` è un metadato di visualizzazione facoltativo, non una garanzia universale di 18 decimali. Il `decimals()` di un feed descrive la risposta del feed, non la scala del token o del protocollo. L'aritmetica controllata può bloccare un overflow con un revert, ma non rileva una formula dimensionalmente errata e può trasformare un risultato rappresentabile in denial of service se trabocca un prodotto intermedio.
## Come funziona
1. Fissare chain, blocco, consumer, adapter, proxy e aggregatore del feed, token o vault, versioni del compilatore e della libreria matematica e stato dell'upgrade.
2. Inventariare ogni intero con tipo e unità: quantità grezza, decimali del token, risposta con segno e decimali del feed, orientamento base/quotazione, tasso di wrapper o quota, scala interna e decimali del token di output.
3. Validare la fonte prima della conversione: indirizzo e direzione corretti, risposta positiva, timestamp e stato, età e intervallo accettabili, semantica del fallback e regole del periodo di grazia del sequencer L2.
4. Derivare un'unica formula dimensionale dalle unità grezze di input a quelle di output. Distinguere esplicitamente aumento e riduzione della scala, limitare ogni esponente di dieci e normalizzare ogni componente una sola volta.
5. Usare un multiply-divide a precisione completa verificato o una cancellazione limitata. Evitare troncamento da divisione anticipata, overflow intermedio controllato, wraparound unchecked e cast con segno o restrittivi non sicuri.
6. Specificare arrotondamento per difetto, eccesso o al più vicino per ogni azione. Garanzia, debito, prestito, emissione, rimborso, commissioni, liquidazione e conversione di quote possono richiedere direzioni conservative diverse.
7. Testare vettori noti e proprietà su importi estremi, combinazioni di decimali, reciproci, feed composti, risposte nulle, negative e obsolete, upgrade e dust; riconciliare i risultati onchain con un modello indipendente ad alta precisione e limitare l'esposizione.
La normalizzazione è analisi dimensionale, non formattazione. `BTC/USD` e `USD/BTC` richiedono formule reciproche; cambiare etichetta non inverte un prezzo. I feed composti richiedono scala e timestamp di ogni componente. La divisione intera di Solidity tronca verso zero, quindi riordinamenti algebricamente equivalenti possono produrre risultati onchain diversi. Un `mulDiv` a precisione completa risolve il problema della larghezza intermedia, ma richiede comunque numeratore, denominatore, unità, limiti e direzione di arrotondamento corretti.
## Esempi svolti
- **Otto contro diciotto decimali.** Un feed BTC/USD restituisce `6,000,000,000,000` con `d_p = 8`, quindi il prezzo è `60,000 USD/BTC`. Interpretare la risposta grezza a 18 decimali produce `0.000006 USD/BTC`, una sottovalutazione di `10^10`, non `10^9`. La scalatura a WAD dà `6,000,000,000,000 * 10^(18 - 8) = 60,000,000,000,000,000,000,000`.
- **Unità di quantità, prezzo e output.** `A_raw = 2,500,000` rappresenta `2.5` token con `d_t = 6`; `P_raw = 200,000,000` rappresenta `2` token di quotazione con `d_p = 8`. Per un valore interno a 18 decimali, `2,500,000 * 200,000,000 * 10^18 / 10^(6 + 8) = 5,000,000,000,000,000,000`, ossia `5 quote tokens`. Omettere il denominatore del token sopravvaluta la posizione di `10^6`.
- **Reciproco e troncamento.** ETH/USD in scala WAD è `2,000 * 10^18`. USD/ETH alla stessa scala è `floor(10^36 / (2,000 * 10^18)) = 500,000,000,000,000`, ossia `0.0005 ETH/USD`. Separatamente, con `A_raw = 999,999`, `d_t = 6` e prezzo `2 * 10^18`, il multiply-divide completo produce `1,999,998,000,000,000,000`; dividere prima la quantità per `10^6` produce `0` e perde tutto il valore.
- **Overflow intermedio e arrotondamento.** Siano `x = 2^200`, `y = 2^100` e il denominatore `2^100`. Il risultato esatto `2^200` rientra in `uint256`, ma `x * y = 2^300` no. La moltiplicazione controllata effettua revert e quella unchecked va in wrap; `mulDiv` a precisione completa restituisce `2^200`. La divisione intera `5 / 2` arrotonda per difetto a `2`, mentre una regola per eccesso restituisce `3`; l'arrotondamento fa quindi parte dell'invariante economica.
## Rischi
- Indirizzo errato di chain, feed, proxy, adapter, token, vault o consumer.
- Orientamento base/quotazione invertito senza conversione reciproca.
- Si presumono 18 decimali del token oppure i metadati facoltativi sono assenti o errati.
- Si presumono 8 decimali del feed anziché leggerli e fissarli.
- I decimali del token di quotazione sono confusi con scala WAD, RAY, di mercato o contabile.
- Decimali di wrapper, quota, indice o tasso di cambio omessi.
- Fattore di scala applicato due volte dopo la normalizzazione dell'adapter.
- Fattore di scala o denominatore necessario omesso.
- Risposta con segno convertita in unsigned prima di verificarne la positività.
- Risultato nullo, obsoleto, incompleto, limitato o non valido accettato.
- Esponente decimale o potenza di dieci va in underflow, overflow o supera i limiti.
- Prodotto intermedio va in overflow sebbene il quoziente finale sia rappresentabile.
- Aritmetica unchecked, bit shift o narrowing cast effettuano wrap o troncano silenziosamente.
- Dividere prima di moltiplicare distrugge precisione o riduce il dust a zero.
- Arrotondamento per difetto, eccesso o al più vicino errato per l'azione.
- Conversioni ripetute accumulano perdita di precisione o dispersione sistematica di valore.
- Prezzi, cap, rapporti, percentuali, punti base, WAD e RAY sono confrontati in unità diverse.
- Upgrade di feed, token, proxy, adapter o vault invalidano ipotesi sui decimali in cache.
- Formattazione di frontend, wallet, RPC o indexer nasconde un calcolo onchain diverso.
- Valutazione errata amplifica prestiti, emissioni, rimborsi, liquidazioni, cap, crediti inesigibili o emissione iniqua di quote.
## Idee errate comuni
- **«Ogni token ERC-20 usa 18 decimali».** Il metodo dei metadati ERC-20 è facoltativo e gli asset implementati usano valori e comportamenti differenti.
- **«Ogni feed di prezzo in USD usa 8 decimali».** La precisione è una proprietà dell'interfaccia dello specifico deployment e deve essere letta e versionata.
- **«Un grande intero grezzo dimostra manipolazione».** La grandezza non significa nulla senza unità, direzione, decimali, timestamp e scala del consumer.
- **«Solidity 0.8 rende corretta la scalatura».** L'overflow controllato può effettuare revert, ma non corregge unità, troncamento, cast o regole di arrotondamento.
- **«Moltiplicare prima di dividere o aggiungere decimali migliora sempre la precisione».** Può causare overflow, doppia scalatura o preservare l'unità errata; anche l'aritmetica a precisione completa richiede la formula corretta.
## Argomenti correlati
- [Verifica dei decimali dei token](/it/crypto/token-decimals-verification/)
- [Oracolo](/it/crypto/oracle/)
- [Attacchi agli oracoli](/it/crypto/oracle-attack/)
## Fonti
- [Data Feeds API Reference](https://docs.chain.link/data-feeds/api-reference) - Chainlink Documentation (consultato: 2026-08-13)
- [Chainlink Data Feeds](https://docs.chain.link/data-feeds) - Chainlink Documentation (consultato: 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [Types](https://docs.soliditylang.org/en/latest/types.html) - Solidity Documentation (consultato: 2026-08-13)
- [Expressions and Control Structures](https://docs.soliditylang.org/en/latest/control-structures.html#checked-or-unchecked-arithmetic) - Solidity Documentation (consultato: 2026-08-13)
- [Utils](https://docs.openzeppelin.com/contracts/5.x/api/utils) - OpenZeppelin Contracts Documentation (consultato: 2026-08-13)
- [Oracles](https://aave.com/docs/aave-v3/smart-contracts/oracles) - Aave Protocol Documentation (consultato: 2026-08-13)
- [Compound v2 Price Feed](https://docs.compound.finance/v2/prices/) - Compound Documentation (consultato: 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/oracle-decimal-mismatch/index.mdx