---
title: "Token-Dezimalstellen verifizieren"
description: "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."
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.
# Token-Dezimalstellen verifizieren
> 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
- [Token-Vertrag verifizieren](/crypto/token-contract-verification/)
- [Wallet-Calldata dekodieren](/crypto/calldata-decoding-wallet/)
- [Bridge-Token verifizieren](/crypto/bridge-token-verification/)
- [Risiko bei Token mit Transfergebühr](/crypto/fee-on-transfer-token-risk/)
- [Proxy-Vertrag](/crypto/proxy-contract/)
## Quellen
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (abgerufen: 2026-08-21)
- [ERC-20](https://docs.openzeppelin.com/contracts/5.x/erc20) - OpenZeppelin Docs (abgerufen: 2026-08-21)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - ethereum.org (abgerufen: 2026-08-21)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (abgerufen: 2026-08-21)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (abgerufen: 2026-08-21)
Source: https://wiki.fcontext.com/de/crypto/token-decimals-verification/index.mdx