Zum Inhalt springen
Financial Context Wiki

Token-Dezimalstellen verifizieren

Prüfen Sie die Dezimalstellen eines ERC-20 am richtigen Vertrag und Block und gleichen Sie Rohsalden, Transfers, Freigaben und Bridge-Umrechnungen ohne Gleitkommafehler ab.

Aktualisiert

Nur zu Bildungszwecken; keine Anlage- oder Sicherheitsberatung. Dezimalstellen beweisen weder Identität, Wert, Deckung noch Sicherheit eines Tokens.

Direkte Antwort

Bei einem ERC-20-Token ist decimals() ein optionales Metadatum, das Oberflächen die Anzeige ganzzahliger Token-Einheiten vorgibt. Liefert es d, ist der übliche Anzeigebetrag raw / 10^d. Es ändert die Vertragsarithmetik nicht und authentifiziert den Token nicht. Prüfen Sie vor Vertrauen in das Ergebnis Chain, exakte Vertragsadresse, Code oder Proxy-Implementierung und Block.

Lesen Sie decimals() über einen unabhängigen RPC an einem bestimmten Block, dekodieren Sie die ABI-Rückgabe als uint8 und vergleichen Sie sie mit dem offiziellen Vertragsregister des Emittenten und einem verlässlichen Explorer. Testen Sie die Skalierung danach gegen rohe balanceOf-, Transfer-, Freigabe-, Receipt- und Eventwerte. Nehmen Sie nicht stillschweigend 18 an, wenn der Aufruf fehlt, revertiert, fehlerhafte Daten liefert oder anderen Belegen widerspricht.

Funktionsweise

ERC-20 speichert und überträgt vorzeichenlose Ganzzahlen. Die Anzeige fügt das Dezimaltrennzeichen ein; der Vertrag erhält weiterhin Ganzzahlen. Wandeln Sie Eingaben mit Dezimalstrings oder Ganzzahlen beliebiger Genauigkeit um, niemals mit binärem Gleitkomma. Eine Menge ist nur darstellbar, wenn die Multiplikation mit 10^d eine Ganzzahl ergibt.

Da decimals() optional ist, kann ein konformer Token es auslassen. Eine eigene oder aktualisierbare Implementierung kann unerwartete Werte liefern oder nach einem Upgrade anders reagieren. Prüfen Sie bei einem ERC-1967-Proxy die Proxy-Adresse, Implementierung oder Beacon, Administrator und Upgrade-Events; lesen Sie Token-Zustand an der Proxy-Adresse und vergleichen Sie alles am selben Block.

Freigaben und ERC-2612-permit-Werte sind ebenfalls rohe Ganzzahlen. Ein korrekt angezeigter Transfer beweist nicht, dass Freigabe, Router-Minimum, Bridge-Betrag oder Buchhaltung dieselbe Skalierung nutzten. Quell- und Zielverträge einer Bridge können verschiedene Dezimalstellen haben; vergleichen Sie Anzeigewert und Roheinheiten beider Seiten nach den dokumentierten Umrechnungs- und Rundungsregeln.

Gehen Sie so vor:

  1. Fixieren Sie Chain-ID oder Domain, Token-Vertrag, Blocknummer, RPC-Endpunkt und Beobachtungszeit.
  2. Bestätigen Sie die Adresse im offiziellen Register des Emittenten; Name, Symbol, Icon und Suchtreffer sind keine maßgeblichen Belege.
  3. Prüfen Sie deployten Code und Proxy-Status; notieren Sie Implementierung oder Beacon, Administrator und jüngste Upgrades.
  4. Rufen Sie decimals() auf, dekodieren Sie uint8 per ABI und erfassen Sie Erfolg, Revert, leere oder fehlerhafte Ausgabe, ohne einen Standardwert einzusetzen.
  5. Lesen Sie rohe balanceOf-, totalSupply-, Freigabe-, Calldata-, Receipt- und Eventwerte an kompatiblen Blöcken und formatieren Sie sie mit der beobachteten Skalierung.
  6. Berechnen Sie Transfer, Freigabe, Quote und Bridge-Betrag mit Ganzzahlen neu, einschließlich Gebühren, Rundung, Resten, Rebases oder Transfersteuern.
  7. Simulieren und senden Sie eine kleine Transaktion und gleichen Sie Rohsalden vorher und nachher ab; stoppen Sie bei jeder Abweichung zwischen Oberfläche, RPC, Event oder Saldo.

Beispiele

  • Ein Rohwert, zwei Skalierungen. Bei raw = 123456789 zeigt d = 6 den Wert 123.456789; bei d = 18 ist es 0.000000000123456789. Der Unterschied beträgt den Faktor 10^12.
  • Darstellbarkeit zählt. Bei d = 6 werden 1.25 Token zu 1250000 Roheinheiten. 0.0000001 Token liegt unter einer Roheinheit und muss abgelehnt oder nach einer ausdrücklichen Regel gerundet werden.
  • Falsch skalierte Freigabe. Eine Freigabe von 100 Token bei d = 6 ist 100000000. Mit d = 18 kodiert ergibt sie 100000000000000000000, also eine um 10^12 größere Freigabe.
  • Bridge-Neuskalierung. Konvertiert eine dokumentierte 1:1-Route einen Quelltoken mit d = 6 in eine Zieldarstellung mit d = 18, stehen rohe 2500000 für 2.5 Token und am Ziel 2500000000000000000 für 2.5. Gebühren, Grenzen, Reste und tatsächlicher Empfang sind weiter zu prüfen.

Risiken

  • Die richtige Adresse wird auf der falschen Chain abgefragt.
  • Ein kopierter Name, ein Symbol oder Icon verbirgt einen anderen Vertrag.
  • Proxy-Implementierung oder Beacon ändern sich nach der Prüfung.
  • RPC oder Explorer liefern alten, nicht finalen oder widersprüchlichen Zustand.
  • Fehlende oder fehlerhafte Metadaten werden still durch 18 ersetzt.
  • Binäre Gleitkommaumrechnung rundet einen großen oder präzisen Betrag.
  • Eine Wallet formatiert Transfer korrekt, Freigabe oder permit aber falsch.
  • Eine Datenbank mischt Roheinheiten und menschenlesbare Beträge.
  • Eine Bridge unterstellt gleiche Dezimalstellen oder verschweigt Restrundung.
  • Transfergebühr, Rebase, Mint, Burn, Pause oder Sperre verhindern einfachen Abgleich.
  • Transaktions-Calldata, Events, Receipts und tatsächliche Saldoänderungen weichen ab.
  • Die Dezimalprüfung gilt fälschlich als Beweis für Emittent, Reserven, Liquidität oder Sicherheit.

Häufige Missverständnisse

  • Alle ERC-20-Token haben 18 Dezimalstellen. Das Metadatum ist optional; Implementierungen können andere Werte liefern.
  • Dezimalstellen sind Präzisionsbits der EVM. Sie sind eine dezimale Anzeigekonvention; Token-Arithmetik bleibt ganzzahlig.
  • Der formatierte Explorer-Saldo ist eine unabhängige Bestätigung. Er kann denselben Metadatenaufruf und damit denselben Fehler nutzen.
  • Gleiches Symbol und gleiche Dezimalstellen bedeuten denselben Vermögenswert. Nötig sind auch richtige Chain, exakter Vertrag und Emittentenbeleg.
  • Ein erfolgreicher Kleintransfer validiert jede Integration. Freigaben, Router, Bridges, Börsen und Buchhaltung können separat skalieren.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...