ERC-1155: Der Multi-Token-Standard für fungible, NFT- und semi-fungible Token

Was ist ERC-1155? Definition und Ursprung

ERC-1155 ist ein Smart-Contract-Standard auf der Ethereum-Blockchain, der fungible, nicht-fungible und semi-fungible Token in einem einzigen Vertrag verwaltet. Das klingt technisch – ist aber eine der praktisch wichtigsten Innovationen im Token-Ökosystem der letzten Jahre.

Vor ERC-1155 brauchtest du für jede neue Token-Art einen eigenen Smart Contract. Willst du in einem Spiel eine Spielwährung, ein einzigartiges Schwert und ein zeitlich begrenztes Saison-Item anbieten? Drei separate Verträge, dreifache Deploymentkosten, dreifache Komplexität. ERC-1155 löst genau dieses Problem: Ein einziger Vertrag ersetzt beliebig viele ERC-20- und ERC-721-Verträge gleichzeitig.

Der Standard wurde 2017 vom Gaming-Blockchain-Unternehmen Enjin vorgeschlagen. Die Motivation war direkt aus der Praxis geboren: Enjin entwickelte ein Gaming-Ökosystem mit Hunderten verschiedener In-Game-Assets und stieß mit den damals verfügbaren Standards schnell an Grenzen. 2019 wurde ERC-1155 offiziell finalisiert und als Ethereum Improvement Proposal (EIP-1155) verabschiedet.

Der Standard unterstützt drei grundlegende Token-Typen:

• Fungible Token – austauschbar und identisch, wie eine Spielwährung oder ein DeFi-Token. Jede Einheit ist gleichwertig.
• Nicht-fungible Token (NFTs) – einzigartig und nicht austauschbar. Jedes Exemplar hat einen eigenen Wert und eine eigene Identität.
• Semi-fungible Token – der interessanteste Typ: Token, die ihren Status wechseln können. Ein Konzertticket ist vor dem Event fungibel (austauschbar gegen ein anderes Ticket derselben Kategorie), danach nicht-fungibel (ein einzigartiges Erinnerungsstück mit Zeitstempel).

Für NFTs gilt eine elegante Sonderregel: Wenn die Gesamtmenge (Supply) eines Token-Typs exakt auf 1 gesetzt wird, behandelt der Standard diesen Token automatisch als NFT. Du brauchst keine separate Logik – die Einzigartigkeit ergibt sich direkt aus der Mengendefinition.

Die Vertragsarchitektur ist dabei denkbar klar: Jeder Token-Typ bekommt eine eindeutige tokenId. Alle Funktionen des Standards nehmen mindestens diese tokenId und eine Adresse als Parameter entgegen. Du kannst theoretisch Millionen verschiedener Token-Typen in einem einzigen ERC-1155-Vertrag verwalten – von der Spielwährung bis zum einzigartigen Kunstwerk, alles unter einem Dach.

Ein weiterer wichtiger Aspekt: ERC-1155 korrigiert bekannte Implementierungsfehler seiner Vorgänger. Bei ERC-20 und ERC-721 können Token versehentlich an Smart Contracts gesendet werden, die keine Token empfangen können – die Token sind dann unwiederbringlich verloren. ERC-1155 enthält native Schutzmechanismen dagegen, die wir im Abschnitt zu den technischen Kernfunktionen genauer betrachten.

ERC-1155 im Vergleich: ERC-20, ERC-721 und der Multi-Token-Standard

Um ERC-1155 wirklich zu verstehen, musst du wissen, was die Vorgänger können – und wo sie scheitern. Die drei Standards lösen ähnliche Probleme auf fundamental unterschiedliche Weise.

ERC-20 ist der älteste und meistgenutzte Token-Standard auf Ethereum. Er definiert fungible Token: Jede Einheit ist identisch und austauschbar, wie Euro-Münzen. ERC-20 ist das Rückgrat von DeFi – praktisch alle Kryptowährungen, Governance-Token und Stablecoins auf Ethereum basieren darauf. Der Haken: Pro Token-Typ brauchst du einen eigenen Vertrag. Willst du zehn verschiedene Spielwährungen, brauchst du zehn Verträge. Batch-Operationen? Fehlanzeige. Und wenn du versehentlich ERC-20-Token an einen inkompatiblen Smart Contract sendest, sind sie weg.

