Token-Standards erklärt: ERC-20, ERC-721, ERC-1155 und mehr
Token-Standards für Entwickler erklärt: Was ERC-20, ERC-721, ERC-1155, TRC-20 und SPL definieren, wie Dezimalstellen funktionieren und was Sie vor der Integration prüfen sollten.

Ein Token-Standard ist eine veröffentlichte Spezifikation, die einem Token-Vertrag vorgibt, welche Funktionen er bereitstellen und welche Ereignisse er auslösen muss. Wallets, Börsen und Anwendungen können dann jeden konformen Token verarbeiten, ohne für jeden einzelnen benutzerdefinierten Code zu schreiben. Dieser Leitfaden behandelt die Standards, denen Sie am häufigsten begegnen werden (ERC-20, ERC-721, ERC-1155 und ihre Entsprechungen auf Tron und Solana). Er behandelt auch, wie ERC-20-Dezimalstellen funktionieren und was Sie prüfen sollten, bevor Sie einen Token in einen Zahlungsablauf integrieren.
TL;DR
- Ein Token-Standard definiert eine Schnittstelle (Funktionen und Ereignisse) sowie Verhaltensregeln, damit Software auf einheitliche Weise mit jedem konformen Token interagieren kann.
- ERC-20 ist für fungible Token, ERC-721 für einzigartige NFTs und ERC-1155 für viele Token-Typen in einem Vertrag.
- TRC-20 spiegelt ERC-20 auf Tron wider, und Solana verwendet sein eigenes SPL-Token-Programm, daher bedeutet „gleicher Standard“ niemals „gleiche Kette“.
- On-Chain-Beträge sind Ganzzahlen. Der optionale
decimals-Wert gibt an, wo das Dezimalzeichen für die Anzeige gesetzt werden muss. - Konformität ist nicht garantiert. Testen Sie das tatsächliche Verhalten jedes Tokens, bevor Sie sich darauf verlassen.
Inhaltsverzeichnis
- Was ein Token-Standard tatsächlich definiert
- ERC-20: der fungible Token-Standard
- ERC-20-Dezimalstellen: korrekte Behandlung von Beträgen
- ERC-721: nicht-fungible Token
- ERC-1155: viele Token-Typen in einem Vertrag
- Vergleich der drei Ethereum-Standards
- Token-Standards auf anderen Ketten
- Was Sie vor der Integration eines Tokens prüfen sollten
- Perspektive: Warum Standards nur die halbe Arbeit sind
- Standards mit Chaingateway in die Praxis umsetzen
- FAQ
- Quellen
Was ein Token-Standard tatsächlich definiert
Ein Token ist keine native Coin. Es ist ein Datensatz, der in einem Smart Contract geführt wird: wer wie viel hält und welche Regeln das Verschieben regeln. Ohne eine gemeinsame Spezifikation würde jeder Token seine eigenen Funktionsnamen bereitstellen, und jede Wallet bräuchte maßgeschneiderten Code, um Guthaben auszulesen oder Transfers zu senden.
Ein Standard behebt das. Laut der Token-Standards-Seite von ethereum.org definieren Standards, wie Token sich verhalten und interagieren, was Smart Contracts komponierbar hält und neuen Token ermöglicht, mit bestehenden dezentralen Börsen und Anwendungen zu funktionieren. Die Übersicht von NIST zum Token-Design beschreibt ERCs als Bereitstellung von Funktions- und Ereignisdeklarationen, Einschränkungen und Anforderungen sowie manchmal Referenzimplementierungen.
In der Praxis gibt Ihnen ein Standard vier Dinge:
- Aufrufbare Funktionen, wie das Auslesen eines Guthabens oder das Verschieben von Token.
- Ereignisse, die der Vertrag auslöst, damit externe Software Aktivitäten nachverfolgen kann.
- Datentypen und Einschränkungen, wie z. B. die Darstellung von Beträgen.
- Verhaltensanforderungen, wie z. B. welche Aufrufe welches Ereignis auslösen müssen.
Auf Ethereum werden diese Spezifikationen als ERCs vorgeschlagen, die Kategorie auf Anwendungsebene der Ethereum Improvement Proposals. Andere Chains haben ihre eigenen Prozesse und Namen, aber die Idee lässt sich übertragen.
ERC-20: der Fungible-Token-Standard
ERC-20 wurde 2015 erstellt und definiert eine standardisierte API für Tokens innerhalb von Smart Contracts, damit Wallets und dezentrale Börsen diese wiederverwenden können. „Fungibel“ bedeutet, dass jede Einheit mit jeder anderen austauschbar ist, wie Dollar oder Kilogramm Gold. Stablecoins, Governance-Tokens und die meisten Zahlungstokens folgen diesem Standard.
Die Schnittstelle, wie in der ERC-20-Dokumentation aufgeführt, umfasst:
| Funktion oder Ereignis | Was sie tut |
|---|---|
totalSupply | Gibt die Gesamtzahl der existierenden Tokens zurück |
balanceOf | Gibt den Kontostand einer Adresse zurück |
transfer | Verschiebt Tokens vom Aufrufer an eine andere Adresse |
approve | Ermöglicht einer anderen Adresse (einem Spender), bis zu einem festgelegten Betrag Ihrer Tokens zu bewegen |
allowance | Gibt zurück, wie viel ein Spender noch im Namen eines Eigentümers bewegen darf |
transferFrom | Verschiebt Tokens im Namen eines Eigentümers, wobei eine Genehmigung verwendet wird |
name, symbol, decimals | Beschreibende Metadaten, häufig vorhanden |
Transfer, Approval Ereignisse | Werden bei Transfers und Genehmigungen ausgelöst |
Die Spezifikation besagt, dass Transfers das Transfer-Ereignis auslösen müssen und erfolgreiche approve-Aufrufe Approval auslösen müssen. Diese Regel macht die Zahlungserkennung möglich: Sie können auf Ereignisse lauschen, anstatt jede Adresse abzufragen. Wir gehen in unserem Leitfaden zum ERC-20 Transfer-Ereignis näher darauf ein, und unser ERC-20 Standard-Überblick führt durch die vollständige Schnittstelle.
Das approve- und transferFrom-Muster
Das Zweischritt-Muster verwirrt Einsteiger. Mit transfer sendet der Token-Inhaber Tokens direkt. Mit approve plus transferFrom autorisiert der Inhaber zuerst einen Spender, und der Spender zieht die Tokens später ein. So nimmt eine dezentrale Börse oder ein Abonnement-Vertrag Zahlungen entgegen, ohne Ihre Schlüssel zu halten. Wenn Sie nur Tokens aus einer Wallet senden müssen, die Sie kontrollieren, reicht transfer völlig aus. Unsere Anleitung zum Senden von ERC-20-Tokens vergleicht die Wallet-, Code- und API-Methoden.
ERC-20 Dezimalstellen: korrekte Behandlung von Beträgen
Smart Contracts speichern keine Brüche. Jeder Kontostand ist eine Ganzzahl, und decimals gibt an, wie viele der rechtesten Ziffern den Bruchteil darstellen. Die ERC-20-Spezifikation macht die Methode optional und gibt ein Beispiel: mit 8 Dezimalstellen teilen Sie den Token-Betrag durch 100000000, um seine Benutzerdarstellung zu erhalten.
Das hat drei praktische Konsequenzen.
Lesen Sie Dezimalstellen immer vom Vertrag aus. Hardcodieren Sie keinen Wert für alle Tokens. Zwei Tokens, die beide als „1,00“ angezeigt werden, können als sehr unterschiedliche Ganzzahlen gespeichert sein.
Führen Sie die Berechnung mit Ganzzahlen oder Big-Number-Typen durch. Rohbeträge können das übersteigen, was eine Standard-Gleitkommazahl exakt hält. Verwenden Sie BigInt, BigNumber oder den Dezimaltyp Ihrer Sprache, und formatieren Sie erst im letzten Schritt für die Anzeige.
Behandeln Sie eine fehlende decimals-Methode als einen zu handhabenden Fall. Da die Methode optional ist, macht ein konformer Token sie möglicherweise nicht verfügbar. Entscheiden Sie sich für einen Fallback, wie die Ablehnung des Tokens oder die Erfordernis einer manuellen Konfiguration, anstatt stillschweigend einen Standardwert anzunehmen.
Ein durchgerechnetes Beispiel: Ein Token mit 6 Dezimalstellen zeigt einen Rohsaldo von 2500000. Die Division durch 10^6 ergibt 2,5 Token. Um 0,75 Token zu senden, übermitteln Sie 750000, nicht 0,75. Würde man versehentlich den Anzeigewert übermitteln, würde man einen verschwindend geringen Betrag senden, und die Transaktion würde dennoch erfolgreich sein.

