Vai al contenuto
Financial Context Wiki

Come verificare i decimali di un token

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.

Aggiornato

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

Fonti

Navigazione

Cerca nella wiki...