ERC-721 brachte 2018 die NFT-Revolution. Jeder Token ist einzigartig, hat eine eigene ID und kann nicht gegen einen anderen ausgetauscht werden. Digitale Kunst, virtuelle Grundstücke, Sammelkarten – ERC-721 ist das Fundament dieser Märkte. Aber auch hier: Ein Vertrag pro Sammlung, keine nativen Batch-Operationen, und die Gas-Kosten pro NFT-Transfer sind erheblich. Wer eine Spielwelt mit tausend verschiedenen Gegenstandstypen aufbaut, zahlt für jeden Typ einen eigenen Deployment-Preis.

ERC-1155 vereint beide Welten und geht darüber hinaus. Ein einziger Vertrag verwaltet beliebig viele Token-Typen – fungibel, nicht-fungibel und semi-fungibel gleichzeitig. Dazu kommen native Batch-Operationen, ein dynamisches Metadaten-System und eingebaute Sicherheitsmechanismen für sichere Übertragungen.

Beim Metadaten-System zeigt sich ein weiterer Unterschied: ERC-20 hat ein einfaches, statisches URI-System. ERC-721 vergibt jedem Token eine einzigartige URI – was bei großen Sammlungen zu erheblichem Overhead führt. ERC-1155 nutzt ein geteiltes, dynamisch aktualisierbares URI-System: Eine einzige URI-Vorlage mit einer {id}-Platzhalter-Variable deckt alle Token-Typen ab. Das spart Speicher und ermöglicht nachträgliche Metadaten-Updates.

Der entscheidende Unterschied bei der sicheren Übertragung: Nur ERC-1155 enthält native Empfangs-Hooks (onERC1155Received und onERC1155BatchReceived). Diese Hooks prüfen vor jeder Übertragung, ob der Empfänger-Contract Token empfangen kann. Kann er es nicht, wird die Transaktion abgebrochen – kein Tokenverlust.

Die Wahl zwischen den Standards ist keine Frage des „besser“ oder „schlechter“ – sie ist eine Frage des Anwendungsfalls. ERC-20 bleibt ungeschlagen für rein fungible Token in DeFi-Protokollen. ERC-721 ist die erste Wahl, wenn absolute Einzigartigkeit und maximale Kompatibilität mit bestehender NFT-Infrastruktur gefragt sind. ERC-1155 gewinnt immer dann, wenn du mehrere Token-Typen kombinieren, Gas sparen oder semi-fungible Logik abbilden musst.

Gas-Effizienz und Batch-Operationen: Der größte Vorteil von ERC-1155

Gas ist auf Ethereum das Maß aller Dinge. Jede Transaktion kostet Gas – und bei komplexen Projekten mit vielen Token-Transfers summieren sich diese Kosten schnell auf beträchtliche Summen. ERC-1155 adressiert dieses Problem direkt mit seiner Batch-Architektur.

Die zentrale Funktion heißt safeBatchTransferFrom. Sie nimmt Arrays von Token-IDs und Mengen entgegen und überträgt alle in einer einzigen Blockchain-Transaktion. Ein konkretes Beispiel: Du willst 100 Einheiten von Token-ID 3, 200 Einheiten von Token-ID 6 und 5 Einheiten von Token-ID 13 übertragen. Mit ERC-721 oder ERC-20 wären das drei separate Transaktionen mit drei separaten Gasgebühren. Mit ERC-1155 lautet der Aufruf: ids=[3, 6, 13], values=[100, 200, 5] – eine einzige Transaktion, eine einzige Gasgebühr.

Die Einsparungen sind erheblich: Gegenüber ERC-721 spart ERC-1155 bei Batch-Operationen durchschnittlich 60–80 % Gas, bei hoher Bündelungsrate sogar bis zu 90 %. Verglichen mit einzelnen ERC-20- oder ERC-721-Transfers liegt die Einsparung durch Batch-Verarbeitung und das sogenannte „Balance Packing“ bei 80–90 %. Diese Zahlen stammen aus Messungen mit realen Transaktionen und machen den Unterschied bei großen Projekten enorm spürbar.

Der erreichbare Durchsatz unterstreicht das: Durch Batch-Übertragung lassen sich bis zu 150–200 Token pro Sekunde übertragen. Für Gaming-Projekte mit tausenden gleichzeitigen Spielern oder für Marktplätze mit hohem Transaktionsvolumen ist das ein entscheidender Faktor.