ERC-721: nicht-fungible Token
Während ERC-20 jede Einheit gleich behandelt, ist ERC-721 eine Schnittstelle für nicht-fungible Token, wie einzigartige Kunstwerke oder Songs. Jedes Token hat eine eindeutige Kennung innerhalb seines Vertrags, sodass das Eigentum pro Token und nicht als Saldo verfolgt wird. Typische Anwendungsfälle sind Sammlerstücke, Tickets, In-Game-Items und Eigentumsnachweise.
Der Kompromiss liegt in Kosten und Komplexität. Das Verschieben von zehn unabhängigen NFTs bedeutet zehn separate Transfers. Für Details zur Schnittstelle sehen Sie sich unseren ERC-721 Standard Guide an.
ERC-1155: viele Token-Typen in einem Vertrag
ERC-1155 ist eine Multi-Token-Schnittstelle. Ein bereitgestellter Vertrag kann eine beliebige Anzahl fungibler, nicht-fungibler oder semi-fungibler Token-Typen repräsentieren, die jeweils durch eine Token-ID identifiziert werden, die ihre eigenen Metadaten und ihr eigenes Angebot haben kann. Die Spezifikation unterstützt auch das Übertragen mehrerer Token-Typen in einem Vorgang.
Das macht es zur natürlichen Wahl für Spiele, bei denen ein einzelner Vertrag eine Währung, einen Satz Verbrauchsgegenstände und einige einzigartige Items enthalten könnte. Sie deployen einmal und können Bewegungen bündeln, anstatt für jeden Asset-Typ eine Transaktion zu senden.
Vergleich der drei Ethereum-Standards
| ERC-20 | ERC-721 | ERC-1155 | |
|---|---|---|---|
| Token-Typ | Fungibel | Nicht-fungibel | Fungibel, nicht-fungibel oder semi-fungibel |
| Verfolgt | Einen Saldo pro Adresse | Einen Besitzer pro Token-ID | Salden pro Adresse pro Token-ID |
| Benötigte Verträge | Einer pro Token | Einer pro Sammlung | Einer für viele Token-Typen |
| Batch-Transfers | Nicht Teil des Standards | Nicht Teil des Standards | Integriert |
| Typische Verwendung | Stablecoins, Zahlungs- und Governance-Token | Sammlerstücke, Tickets, einzigartige Assets | Spiele, gemischte Asset-Kataloge |
Token-Standards auf anderen Chains
Die Namen ändern sich von Chain zu Chain, aber die Idee bleibt dieselbe.
Tron: TRC-20 und TRC-10. TRC-20 ist der fungible Token-Standard auf TRON und auf Schnittstellenebene mit ERC-20 kompatibel, sodass die meisten Ethereum-Token-Verträge nur wenige Änderungen benötigen, um dort zu laufen. Tron hat außerdem den älteren, protokollbasierten TRC-10. Wir erklären die praktischen Unterschiede in TRC-10 vs TRC-20.
BNB Chain: BEP-20. BEP-20 folgt dem ERC-20-Modell auf einer EVM-kompatiblen Chain, sodass die Funktionsnamen und Event-Strukturen vertraut aussehen werden.
Solana: SPL-Token. Solana stellt für jeden Token keinen neuen Vertrag bereit. Token werden über das gemeinsame SPL-Token-Programm erstellt, und ein NFT dort ist einfach ein Token, das mit null Dezimalstellen erstellt wurde. Das mentale Modell unterscheidet sich von Ethereum, obwohl das Ziel der Interoperabilität dasselbe ist.
Cosmos-Ökosystem: CW20. Die CW20-Spezifikation verwaltet Salden und Transfers mithilfe von Uint128-Ganzzahlen und überlässt die Dezimalstellen-Verarbeitung der Benutzeroberfläche, was dieselbe Trennung zwischen Ganzzahl und Anzeige wie bei ERC-20 ist.
Ein gleichnamiger Standard auf einer anderen Kette ist niemals austauschbar mit dem Original. Ein TRC-20 USDT und ein ERC-20 USDT sind unterschiedliche Assets in unterschiedlichen Netzwerken, und das Senden an das falsche Netzwerk kann zum Verlust von Geldern führen. Verknüpfen Sie eine Adresse in Ihrem Datenmodell immer mit ihrem Netzwerk.

