Was ist ein Token-Standard?

Ein Token-Standard ist eine technische Spezifikation, die festlegt, welche Funktionen ein Token-Programm bereitstellen soll, welche Eingaben es annimmt und wie es Ergebnisse an Wallets und andere Anwendungen meldet. Dadurch können Token, die verschiedene Entwickelnde erstellen, über ein gemeinsames Regelwerk erkannt und aufgerufen werden.

Ein Standard lässt sich als Schnittstellenvereinbarung verstehen: Er regelt „wie nach außen kommuniziert wird“, entscheidet aber für kein Projekt über Emission, Zweck, Administrationsrechte oder Offchain-Rechte. Zwei Token können demselben Standard folgen und dennoch unterschiedlichen Code nutzen, unterschiedliche Rechte halten und völlig verschiedene Dinge darstellen.

Was ohne gemeinsamen Standard geschähe

Würde jedes Token seine Funktionen für Guthabenabfrage, Übertragung und Freigabe eigenständig benennen, müssten Wallets und Anwendungen für jedes einzelne eine separate Anbindung schreiben. Ein neues Token könnte sich zwar normal übertragen lassen, würde aber vielleicht in bestehenden Wallets nicht angezeigt oder wäre für andere Onchain-Programme nicht aufrufbar.

Ein gemeinsamer Standard legt einheitliche Einstiegspunkte für übliche Vorgänge fest. Eine Wallet weiß, wie sie ein Guthaben abfragt, eine Anwendung weiß, wie sie eine Übertragung anfordert, ein Block-Explorer weiß, welche Ereignisse zu lesen sind, und andere Programme können mehrere Token im gleichen Format aufrufen. Entwickelnde müssen nicht jedes einzelne Token vorab kennen, um eine Basisunterstützung anzubieten.

Ein Standard verbessert die Softwarekompatibilität, nicht die Qualität eines Tokens. Sind die Schnittstellen einheitlich, lässt sich auch eine fehlerhafte oder bösartige Umsetzung leichter an bestehende Anwendungen anbinden; wer sie nutzt, muss Code und Rechte im Einzelfall weiterhin prüfen.

Was ein Standard üblicherweise festlegt

Der Umfang eines Token-Standards hängt von Netzwerk und Token-Art ab. Verbreitete Inhalte lassen sich in folgende Gruppen fassen.

Abfragefunktionen

Ein Standard kann festlegen, wie das Guthaben einer Adresse, die Gesamtemission eines Tokens oder die aktuell kontrollierende Partei einer eigenständigen Nummer abgefragt wird. Eine einheitliche Abfrageweise erlaubt Wallets und Anwendungen die Anzeige grundlegender Informationen.

Abfrageergebnisse spiegeln nur die Daten, die das Programm gerade zurückgibt. Ein Standard prüft nicht, ob ein Anzeigename echt ist oder ob eine Emission Offchain-Deckung hat, und er garantiert nicht, dass die ergänzenden Angaben zu einem Token — seine Metadaten — unter ihrem Link dauerhaft erreichbar bleiben.

Übertragungsfunktionen

Ein Standard kann festlegen, wie eine sendende Partei Token an eine empfangende überträgt, welche Parameter der Aufruf erfordert und wie bei Erfolg oder Fehlschlag zu antworten ist. Bei Token mit eigenständiger Nummer muss eine Übertragung zusätzlich die konkrete Nummer angeben.

Manche Standards bieten eine sicherere Übertragungsweise, die prüft, ob ein empfangendes Programm mit den erhaltenen Token umgehen kann. Das kann bestimmte Fehlübertragungen verringern, verhindert aber keine Verluste durch eine falsche Adresse, eine bösartige Freigabe oder einen Programmfehler.

Freigabefunktionen

Eine Freigabe erlaubt Haltenden, eine andere Adresse oder ein anderes Programm in festgelegten Grenzen für sich handeln zu lassen. Haltende können etwa eine Anwendung ermächtigen, eine bestimmte Menge fungibler Token zu übertragen, oder eine operierende Partei beauftragen, eine Gruppe eigenständig nummerierter Token zu verwalten.

Ein Standard legt fest, wie eine Freigabe erzeugt, abgefragt und widerrufen wird, entscheidet aber nicht, ob Nutzende eine erteilen sollten. Höhe des Rahmens, Dauer und Verhalten des berechtigten Programms sind weiterhin anhand der konkreten Umsetzung und durch die nutzende Person zu beurteilen.

Ereignisse und Aufzeichnungsformate