Neben dem Transfer gibt es auch eine Batch-Abfragefunktion: balanceOfBatch erlaubt es, die Salden mehrerer Assets für mehrere Adressen in einem einzigen Schritt abzufragen. Statt zehn separate Blockchain-Calls für zehn Token-Typen reicht ein einziger Aufruf. Das reduziert nicht nur Kosten, sondern auch Latenz – wichtig für Anwendungen, die Echtzeit-Daten benötigen.

Die technische Grundlage dieser Effizienz ist das sogenannte Balance Packing: ERC-1155 speichert Salden mehrerer Token-Typen komprimiert in einem einzigen Speicher-Slot. Ethereum-Speicher ist teuer – je weniger Slots eine Transaktion liest oder schreibt, desto günstiger. Durch diese Komprimierung reduziert ERC-1155 den Speicherbedarf erheblich gegenüber Architekturen, die für jeden Token-Typ separate Mappings anlegen.

Für Airdrops und Minting-Kampagnen ist der Vorteil besonders deutlich. Willst du 10.000 Spielern je drei verschiedene Items schicken, zahlst du mit ERC-721 für 30.000 einzelne Transaktionen. Mit ERC-1155 bündelst du die drei Items pro Spieler in einem Batch – das reduziert die Anzahl der Transaktionen drastisch und damit auch die Gesamtkosten der Kampagne.

Technische Kernfunktionen und Vertragsarchitektur

ERC-1155 definiert eine Reihe von Pflichtfunktionen, die zusammen ein kohärentes und sicheres Token-System ergeben. Wer den Standard implementiert, muss diese Funktionen exakt nach Spezifikation umsetzen – das garantiert Kompatibilität mit Wallets, Marktplätzen und anderen Protokollen.

safeBatchTransferFrom ist die Herzfunktion des Standards. Sie nimmt fünf Parameter entgegen: Absender-Adresse (_from), Empfänger-Adresse (_to), ein Array von Token-IDs (_ids), ein Array von Mengen (_values) und optionale Daten (_data). Die Arrays müssen dieselbe Länge haben – jede ID korrespondiert mit einer Menge an derselben Position. Die Funktion überträgt alle Token-Typen atomar: Entweder gelingt die gesamte Übertragung, oder sie schlägt komplett fehl. Keine Teilübertragungen, keine inkonsistenten Zustände.

setApprovalForAll erlaubt es, einer Adresse (typischerweise einem Marktplatz-Contract) die Berechtigung zu erteilen, alle Token des Nutzers zu verwalten – in einem einzigen Schritt. Bei ERC-721 musst du für jedes einzelne Token eine Genehmigung erteilen. ERC-1155 macht das mit einem einzigen Aufruf für alle Token-Typen gleichzeitig. Das vereinfacht die Integration mit Marktplätzen erheblich.

onERC1155Received und onERC1155BatchReceived sind die Empfangs-Hooks, die das Sicherheitsproblem der Vorgänger lösen. Wenn ein ERC-1155-Token an einen Smart Contract gesendet wird, ruft der Standard automatisch den entsprechenden Hook auf dem Empfänger-Contract auf. Antwortet der Contract nicht mit dem erwarteten Rückgabewert, wird die Transaktion rückgängig gemacht. Token können so nicht mehr an inkompatible Contracts verloren gehen – ein Problem, das bei ERC-20 und ERC-721 Millionen von Dollar vernichtet hat.

Das Metadaten-URI-System von ERC-1155 ist elegant und effizient. Statt für jeden Token eine eigene URI zu speichern, definiert der Standard eine einzige URI-Vorlage mit einem {id}-Platzhalter. Die Token-ID wird hexadezimal in die URL eingesetzt. Das bedeutet: Alle Token-Typen eines Vertrags teilen sich dieselbe URI-Struktur, und Metadaten können nachträglich aktualisiert werden, ohne den Contract selbst zu ändern. Für Projekte mit dynamischen Metadaten – etwa Spielfiguren, die sich entwickeln – ist das ein erheblicher Vorteil.

Die semi-fungible Logik verdient besondere Aufmerksamkeit. Das Konzertticket-Beispiel macht es greifbar: Vor dem Konzert sind alle Tickets der Kategorie „Stehplatz“ fungibel – du kannst eines gegen ein anderes tauschen, ohne dass es einen Unterschied macht. Nach dem Konzert ist jedes Ticket ein einzigartiges Erinnerungsstück mit Datum, Sitzplatz und vielleicht einer Signatur. ERC-1155 kann diesen Statuswechsel innerhalb desselben Vertrags abbilden, indem die Logik des Token-Typs entsprechend programmiert wird. Kein Wechsel des Contracts, kein Migration-Aufwand.