Was Sie vor der Integration eines Tokens prüfen sollten
Ein Standard beschreibt, was ein Token tun sollte, nicht, was jeder bereitgestellte Vertrag tut. Eine Studie aus dem Jahr 2022 in IET Software berichtete, dass Mehrdeutigkeiten in der ERC-20-Schnittstelle zu unterschiedlichen Interpretationen und Compliance-Schwachstellen bei realen Token-Verträgen führen können.
Die Token-Integrations-Checkliste auf ethereum.org ist eine gute Basis. Sie fordert Entwickler auf, Folgendes zu prüfen:
- Konformität und Rückgabewerte der Standardfunktionen,
- optionale Funktionen und Dezimalstellen,
- Race-Condition-Minderung bei Approvals,
- externe Aufrufe innerhalb des Tokens,
- Gebühren oder Zinsen, die bei Transfers erhoben werden,
- Upgradefähigkeit, Minting, Pausieren und Blacklisting-Befugnisse,
- Eigentümer- und Team-Risiken sowie Angebots-Konzentration.
Für ein Zahlungsprodukt sind die am häufigsten auftretenden Probleme das Fee-on-Transfer-Verhalten (der empfangene Betrag ist geringer als der gesendete Betrag), Blacklisting (ein Transfer kann nachträglich blockiert) und nicht standardmäßige Rückgabewerte. Testen Sie jeden Token, den Sie unterstützen möchten, in einem Testnetz mit echten Transfers, und schreiben Sie Einzahlungen basierend auf dem tatsächlich empfangenen Betrag gut, nicht auf dem angeforderten Betrag.
Perspektive: Warum Standards nur die halbe Arbeit sind
Standards lösen das Problem, wie ein Token mit einer Kette kommuniziert. Sie lösen nicht das Problem, ein Produkt über mehrere Ketten hinweg zu betreiben. Wenn Sie Zahlungen auf Ethereum, Tron und Solana akzeptieren, stehen Sie immer noch vor unterschiedlichen Adressformaten, unterschiedlichen Gebührenmodellen, unterschiedlichen Ereignisstrukturen und unterschiedlicher Knoten-Infrastruktur.
Wir haben Chaingateway genau für diese Lücke entwickelt. Unsere Ansicht ist, dass Entwickler keine chain-spezifischen Endpunkte warten oder eigene Knoten betreiben müssen, nur um zu erfahren, dass ein Kunde gezahlt hat. Deshalb liefern wir vordekodierte Daten, sodass ein Transfer als lesbare Felder ankommt, anstatt als rohe Log-Themen, und wir schätzen Gas automatisch. Wir signieren Webhook-Anfragen mit HMAC, damit Ihr Backend überprüfen kann, ob eine Zahlungsbenachrichtigung echt ist.
Unser Rat für Teams, die gerade anfangen: Wählen Sie den Standard, der zu Ihrem Asset passt (fungibel, einzigartig oder gemischt), lesen Sie die Dezimalstellen jedes Mal aus dem Vertrag aus, und bauen Sie Ihre Zahlungserkennung auf Ereignissen statt auf Polling auf. Alles andere ist Klempnerarbeit, und Klempnerarbeit ist das, was eine API absorbieren sollte.
— Bitblade
Standards mit Chaingateway in die Praxis umsetzen
Wenn Sie Zahlungen oder Wallets auf Basis dieser Standards entwickeln, bietet Ihnen unsere Blockchain API eine einzige REST-Schnittstelle, um Wallets zu erstellen, Token- und NFT-Transfers zu senden, dekodierte Transaktionsdaten abzurufen und Gebühren über Ethereum, Bitcoin, Tron, Solana, Polygon, BNB Chain und Arbitrum zu schätzen. Sie unterstützt die wichtigsten Token-Standards, einschließlich ERC-20, BEP-20, TRC-20 und ERC-721. Chaingateway Webhooks senden Echtzeit-Benachrichtigungen, wenn eine Zahlung eingeht, sodass Sie nicht pollen müssen.