Führt ein Onchain-Programm eine Übertragung, Prägung oder Freigabe aus, kann es strukturierte Ereignisse aussenden. Ein Ereignis ist ein Hinweis auf eine Ausführungsaufzeichnung zum Auslesen durch Anwendungen; Wallets, Block-Explorer und Datendienste können damit Oberflächen aktualisieren oder einen Index aufbauen.

Ein Ereignis ersetzt den endgültigen Zustand nicht. Eine Anwendung muss weiterhin bestätigen, ob die Transaktion erfolgreich war, und die aktuellen Daten nach den Netzwerkregeln lesen; ein einzelnes unbestätigtes Ereignis oder eines aus dem falschen Contract genügt nicht als Beweis, dass sich ein Guthaben wirksam geändert hat.

Optionale Funktionen und Erweiterungen

Ein Standard kann Name, Kürzel, Metadaten oder eine Funktion, die alle eigenständigen Nummern auflistet — die Aufzählung —, als optional führen und ebenso erlauben, Übertragungsgebühren, Einfrieren, Pausieren oder andere Erweiterungen zu aktivieren. Eine Anwendung darf nicht annehmen, dass alle optionalen Funktionen vorhanden sind, nur weil ein Token angibt, einem Standard zu folgen.

Erweiterungen können zudem untereinander unvereinbar sein oder eine bewusste Anpassung der Wallets erfordern. Gleiche Basisübertragungen bedeuten nicht, dass eine ältere Anwendung alle später ergänzten Rechte und Datenfelder versteht.

Standard, Umsetzung und Token sind nicht dasselbe

Ein Standard ist eine Funktionsvereinbarung und beschreibt, wie ein kompatibles Programm nach außen antworten soll. Eine Umsetzung ist der konkrete Code, den Entwickelnde nach dieser Vereinbarung schreiben und bereitstellen. Ein Token sind die Onchain-Aufzeichnung und Einheiten, die eine bestimmte Umsetzung verwaltet.

Ein Standard kann viele Code-Umsetzungen haben; dieselbe Umsetzung kann auch zur Erzeugung mehrerer verschiedener Token dienen. Eine Umsetzung kann über die Anforderungen des Standards hinaus Gebühren, Einfrieren, Listen, Upgrades oder andere Logik ergänzen.

„Einen Standard übernehmen“ zeigt daher nur die Absicht, eine Reihe von Schnittstellen zu unterstützen. Es beweist nicht, dass der Code fehlerfrei ist, und zeigt nicht, dass alle Schnittstellen korrekt umgesetzt wurden. Beim Einbinden muss eine Anwendung die bereitgestellte Adresse, die tatsächlich zurückgegebenen Ergebnisse, zusätzliche Rechte und Ausnahmeverhalten prüfen.

Wie ein Standard entsteht und übernommen wird

Ein Token-Standard erscheint üblicherweise zuerst als technischer Vorschlag, Spezifikationsdokument oder gemeinsames Programm. Die Verfassenden legen das zu lösende Problem, die Schnittstellenanforderungen und die Entwurfsgründe dar; nach der Diskussion durch Community und Entwickelnde kann der Vorschlag einen relativ stabilen Zustand erreichen, sich weiter ändern oder nicht weiterverfolgt werden.

Dokumentstatus und Marktverbreitung sind zwei verschiedene Dinge. Ein Vorschlag kann vollständig ausgearbeitet und doch kaum genutzt sein; ein anderer Standard kann schon vor der Fertigstellung zahlreiche Umsetzungen haben. Ob Wallets und Anwendungen ihn unterstützen, hängt von tatsächlichen Bereitstellungen, Nutzungsbedarf und den Entscheidungen Entwickelnder ab — nicht von der Nummer selbst.

Ein aktualisierter Standard verändert zudem nicht zwangsläufig bereits bereitgestellte Token. Ein älterer Contract kann mit der alten Schnittstelle weiterlaufen, während neue Funktionen über einen neuen Contract, eine neue Version oder eine optionale Erweiterung kommen. Beim Lesen eines Standards sind Netzwerk, Version, Status und konkrete Umsetzung gleichzeitig zu klären.

Die gemeinsame Schnittstelle fungibler Token

Fungible Token werden nach Menge erfasst, und gleiche Einheiten lassen sich in der Regel gegeneinander tauschen. Standards dieser Art legen häufig Guthabenabfrage, Gesamtemission, Übertragung sowie eine Freigabefunktion fest, mit der eine andere Adresse im Rahmen eines festgelegten Betrags für die haltende Partei übertragen darf.