Die Vertragsarchitektur im Vergleich macht den Skalierungsvorteil deutlich: Ein Spielentwickler, der 500 verschiedene Item-Typen anbietet, braucht mit ERC-721 500 separate Smart Contracts – 500 Deployments, 500 Audit-Prozesse, 500 Verwaltungsaufwände. Mit ERC-1155 ist es ein einziger Vertrag. Die tokenId als eindeutiger Identifikator pro Token-Typ übernimmt die Differenzierung intern. Das reduziert nicht nur Kosten, sondern auch die Angriffsfläche für Sicherheitslücken.

Sicherheitsrisiken und Best Practices bei ERC-1155-Smart-Contracts

Ein Smart Contract ist unveränderlich, sobald er auf der Blockchain deployed ist. Fehler lassen sich nicht einfach patchen – sie können dauerhaft ausgenutzt werden. Bei ERC-1155-Verträgen gibt es sechs bekannte Angriffsvektoren, die du kennen und adressieren musst.

Reentrancy-Angriffe sind die gefährlichste Klasse. Sie entstehen, wenn ein externer Contract während der Ausführung deiner Funktion zurückruft und dabei den Zustand des Vertrags in einem inkonsistenten Zwischenzustand ausnutzt. Bei ERC-1155 ist das besonders relevant, weil die Empfangs-Hooks (onERC1155Received) externe Aufrufe auslösen – genau das Einfallstor für Reentrancy. Die Gegenmaßnahme ist der nonReentrant-Modifikator aus der OpenZeppelin-Bibliothek. Er sperrt die Funktion für weitere Aufrufe, solange sie noch ausgeführt wird.

Unzureichende Zugriffskontrolle ist ein häufiger Fehler bei Anfängern. Wenn Minting- und Burning-Funktionen nicht ausreichend geschützt sind, kann jede Adresse beliebig viele Token erstellen oder vernichten. Die Lösung ist Role-Based Access Control (RBAC) über OpenZeppelins AccessControl-Modul. Du definierst Rollen wie MINTER_ROLE und BURNER_ROLE und weist sie nur autorisierten Adressen zu. Jede sensible Funktion prüft dann, ob der Aufrufer die erforderliche Rolle hat.

Unsichere Batch-Transfers entstehen, wenn die Empfängeradressen in Batch-Operationen nicht validiert werden. Ein Angreifer könnte Token an die Null-Adresse oder an inkompatible Contracts senden und dabei unerwartetes Verhalten auslösen. Whitelist-Validierung – also eine explizite Liste erlaubter Empfängeradressen – ist die robusteste Gegenmaßnahme für sensible Systeme.

Integer Overflow und Underflow waren lange eine der häufigsten Schwachstellen in Solidity-Contracts. Wenn Mengenberechnungen über die maximale Ganzzahl hinausgehen, können sie auf null oder negative Werte „umschlagen“ – mit katastrophalen Folgen für Token-Salden. Ab Solidity-Version 0.8 ist dieser Schutz in die Sprache integriert: Arithmetische Operationen werfen automatisch einen Fehler bei Über- oder Unterlauf. Für ältere Contracts sind SafeMath-Bibliotheken die Lösung.

Front-Running ist ein Angriff auf der Netzwerkebene. Transaktionen sind im Ethereum-Mempool öffentlich sichtbar, bevor sie in einen Block aufgenommen werden. Ein Angreifer kann eine Transaktion beobachten und eine eigene mit höherer Gasgebühr vorschalten, um einen Vorteil zu erlangen – etwa beim Kauf eines begehrten Items. Commit-Reveal-Schemata lösen das Problem: Der Nutzer sendet zunächst einen Hash seiner Absicht (Commit), und erst in einem zweiten Schritt die eigentliche Transaktion (Reveal). Der Angreifer sieht nur den Hash, nicht die Absicht.

tx.origin-Authentifizierung ist eine subtile, aber gefährliche Schwachstelle. tx.origin gibt die ursprüngliche Absenderadresse einer Transaktion zurück – nicht den direkten Aufrufer. Ein bösartiger Zwischenvertrag kann so die Identität eines Nutzers vortäuschen. Die sichere Alternative ist immer msg.sender, der den direkten Aufrufer zurückgibt.