Die Pläne beginnen bei 49 € pro Monat für Plus, Pro bei 99 €, Premium bei 249 € und Enterprise bei 499 € pro Monat. Bei jährlicher Abrechnung betragen die Kosten 490 €, 990 €, 2.490 € und 4.990 € entsprechend. Details zu den enthaltenen Leistungen finden Sie auf der Preisseite. Speziell für Ethereum zeigt unsere Ethereum API, wie Sie ERC-20-Token über REST ohne web3.js senden können.
Quellen
- Token Standards, ethereum.org
- Ethereum Development Standards, ethereum.org
- ERC-20 Token Standard, ethereum.org
- ERC-20: Token Standard, EIP-20
- ERC-1155: Multi Token Standard, EIP-1155
- Token integration checklist, ethereum.org
- Blockchain Networks: Token Design and Management Overview, NIST
- Conformance evaluation of the top-100 Ethereum token smart contracts, IET Software
- TRC-20 fungible token standard, TRON developer docs
- Token, Solana SPL documentation
- CW20 specification, CosmWasm
Empfohlen
Häufig gestellte Fragen
Ein Coin wie ETH ist nativ für seine Blockchain und bezahlt die Transaktionsgebühren. Ein Token wird durch einen Smart Contract erstellt, der einem Standard folgt, und existiert auf dieser Kette. Sie benötigen weiterhin den nativen Coin, um Gas für das Verschieben von Tokens zu bezahlen, was in unserer Ethereum-Übersicht behandelt wird.
Nein. Die ERC-20-Spezifikation kennzeichnet sie als optional. Die meisten Tokens implementieren sie, aber Ihr Code sollte den Fall behandeln, dass sie fehlt, anstatt einen Standardwert anzunehmen.
Beide Ketten verwenden dasselbe Adressformat, sodass dieselbe Adresse auf beiden existieren kann, die Guthaben jedoch getrennt sind. Gelder, die im falschen Netzwerk gesendet werden, erscheinen nicht im anderen. Unser ERC-20-Adressen-Leitfaden erklärt das Format und wie man Guthaben ausliest.
Verwenden Sie ERC-20 (oder das entsprechende TRC-20- oder BEP-20-Äquivalent) für austauschbare Einheiten wie einen Zahlungs- oder Utility-Token. Verwenden Sie ERC-721, wenn jedes Element einzigartig sein muss, und ERC-1155, wenn ein Vertrag mehrere Arten von Assets verwalten muss. Wählen Sie zuerst die Kette, da das Tooling und die Gebühren jeder Kette die Wahl beeinflussen.
Möchten Sie das selbst umsetzen? API-Key erhalten — 7 Tage kostenlos testen, keine Karte nötig — oder werfen Sie einen Blick auf Blockchain-API für die vollständige Endpoint-Referenz.