Auf Ethereum heißen Standardvorschläge der Anwendungsschicht zum Beispiel Ethereum Request for Comments (ERC). ERC-20 ist der ERC-Standard, der die grundlegenden Schnittstellen fungibler Token festlegt, sodass Wallets und Onchain-Anwendungen Guthaben abfragen, Übertragungen anfordern und Freigaben auf gemeinsame Weise behandeln können.

ERC-20 verlangt von einem Token keine feste Emission und verbietet Entwickelnden nicht, zusätzliche Logik wie Pausieren, Übertragungsgebühren oder Listen zu ergänzen. Anzeigeinformationen wie Name, Kürzel und Dezimalstellen können die Contract-Adresse zur eindeutigen Identifikation eines Tokens ebenfalls nicht ersetzen.

Die gemeinsame Schnittstelle eigenständig nummerierter Token

Nicht fungible Token (non-fungible token, NFT) erfordern, jede Nummer gesondert zu verfolgen. Die zugehörigen Standards legen üblicherweise fest, wie die haltende Partei einer Nummer abgefragt, eine bestimmte Nummer übertragen und eine andere Adresse zum Umgang mit einem einzelnen Token oder einer Gruppe ermächtigt wird.

Diese Schnittstellen werden in verschiedenen Netzwerken unterschiedlich umgesetzt. Auf Ethereum legt zum Beispiel ERC-721 grundlegende Vorgänge für Haltung, Übertragung und Freigabe eigenständig nummerierter Token fest, während Metadaten und eine vollständige Nummernliste zu optionalen Erweiterungen gehören. Diesen Standard zu übernehmen bedeutet nicht, dass ein Bild oder anderer Inhalt zwangsläufig onchain gespeichert ist, und belegt nicht, dass das vom Token dargestellte Offchain-Objekt tatsächlich existiert.

Manche Standards erlauben einem Programm auch, fungible Einheiten, eigenständig nummerierte Einheiten oder mehrere Exemplare unter derselben Nummer gemeinsam zu verwalten. Sie dienen unterschiedlichen Aufzeichnungsbedürfnissen; das heißt nicht, dass ein Standard einem anderen allgemein überlegen wäre.

Wie verschiedene Netzwerke standardisieren

Ein Token-Standard muss nicht bedeuten: „für jedes Token einen Contract bereitstellen, der dieselbe Schnittstelle umsetzt“. Verschiedene Blockchains können Kompatibilität über Protokollregeln, ein gemeinsames Programm oder optionale Erweiterungen erreichen.

So stellt das Token-Programm von Solana Anweisungen für Prägung, Kontoaufzeichnungen, Übertragung und Freigabe an einer Stelle bereit. Jedes Mint erfasst Emission und Rechte eines bestimmten Tokens, während Wallets und Anwendungen viele Mints über dasselbe Token-Programm behandeln.

Solana bietet außerdem Token Extensions, ein Token-Programm, dem zusätzliche Funktionen hinzugefügt werden können. Beim Erzeugen eines Tokens können Entwickelnde Erweiterungen nach Bedarf wählen; einige lassen sich nach der Initialisierung nicht mehr hinzufügen, und einige können untereinander unvereinbar sein. Das zeigt: „dasselbe Token-Programm nutzen“ genügt noch nicht für den Schluss, dass sich zwei Token gleich verhalten.

Erscheinen derselbe Standardname oder eine ähnliche Schnittstelle netzwerkübergreifend, ist ebenfalls nicht anzunehmen, dass Adressen, Rechte und Transaktionsformate unmittelbar übertragbar sind. Der Anwendungsbereich eines Standards bleibt stets an das konkrete Netzwerk und die Ausführungsumgebung gebunden.

Kompatibel heißt nicht gleiches Verhalten

Wenn eine Wallet oder Anwendung angibt, „einen Standard zu unterstützen“, heißt das meist, dass sie die vom Standard verlangten Basisschnittstellen verarbeiten kann. Die tatsächliche Kompatibilität kann weiterhin durch Folgendes beeinflusst werden:

• das Token setzt die erforderlichen Funktionen nicht vollständig um oder antwortet anders als erwartet;
• das Token ergänzt Übertragungsgebühren, Pausieren, Einfrieren oder Listenregeln;
• die Anwendung unterstützt bestimmte optionale Erweiterungen nicht;
• das empfangende Programm kann eine bestimmte Übertragungsweise nicht verarbeiten;
• eine Proxy-Upgrade-Struktur, die den ausgeführten Code hinter einem festen Einstiegspunkt austauscht, hat die tatsächliche Logik geändert;
• gleichnamige Token sind in verschiedenen Netzwerken oder unter verschiedenen Adressen bereitgestellt.

