Was ist ERC-20?
ERC-20 ist ein Schnittstellenstandard für fungible Token auf Ethereum. Er richtet sich an eine Art Onchain-Programm, das Guthaben erfasst und Vorgänge verarbeitet: einen Token-Contract. ERC steht für Ethereum Request for Comments, die Kategorie der Standards und Konventionen der Ethereum-Anwendungsschicht; 20 ist die Nummer dieses Vorschlags. ERC-20 legt fest, wie ein Token-Contract Abfragen zu Guthaben und Gesamtemission beantworten, wie er Übertragungen und Freigaben verarbeiten und welche Vorgangsaufzeichnungen er zum Auslesen durch Anwendungen aussenden soll — seine Ereignisse —, damit Wallets und andere Anwendungen verschiedene Token auf ähnliche Weise anbinden können.
„Fungibel“ heißt, dass gleiche Mengen desselben Tokens in der Buchführung des Contracts gegeneinander austauschbar sind. Eine von einem bestimmten Contract erfasste Einheit wird zum Beispiel nicht automatisch zu einem anderen Typ, nur weil sie von einer anderen Adresse kommt. ERC-20 vereinheitlicht die Art, wie mit diesen Einheiten umgegangen wird — nicht ihren Preis, Zweck oder ihre Vertrauenswürdigkeit.
Eine gemeinsame Schnittstelle löst Unterschiede bei der Anbindung
Würde jeder Token-Contract andere Funktionsnamen und Parameter verwenden, müsste eine Wallet für jedes neu aufgenommene Token einen neuen Satz Abfrage- und Übertragungsmethoden lernen, und Onchain-Anwendungen könnten bestehenden Code kaum wiederverwenden.
ERC-20 legt einen Satz gemeinsamer Schnittstellen fest. Eine Wallet kann Guthaben verschiedener Token mit derselben Abfragemethode lesen, eine Anwendung kann eine Übertragung vereinbarungsgemäß anfordern, und Datendienste können Übertragungs- und Freigabeereignisse in einem einheitlichen Format auslesen.
Der Standard selbst erzeugt kein Token. Entwickelnde müssen weiterhin einen konkreten Contract schreiben oder übernehmen und ihn im Netzwerk bereitstellen. Jeder Contract kann seine eigene Emission, Kontoguthaben und zusätzliche Regeln erfassen; zwei ERC-20-Token können daher unterschiedlichen Code nutzen und völlig unterschiedliche Administrationsrechte halten.
Guthaben, Gesamtmengen und Anzeigeeinheiten
Ein ERC-20-Contract erfasst Tokenmengen als ganze Zahlen. balanceOf dient der Abfrage des Guthabens einer Adresse, totalSupply der Abfrage der vom Contract gemeldeten Gesamtmenge.
Die in einer Oberfläche sichtbaren Dezimalstellen stammen üblicherweise aus einer Anzeigeregel und nicht daraus, dass der Contract tatsächlich einen Bruchteil speichert. Das optionale Feld decimals teilt der Wallet mit, um wie viele Stellen die ganze Zahl nach links zu verschieben ist. Erfasst ein Contract 1.000.000 kleinste Einheiten und beträgt decimals 6, zeigt eine Oberfläche normalerweise 1 Token an.
Das ändert die Onchain-Menge nicht und verändert auch den Wert eines Tokens nicht automatisch. Der ursprüngliche Standard führt das Namensfeld name, das Kürzelfeld symbol und das Anzeigedezimalfeld decimals als optionale Informationen; Namen und Kürzel können sich zudem wiederholen. Ein ERC-20-Token verlässlich zu identifizieren erfordert, Netzwerk und Contract-Adresse gemeinsam zu prüfen, nicht nur ein Symbolbild oder ein Kürzel.
Wie eine direkte Übertragung abläuft
Überträgt die haltende Partei Token aus dem eigenen Guthaben direkt an eine andere Adresse, ruft sie üblicherweise transfer auf und gibt die Empfangsadresse sowie eine in der kleinsten Einheit ausgedrückte Menge an.
Bei der Ausführung prüft der Contract seine eigenen Regeln. Im Grundfall führt ein unzureichendes Guthaben zum Fehlschlag; eine Umsetzung kann außerdem Pausieren, Listen, Übertragungsgebühren oder weitere Beschränkungen ergänzen. Nach Erfolg aktualisiert der Contract seine internen Guthaben und sendet ein Transfer-Ereignis aus, damit Wallets, Block-Explorer und Datendienste diese Änderung erkennen.
Das Transfer-Ereignis ist ein wichtiger Hinweis zum Auslesen von Änderungen, doch das endgültige Guthaben bestimmt weiterhin der Contract-Zustand. Eine Anwendung muss zusätzlich bestätigen, dass die Transaktion erfolgreich im richtigen Netzwerk geschrieben wurde und dass das Ereignis von der richtigen Contract-Adresse stammt.
Freigaben lassen eine Anwendung eine begrenzte Menge für dich übertragen
ERC-20 unterstützt auch den Ablauf „zuerst freigeben, dann von einer anderen Adresse oder einem Contract ausführen lassen“. Er dient häufig dezentralem Handel, Verleih oder anderen Vorgängen, bei denen ein Contract Token empfangen muss.
Daran sind drei Rollen beteiligt:
- die haltende Partei besitzt die Token und entscheidet über die Freigabe;
- die berechtigte Partei kann eine andere Adresse oder eine Onchain-Anwendung sein;
- die empfangende Seite ist die Adresse, auf die die Token letztlich übertragen werden, und kann sich von der berechtigten Partei unterscheiden.
Die haltende Partei ruft approve auf, um einen Freigaberahmen festzulegen. allowance dient der Abfrage des Restbetrags; die berechtigte Partei ruft transferFrom auf und verschiebt Token im Rahmen dessen, was Guthaben und Restrahmen erlauben. Bei erfolgreicher Freigabe sendet der Contract ein Approval-Ereignis aus.
Eine Freigabe bedeutet nicht, dass die Token bereits abgeflossen sind, lässt der berechtigten Partei aber Raum für späteres Handeln. Ist der Rahmen groß oder wird er nicht rechtzeitig widerrufen, kann die berechtigte Anwendung — sobald sie eine Schwachstelle hat, unter fremde Kontrolle gerät oder sich anders verhält als erwartet — Token im freigegebenen Umfang abziehen. Nutzende sollten berechtigte Adresse, Token-Contract und Rahmen prüfen, statt sich auf den auf einer Anwendungsseite angezeigten Namen zu verlassen.
Worauf beim Ändern eines Freigaberahmens zu achten ist
Der ursprüngliche ERC-20-Entwurf erlaubt, approve erneut aufzurufen und den alten Rahmen mit einem neuen Wert zu überschreiben. Ist der alte Rahmen noch nicht genutzt und ändert die haltende Partei ihn unmittelbar auf einen anderen Wert ungleich null, kann die berechtigte Partei den alten Rahmen verbrauchen, bevor die Änderungstransaktion wirksam wird, und danach mit dem neuen Rahmen fortfahren — insgesamt mehr als der neue Rahmen, den die haltende Partei belassen wollte.
Die ERC-20-Spezifikation empfiehlt Client-Oberflächen, den Rahmen derselben berechtigten Partei zuerst auf 0 zu setzen und den neuen Wert erst nach Bestätigung der Nullsetzungs-Transaktion festzulegen. Das ist eine Kompatibilitätsempfehlung zum Ablauf einer Freigabeänderung; sie bedeutet nicht, dass alle Wallets dieselbe Interaktion nutzen, und sie ersetzt nicht die Beurteilung des berechtigten Contracts.
Eine Freigabe zu widerrufen heißt üblicherweise ebenfalls, den Rahmen auf 0 zu setzen und eine Onchain-Transaktion einzureichen. Eine Wallet lediglich von einer Website zu trennen ändert einen bereits im Token-Contract eingetragenen Rahmen normalerweise nicht automatisch.
Die gemeinsame Schnittstelle des Basisstandards
Aus Sicht der Nutzenden lassen sich die Basisschnittstellen in drei Gruppen fassen:
- Abfrage: Gesamtemission, Guthaben einer Adresse und verbleibenden Freigaberahmen lesen;
- Vorgang: direkte Übertragung durch die haltende Partei, Festlegen einer Freigabe oder Übertragung durch die berechtigte Partei;
- Ereignisse: erfolgreiche Übertragungen und Freigaben festhalten, damit externe Anwendungen ihre Daten aktualisieren.
Name, Kürzel und Dezimalstellen zählen zu den optionalen Anzeigeinformationen. Der Standard verlangt außerdem, dass die aufrufende Seite den Fall eines Vorgangs behandeln kann, der false zurückgibt, und nicht annimmt, jeder Aufruf sei entweder erfolgreich oder melde automatisch einen Fehler. In der praktischen Anbindung muss eine Anwendung den schon bereitgestellten unterschiedlichen Umsetzungen begegnen und nicht bloß prüfen, ob ein Funktionsname existiert.
Welche Fähigkeiten nicht zum Basisstandard gehören
ERC-20 legt nicht einheitlich fest, wie ein Token seine Anfangsemission erzeugt, und verlangt von einem Contract nicht, weiter zu prägen oder Vernichtung zu unterstützen. Prägung, Vernichtung, Pausieren, Einfrieren, Listen, Transaktionsgebühren, Stimmrechte, Upgrades und Administrationsrollen können jeweils von einer konkreten Umsetzung zusätzlich eingebaut werden oder gar nicht vorhanden sein.
Der Standard legt ebenfalls nicht fest:
- ob die Tokenemission eine Obergrenze hat und wer die Emission ändern kann;
- ob ein Token Reserven, Waren, Dienstleistungen oder anderen Offchain-Rechten entspricht;
- Preis, Liquidität oder Handelsplätze eines Tokens;
- ob eine Administration den Contract pausieren, einfrieren oder aktualisieren kann;
- ob ein gleichnamiges Token in einem anderen Netzwerk zur selben Emissionsvereinbarung gehört.
totalSupply zu lesen ergibt daher nur die Gesamtmenge, die der Contract aktuell meldet, und sagt allein nichts darüber, ob künftig weiter ausgegeben wird. Dasselbe symbol zu sehen beweist ebenso nicht, dass zwei Contracts dasselbe Token darstellen.
Token-Contracts und natives ETH
ETH ist das native Asset des Ethereum-Netzwerks, dient zur Zahlung der Gas-Gebühr, die das Netzwerk für die Ausführung von Transaktionen erhebt, und wird unmittelbar vom Protokoll erfasst. Ein ERC-20-Token hingegen hat einen Smart Contract, der Guthaben und Vorgangsregeln führt.
Beide lassen sich zwischen Adressen übertragen, doch der Aufrufweg ist nicht derselbe. Eine gewöhnliche ETH-Übertragung erfordert keinen Aufruf eines ERC-20-Contracts, und ETH selbst ist kein ERC-20-Token. Manche Anwendungen nutzen einen Contract, um ETH in einer ERC-20-Form abzubilden, damit es an Programme angebunden werden kann, die nur die ERC-20-Schnittstelle annehmen; dadurch kommt ein weiterer Contract mit eigenen Regeln hinzu, sodass beide Aufzeichnungen nicht unmittelbar als dasselbe Objekt gelten können.
Schnittstellenkompatibilität bedeutet nicht gleiches Verhalten
„ERC-20 unterstützen“ sagt üblicherweise nur, dass eine Wallet oder Anwendung die Basisschnittstellen aufrufen kann. Ein konkretes Token kann sich dennoch anders verhalten:
- bei der Übertragung werden zusätzliche Gebühren abgezogen, sodass der empfangene Betrag unter dem eingegebenen liegt;
- eine Administration kann Übertragungen pausieren, Adressen einfrieren oder die Umsetzung ändern;
- manche älteren Contracts geben Ergebnisse nicht so zurück, wie eine Anwendung es erwartet;
- Anzeigefelder fehlen, sind doppelt vorhanden oder kommen aus einer unzuverlässigen Quelle;
- zusätzliche Logik lässt eine gewöhnliche Übertragung unter bestimmten Bedingungen scheitern.
ERC-20 liefert daher eine gemeinsame Sprache, keine einheitlichen Geschäftsregeln. Um zu beurteilen, ob ein Token sicher angebunden werden kann, sind die konkrete Contract-Adresse, der Code oder die Verifizierungsangaben, die Administrationsrechte und die tatsächlichen Aufrufergebnisse zu prüfen.
Häufig gestellte Fragen
Sind alle Ethereum-Token ERC-20?
Nein. Ethereum hat auch Standards für eigenständig nummerierte Token oder andere Zwecke, und eigene Schnittstellen können ebenfalls existieren. ERC-20 dient vor allem Token, die nach Menge erfasst werden und deren gleiche Einheiten austauschbar sind.
Nutzen alle Token 18 Dezimalstellen?
Nein. decimals ist ein optionales Anzeigefeld, und verschiedene Token können unterschiedliche Werte verwenden. Eine Anwendung sollte die Einstellung des konkreten Contracts lesen und korrekt behandeln, bevor sie Mengen berechnet oder anzeigt.
Widerruft das Trennen der Wallet von einer Website die Freigabe?
Üblicherweise nicht. Das Trennen verhindert, dass die Website über die aktuelle Sitzung weiter Wallet-Vorgänge anfordert, doch der Onchain-Rahmen bleibt im Token-Contract erfasst. Ein Widerruf erfordert meist, diesen Rahmen auf 0 zu ändern und die Transaktion erfolgreich im Netzwerk schreiben zu lassen.
Bedeutet der Erhalt eines ERC-20-Tokens, dass es echt ist?
Nein. Beliebige Parteien können einen Contract mit ähnlichem Namen oder Kürzel bereitstellen. Netzwerk, Contract-Adresse und verlässliche Informationsquellen sind zu prüfen; Standardkompatibilität beweist weder Identität der emittierenden Partei noch Reserven oder Wert.
Können andere Blockchains diesen Standard direkt nutzen?
ERC-20 ist ein Standard der Ethereum-Anwendungsschicht. Andere Netzwerke, die Smart Contracts im Ethereum-Stil ausführen können, übernehmen möglicherweise eine ähnliche Schnittstelle, doch Contract-Adressen und Zustand sind in jedem Netzwerk voneinander unabhängig. Eine Bewegung zwischen Chains umfasst in der Regel zusätzlich eine Bridge oder eine eigene Emissionsvereinbarung, die die ERC-20-Schnittstelle nicht automatisch leistet.
Verwandte Begriffe
Lies weiter über Token-Standard, Krypto-Token, Smart Contract und Gas-Gebühr, oder kehre zum Krypto-Glossar zurück.
Quellen
- ERC-20: Token Standard — grundlegende Anforderungen an Abfrage, Übertragung, Freigabe, Rückgabewerte und Ereignisse.
- Ethereum.org: Einführung zu ERC-20 — Zweck des Standards, verbreitete Funktionen und die Anbindung durch Wallets und Anwendungen.
- EIP-1: Zweck und Kategorien der Ethereum Improvement Proposals — Bedeutung von EIP und ERC, Geltungsbereich und Standardprozess.
© 2025 OKX. Dieser Artikel darf in seiner Gesamtheit vervielfältigt oder verbreitet oder es dürfen Auszüge von 100 Wörtern oder weniger dieses Artikels verwendet werden, sofern eine solche Nutzung nicht kommerziell erfolgt. Bei jeder Vervielfältigung oder Verbreitung des gesamten Artikels muss auch deutlich angegeben werden: „Dieser Artikel ist © 2025 OKX und wird mit Genehmigung verwendet.“ Erlaubte Auszüge müssen den Namen des Artikels zitieren und eine Quellenangabe enthalten, z. B. „Artikelname, [Name des Autors, falls zutreffend], © 2025 OKX.“ Einige Inhalte können durch künstliche Intelligenz (KI) generiert oder unterstützt worden sein. Es sind keine abgeleiteten Werke oder andere Verwendungen dieses Artikels erlaubt.




