---
title: "Come verificare i decimali di un token"
description: "Verifica i decimali di un ERC-20 sul contratto e sul blocco corretti, quindi riconcilia saldi grezzi, trasferimenti, autorizzazioni e conversioni bridge senza errori in virgola mobile."
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.
# Come verificare i decimali di un token
> Solo a fini educativi; non è consulenza finanziaria o di sicurezza. I decimali non provano identità, valore, copertura o sicurezza di un token.
## Risposta diretta
Per un token ERC-20, `decimals()` è un metadato facoltativo che indica alle interfacce come mostrare unità intere. Se restituisce `d`, l'importo visualizzato convenzionale è `raw / 10^d`. Non cambia l'aritmetica del contratto e non autentica il token. Prima di fidarti del risultato verifica rete, indirizzo esatto, codice o implementazione proxy e blocco.
Leggi `decimals()` direttamente tramite un RPC indipendente a un blocco specifico, decodifica il risultato ABI come `uint8` e confrontalo con il registro ufficiale dell'emittente e un explorer affidabile. Poi verifica la scala con valori grezzi di `balanceOf`, trasferimenti, autorizzazioni, ricevute ed eventi. Non presumere `18` se la chiamata manca, va in revert, restituisce dati malformati o contraddice altre prove.
## Come funziona
ERC-20 memorizza e trasferisce importi interi senza segno. Il livello di visualizzazione inserisce la virgola; il contratto riceve sempre interi. Converti l'input con stringhe decimali o interi a precisione arbitraria, mai con virgola mobile binaria. Una quantità è rappresentabile solo se moltiplicandola per `10^d` si ottiene un intero.
Poiché `decimals()` è facoltativo, un token conforme può ometterlo. Un'implementazione personalizzata o aggiornabile può restituire un valore inatteso o cambiare dopo un upgrade. Per un proxy ERC-1967 controlla indirizzo proxy, implementazione o beacon, amministratore ed eventi di upgrade; leggi lo stato all'indirizzo proxy e fissa ogni confronto allo stesso blocco.
Anche autorizzazioni e valori ERC-2612 `permit` sono interi grezzi. Un trasferimento mostrato correttamente non prova che autorizzazione, minimo del router, importo bridge o contabilità usino la stessa scala. I contratti sorgente e destinazione di un bridge possono avere decimali diversi: confronta valore leggibile e unità grezze su entrambi i lati secondo le regole documentate di conversione e arrotondamento.
Usa questa procedura:
1. Fissa ID della rete o dominio, contratto del token, numero del blocco, endpoint RPC e ora di osservazione.
2. Conferma l'indirizzo nel registro ufficiale dell'emittente; nome, simbolo, icona e risultati di ricerca non sono prove autorevoli.
3. Controlla il codice distribuito e se l'indirizzo è un proxy; annota implementazione o beacon, amministratore e upgrade recenti.
4. Chiama `decimals()`, decodifica `uint8` via ABI e registra successo, revert, vuoto o output malformato senza inserire un valore predefinito.
5. Leggi `balanceOf`, `totalSupply`, autorizzazione, calldata, ricevuta ed eventi grezzi a blocchi compatibili; formattali con la scala osservata.
6. Ricalcola trasferimenti, autorizzazioni, preventivi e bridge con interi, includendo commissioni, arrotondamento, residui, rebase o tasse di trasferimento.
7. Simula e invia una piccola operazione, poi riconcilia i saldi grezzi prima e dopo; fermati se interfaccia, RPC, evento o saldo non coincidono.
## Esempi
- **Un valore grezzo, due scale.** Con `raw = 123456789`, `d = 6` mostra `123.456789`; con `d = 18`, `0.000000000123456789`. La differenza è un fattore di `10^12`.
- **La rappresentabilità conta.** Con `d = 6`, `1.25` token diventano `1250000` unità grezze. `0.0000001` token è meno di un'unità e va rifiutato o arrotondato secondo una regola esplicita.
- **Autorizzazione scalata male.** Un'autorizzazione di `100` token con `d = 6` è `100000000`. Codificata con `d = 18` diventa `100000000000000000000`, cioè `10^12` volte maggiore.
- **Riscalatura bridge.** Se una rotta documentata `1:1` converte un token sorgente con `d = 6` in una rappresentazione destinazione con `d = 18`, `2500000` grezzo rappresenta `2.5` token e `2500000000000000000` a destinazione rappresenta `2.5`. Commissioni, limiti, residui e saldo ricevuto vanno comunque verificati.
## Rischi
- L'indirizzo corretto viene interrogato sulla rete sbagliata.
- Nome, simbolo o icona copiati nascondono un altro contratto.
- Implementazione proxy o beacon cambiano dopo la verifica.
- RPC o explorer forniscono stato vecchio, non finalizzato o incoerente.
- Metadati assenti o malformati vengono sostituiti silenziosamente con `18`.
- La virgola mobile binaria arrotonda un importo grande o preciso.
- Il wallet formatta bene il trasferimento ma male autorizzazione o permit.
- Un database mescola unità grezze e importi leggibili.
- Un bridge presume decimali uguali o non dichiara l'arrotondamento dei residui.
- Commissione sul trasferimento, rebase, mint, burn, pausa o blocco rompono la riconciliazione semplice.
- Calldata, eventi, ricevute e variazioni effettive del saldo non coincidono.
- La verifica dei decimali è scambiata per prova di emittente, riserve, liquidità o sicurezza.
## Errori comuni
- **Tutti gli ERC-20 hanno `18` decimali.** Il metadato è facoltativo e un'implementazione può restituire altro.
- **I decimali sono bit di precisione usati dalla EVM.** Sono una convenzione di visualizzazione in base dieci; l'aritmetica resta intera.
- **Il saldo formattato dell'explorer è una conferma indipendente.** Può dipendere dalla stessa chiamata e condividere lo stesso errore.
- **Stesso simbolo e decimali identificano lo stesso asset.** Servono anche rete corretta, contratto esatto e prove dell'emittente.
- **Un piccolo trasferimento riuscito valida ogni integrazione.** Autorizzazioni, router, bridge, exchange e contabilità possono scalare separatamente.
## Argomenti correlati
- [Verifica del contratto del token](/crypto/token-contract-verification/)
- [Decodifica della calldata nel wallet](/crypto/calldata-decoding-wallet/)
- [Verifica dei token bridge](/crypto/bridge-token-verification/)
- [Rischio dei token con commissione di trasferimento](/crypto/fee-on-transfer-token-risk/)
- [Contratto proxy](/crypto/proxy-contract/)
## Fonti
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultato: 2026-08-21)
- [ERC-20](https://docs.openzeppelin.com/contracts/5.x/erc20) - OpenZeppelin Docs (consultato: 2026-08-21)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - ethereum.org (consultato: 2026-08-21)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consultato: 2026-08-21)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (consultato: 2026-08-21)
Source: https://wiki.fcontext.com/it/crypto/token-decimals-verification/index.mdx