Tests der Schnittstellenkompatibilität müssen sich daher am konkreten Code und an den konkreten Ergebnissen eines Aufrufs orientieren. Ein Label „standardkonform“ ist selbst kein Sicherheitsaudit und keine Zusicherung, dass sich das künftige Verhalten nicht ändert.

Was ein Standard nicht festlegt

Ein Token-Standard ersetzt üblicherweise nicht folgende Informationen:

• wer weiter prägen, einfrieren, pausieren oder das Token aktualisieren kann;
• wie die Gesamtmenge verteilt ist und ob sich das ändern wird;
• welchen praktischen Zweck oder welche Marktnachfrage das Token hat;
• ob Name, Symbol und Metadaten von einer verlässlichen Quelle gepflegt werden;
• ob die Reserven, physischen Güter oder Dienstleistungen, denen das Token zu entsprechen behauptet, existieren;
• ob Haltende Einlöse-, Governance- oder andere Offchain-Rechte besitzen.

Diese Fragen erfordern die Prüfung der konkreten Umsetzung, der Rechte und der Offchain-Vereinbarungen. Ein technischer Standard löst nur einen Teil der Fragen zur Softwareinteraktion; den Nachweis von Echtheit, Wert oder Rechtswirkung kann er nicht tragen.

Häufig gestellte Fragen

Muss ein Token einem Standard folgen?

Nicht zwangsläufig. Entwickelnde können eine eigene Schnittstelle erstellen, doch Wallets und Anwendungen brauchen dann zusätzliche Anpassung. Einen breit unterstützten Standard zu übernehmen erleichtert üblicherweise die Basiskompatibilität.

Ist eine höhere Standardnummer besser?

So lässt sich das nicht beurteilen. Ein neuerer Standard kann Funktionen ergänzen, aber auch weniger Unterstützung haben, sich noch ändern oder für einen Zweck unpassend sein. Zu prüfen sind Status des Vorschlags, tatsächliche Verbreitung und der konkrete Bedarf.

Kann ein Token mehrere Standards übernehmen?

Möglich. Eine Umsetzung kann mehrere Schnittstellen gleichzeitig unterstützen oder einem Basisstandard Erweiterungen hinzufügen. Ob diese Schnittstellen korrekt zusammenwirken, ist weiterhin am konkreten Code zu prüfen.

Bedeutet Standardkonformität, dass ein Token in jeder Wallet erscheint?

Das ist nicht gesichert. Eine Wallet muss zusätzlich das betreffende Netzwerk, die Version des Standards und optionale Funktionen unterstützen sowie den richtigen Contract oder Mint erkennen. Metadaten wie Name und Symbol können außerdem eine zusätzliche Quelle erfordern.

Kann ein Standard die Sicherheit eines Tokens garantieren?

Nein. Ein Standard legt nur gemeinsame Schnittstellen oder Verhaltensanforderungen fest. Codefehler, Administrationsrechte, externe Daten, Freigaben der Nutzenden und das zugrunde liegende Netzwerk können weiterhin Risiken verursachen.

Verwandte Begriffe

Lies weiter über Krypto-Token, Smart Contract, Blockchain und Krypto-Wallet, oder kehre zum Krypto-Glossar zurück.

Quellen

• NISTIR 8301: Blockchain Networks: Token Design and Management Overview — Datenmodelle für Token, Protokoll- und Kontovorgänge sowie der unterschiedliche Umfang von Standards.
• Ethereum.org: Token-Standards — Rolle der Token-Schnittstellen für die Kompatibilität zwischen Wallets, Anwendungen und Onchain-Programmen.
• Standardprozess der Ethereum-Anwendungsschicht — ERC-Kategorie, Statuswerte von Standardvorschlägen und Umfang der Interoperabilität von Anwendungen.
• Ethereum-Standard für fungible Token ERC-20 — grundlegende Schnittstellen für Guthaben, Übertragung, Freigabe und Ereignisse.
• Ethereum-Standard für nicht fungible Token ERC-721 — Haltung, Übertragung, Freigabe und optionale Erweiterungen eigenständig nummerierter Token.
• Solana Docs: Tokens und Erweiterungen — gemeinsames Token-Programm, Mints, Token-Konten und optionale Erweiterungen.