Angesichts dieser Risiken ist ein professionelles Sicherheits-Audit vor dem Deployment in einer Produktionsumgebung keine Option, sondern eine Pflicht. Die Kosten dafür liegen je nach Komplexität des Vertrags zwischen 10.000 und 50.000 USD. Das klingt viel – ist aber minimal verglichen mit dem potenziellen Schaden durch eine ausgenutzte Schwachstelle. Audits prüfen Code, Logik, Architektur und alle bekannten Angriffsvektoren systematisch durch.

Anwendungsfälle: Gaming, DeFi, Ticketing und NFT-Marktplätze

ERC-1155 ist kein theoretisches Konstrukt – er ist heute in einigen der größten Blockchain-Projekte im Einsatz. Die Bandbreite der Anwendungsfälle reicht von Gaming über Finanzmärkte bis zu Lieferketten.

Gaming ist das Hauptanwendungsfeld, und das aus gutem Grund. Enjin, der Mitentwickler des Standards, hat ihn direkt für diesen Zweck geschaffen. Ein typisches Blockchain-Spiel braucht gleichzeitig: eine Spielwährung (fungibel), einzigartige Charaktere oder Waffen (nicht-fungibel), Saison-Items mit begrenzter Laufzeit (semi-fungibel) und Ressourcen wie Holz oder Stein (fungibel, aber projektspezifisch). Mit ERC-721 und ERC-20 wären das vier oder mehr separate Contracts. Mit ERC-1155 ist es einer. The Sandbox nutzt ERC-1155 für seine In-Game-Assets, Gods Unchained für seine Sammelkarten. Beide Projekte verwalten tausende verschiedener Asset-Typen in einem einzigen Vertrag.

NFT-Marktplätze profitieren von ERC-1155 besonders bei limitierten Editionen. Wenn ein Künstler 100 identische Drucke eines Werks verkauft, ist das mit ERC-721 umständlich – jeder der 100 Token braucht eine eigene ID, obwohl sie inhaltlich identisch sind. ERC-1155 löst das elegant: Ein Token-Typ mit Supply 100 repräsentiert alle 100 Drucke. OpenSea unterstützt beide Standards und zeigt, dass die Nachfrage nach ERC-1155-basierten Sammlungen real ist.

Event-Ticketing ist der Paradefall für semi-fungible Token. Vor dem Konzert sind alle Tickets der Kategorie „Innenraum“ fungibel – Ticket A ist genauso viel wert wie Ticket B. Nach dem Konzert wird jedes Ticket zu einem einzigartigen Erinnerungsstück: mit dem genauen Datum, dem Sitzplatz, vielleicht sogar mit einer Signatur des Künstlers als Metadaten. ERC-1155 kann diesen Statuswechsel nativ abbilden, ohne den Contract zu wechseln oder Token zu migrieren.

DeFi-Protokolle nutzen ERC-1155 für komplexe Finanzinstrumente. Optionen, Futures oder strukturierte Produkte haben oft sowohl fungible Komponenten (die zugrunde liegende Position) als auch nicht-fungible Aspekte (spezifische Konditionen, Laufzeiten, Ausübungspreise). Ein einziger ERC-1155-Vertrag kann diese Komplexität abbilden, ohne mehrere Token-Standards zu kombinieren.

Supply-Chain-Management ist ein weniger bekannter, aber vielversprechender Anwendungsfall. Produktmengen – etwa 10.000 Einheiten eines Medikaments – sind fungibel. Die Seriennummer jeder einzelnen Einheit ist nicht-fungibel. ERC-1155 kann beides in einem Vertrag verwalten: die Gesamtmenge als fungiblen Token-Typ und jede Seriennummer als Token mit Supply 1. Das ermöglicht lückenlose Rückverfolgbarkeit ohne die Komplexität mehrerer Contracts.

Die Entscheidung zwischen ERC-721 und ERC-1155 lässt sich auf zwei Leitfragen reduzieren: Brauchst du mehrere Token-Typen oder Batch-Operationen? Dann ERC-1155. Brauchst du absolute Einzigartigkeit mit maximaler Kompatibilität zu bestehender NFT-Infrastruktur? Dann ERC-721. Für neue Projekte mit komplexen Token-Ökonomien ist ERC-1155 heute in den meisten Fällen die effizientere Wahl.