Was sind die Unterschiede zwischen Security Token und Utility-Token?

Wenn ein Team einen Token entwirft, ist für dessen rechtliche Einordnung weder das Netzwerk noch der Standard ausschlaggebend, sondern die Liste dessen, was der Inhaber damit tun kann: ihn gegen eine Dienstleistung eintauschen, einen Anteil am Ergebnis des Unternehmens erhalten, in dessen Gesellschafterversammlung abstimmen oder zu einem bestimmten Zeitpunkt zurückerhalten, was er gezahlt hat. Die BegriffeSecurity Tokenund Utility-Token fassen diese beiden Design-Familien zusammen, sind aber Branchenbegriffe und keine rechtlichen Kategorien, und jede Rechtsordnung zieht die Grenze nach eigenen Kriterien. In den USA geschieht das anhand desHowey-Test; in der Europäischen Union anhand zweier unterschiedlicher Regelwerke, die sich nicht überschneiden.

In der Europäischen Union ist ein Security Token ein Token, der ein Finanzinstrument im Sinne von MiFID II, der Richtlinie 2014/65/EU, verkörpert, und unterliegt dem Wertpapierrecht. Für das, was die Branche Utility-Token nennt, gibt es dagegen eine gesetzliche Definition:Art. 3 Abs. 1 Nr. 9 MiCA, also der Verordnung (EU) 2023/1114, definiert den Utility-Token als „einen Kryptowert, der ausschließlich dazu bestimmt ist, Zugang zu einer Ware oder Dienstleistung zu verschaffen, die von ihrem Emittenten bereitgestellt wird“. Der Unterschied zwischen beiden liegt in den Rechten, die das Design dem Inhaber einräumt, und wird bei der Definition des Produkts festgelegt, bevor der Smart Contract geschrieben wird.

Zwei Regime, die sich nicht überschneiden

MiCA schließt Kryptowerte, die als Finanzinstrumente gelten, aus ihrem Anwendungsbereich aus (Art. 2 Abs. 4 Buchst. a), sodass ein Token nicht gleichzeitig beiden Regimen unterliegen kann. Zuerst wird die Einstufung als Finanzinstrument geprüft, anhand der Leitlinien, die die Europäische Wertpapier- und Marktaufsichtsbehörde (ESMA) 2025 veröffentlicht hat und die wir ausführlich in unserem Artikel überMiFID II und Tokenisierung erläutern. Nur wenn der Token kein Finanzinstrument ist und unter keine andere Ausnahme des Art. 2 fällt, stellt sich die Frage, welche MiCA-Kategorie auf ihn zutrifft.

DieseLeitlinienbeantworten auch die Frage, die sich stellt, sobald ein Token mehr als eine Funktion hat: Was gilt, wenn er den Zugang zu einer Dienstleistung mit Anlagemerkmalen verbindet? Die ESMA verlangt, zuerst zu prüfen, ob er die Kriterien eines Finanzinstruments erfüllt, und in diesem Fall hat diese Einstufung Vorrang; maßgeblich sind die Merkmale des Tokens, nicht die Bezeichnung, die der Emittent ihm gibt. Ihn Utility-Token zu nennen, schützt nicht, wenn seine Rechte denen einer Anleihe entsprechen. Umgekehrt wird ein Zugangstoken nicht dadurch zum Wertpapier, dass er auf einer Plattform gehandelt wird oder seine Käufer auf einen Kursanstieg hoffen.

Die Unterschiede im Einzelnen

Die Tabelle fasst die Unterschiede zusammen, die bei einem in Spanien angebotenen Projekt am stärksten ins Gewicht fallen. Die konkreten Pflichten hängen zudem vom Angebot und den jeweiligen Ausnahmen ab, die weiter unten erläutert werden.

Welche Rechte einen Token zum Finanzinstrument machen

Beim Token-Design dienen die ESMA-Leitlinien als Liste von Rechten, die man einzeln prüfen sollte. Ein Token, der eine Beteiligung am Unternehmen, Dividenden, einen Anteil am Liquidationserlös oder Stimmrechte bei gesellschaftsrechtlichen Entscheidungen gewährt, verleiht Rechte, die denen einer Aktie entsprechen. Zahlt er regelmäßig Zinsen oder verspricht er die Rückzahlung des Kapitals zu einem künftigen Zeitpunkt, entsprechen seine Rechte denen einer Anleihe. Und sammelt das Projekt das Geld der Inhaber ein, um es nach einer festgelegten Anlagepolitik zu investieren und die Erträge an sie auszuschütten, kann der Token ein Anteil an einem Organismus für gemeinsame Anlagen sein. Sind diese Rechte an fungible und übertragbare Token geknüpft, ist das Ergebnis ein Finanzinstrument.

Governance muss gesondert betrachtet werden, weil sie sich leicht einem Zugangstoken hinzufügen lässt. Die ESMA trennt Abstimmungen über Entscheidungen der Gesellschaft, etwa die Wahl der Geschäftsleitung oder die Zustimmung zu einer Fusion, die dem Stimmrecht einer Aktie entsprechen, von Abstimmungen über technische oder operative Fragen eines Protokolls, etwa ein Upgrade oder eine Anpassung der Gebühren, die das nicht tun. Ein Utility-Token kann diese zweite Art von Governance enthalten. Was er nach denselben Leitlinien nicht gewähren darf, sind finanzielle Rechte, die an Gewinne, Kapital oder den Liquidationsüberschuss eines Unternehmens geknüpft sind.

Darüber hinaus gibt es ein Design, das nicht unter MiCA fällt, ohne ein Finanzinstrument zu sein: einen Token, der nicht an andere Inhaber übertragen werden kann und nur vom Emittenten oder Anbieter akzeptiert wird, etwa ein Prepaid-Guthaben, das ausschließlich in der eigenen Anwendung nutzbar ist. Die ESMA ordnet ihn außerhalb des Anwendungsbereichs der Verordnung ein, ebenso wie einzigartige und nicht fungible Kryptowerte. Muss der Token für das Produkt nicht zwischen Nutzern zirkulieren, hat diese technische Entscheidung also eine rechtliche Konsequenz.

Was MiCA für einen Utility-Token verlangt

Für ein öffentliches Angebot eines Utility-Tokens verlangtArt. 4 Abs. 1 MiCAvom Anbieter, dass er eine juristische Person ist, ein Kryptowerte-Whitepaper erstellt, es der zuständigen Behörde übermittelt und veröffentlicht, seine Marketingmitteilungen an der Verordnung ausrichtet und die Verhaltenspflichten für Anbieter erfüllt. Das Whitepaper wird mindestens 20 Arbeitstage vor seiner Veröffentlichung übermittelt, und die Behörde billigt es nicht vorab (Art. 8); sind die Angaben unvollständig oder irreführend, haften der Anbieter und die Mitglieder seines Leitungsorgans gegenüber den Inhabern für die dadurch verursachten Verluste (Art. 15).

Die Ausnahmen verändern die Kosten eines Angebots am stärksten, und sie hängen von einer Produktfrage ab: ob die Dienstleistung bereits existiert. Verschafft der Utility-Token Zugang zu einer Ware oder Dienstleistung, die bereits existiert oder in Betrieb ist, findet Titel II von MiCA auf das Angebot keine Anwendung (Art. 4 Abs. 3 Buchst. c). Existiert sie noch nicht, findet er Anwendung, und das Angebot darf nicht länger als 12 Monate ab Veröffentlichung des Whitepapers laufen (Art. 4 Abs. 6). Unabhängig davon ist der Anbieter von der Pflicht befreit, das Whitepaper zu erstellen, zu übermitteln und zu veröffentlichen, wenn sich das Angebot an weniger als 150 Personen je Mitgliedstaat richtet, innerhalb von 12 Monaten 1.000.000 € nicht übersteigt oder sich ausschließlich an qualifizierte Anleger richtet und nur diese den Token halten können (Art. 4 Abs. 2).

Keine dieser Ausnahmen gilt, wenn der Anbieter oder eine in seinem Namen handelnde Person in irgendeiner Mitteilung die Absicht bekundet, die Zulassung des Tokens zum Handel zu beantragen (Art. 4 Abs. 4). Das sollte man bei der Vorbereitung des Launches berücksichtigen, denn schon ein Hinweis auf ein künftiges Listing auf einer Plattform genügt, um die Befreiung zu verlieren. Die Ausnahmen erstrecken sich auch nicht auf Dritte: Wer den Token für Kunden verwahrt oder handelt, benötigt in der Regel eine Zulassung alsCASP, mit Ausnahme des eng begrenzten Falls nach Art. 4 Abs. 5 für Angebote, die nach Abs. 3 ausgenommen sind.

Ein Beispiel: derselbe Token mit zwei Designs

Der Fall ist hypothetisch. Ein spanisches Softwareunternehmen bietet Cloud-Speicher an und möchte einen Token ausgeben, den seine Kunden im Voraus kaufen und gegen Kapazität einlösen: Jeder Token entspricht einem Terabyte für einen Monat, kann an andere Nutzer übertragen werden und wird bei der Einlösung verbrannt.

In diesem ersten Design hat der Inhaber gegenüber dem Emittenten nur ein Zugangsrecht, und der Token ist ein Utility-Token. Da die Dienstleistung bereits in Betrieb ist, fällt das Angebot nach Art. 4 Abs. 3 Buchst. c nicht unter Titel II von MiCA, sofern das Unternehmen keine künftige Zulassung zum Handel ankündigt. Die technische Arbeit konzentriert sich darauf, den Smart Contract mit der Dienstleistung abzustimmen: verhindern, dass dieselbe Einheit zweimal eingelöst wird, eine Einlösung abwickeln, die mitten im Prozess fehlschlägt, und festlegen, was mit den Guthaben geschieht, wenn sich die Bedingungen der Dienstleistung ändern oder sie eingestellt wird.

Um den Token attraktiver zu machen, schlägt das Vertriebsteam zwei Ergänzungen vor: vierteljährlich 20 % des Gewinns aus der Dienstleistung an die Inhaber ausschütten und ihnen ein Stimmrecht bei der Wahl eines Mitglieds des Verwaltungsrats geben. Damit gewährt der Token gewinnabhängige Rechte und Stimmrechte bei gesellschaftsrechtlichen Entscheidungen, also die Merkmale, die die ESMA einer Aktie zuordnet, und da er zudem fungibel und übertragbar ist, wird er zum Finanzinstrument. MiCA ist nicht mehr anwendbar, und für das Unternehmen gilt ein anderer Ablauf. In Spanien benötigt ein mittels DLT dargestelltes Wertpapier ein Emissionsdokument und eineERIR, die sein Register führt; das öffentliche Angebot erfordert einen Wertpapierprospekt oder eine Ausnahme, und der Token brauchtÜbertragungsbeschränkungensowie eine Identifizierung der Inhaber. Diese Funktionen bilden Standards wieERC-3643direkt im Smart Contract ab. Ist die Emittentin zudem eine Sociedad Limitada (die spanische Entsprechung der GmbH), können ihre Geschäftsanteile keine Wertpapiere sein; mehr dazu im Leitfaden zuTokenisierung von Unternehmen und Start-ups.

Keines der beiden Designs ist an sich besser. Das erste hält das Produkt in einem leichteren Regime, solange der Token Zugang zu einer Dienstleistung bleibt; das zweite gibt den Inhabern Anlegerrechte und verlangt die Struktur einer Wertpapieremission. Was nicht funktioniert, ist der Mittelweg: Einen Utility-Token mit einer Rendite auszustatten, um ihn besser zu verkaufen, macht ihn genau dadurch zu einem anderen Produkt mit anderem Rechtsrahmen.

Was vor dem Schreiben des Smart Contracts entschieden werden sollte

In der Designphase lässt sich die Einstufung am kostengünstigsten festlegen, denn danach erzwingt jede Änderung der Rechte eine erneute Prüfung und kann einen Token, der sich bereits in den Händen von Nutzern befindet, in ein anderes Regime verschieben. Es empfiehlt sich, schriftlich festzuhalten, welche Rechte der Token gewährt, wer ihn halten und übertragen darf, ob die Dienstleistung, zu der er Zugang verschafft, bereits existiert, welche Governance er umfasst und wie das Angebot kommuniziert wird, und dieses Dokument vor dem Deployment mit der Kanzlei abzustimmen, die die Einstufung verantwortet.

Bei Metlabs entwickeln wir beide Token-Arten:Utility-Tokendie das Guthaben mit dem Dienst abstimmen, zu dem sie Zugang gewähren, undSecurity Tokenmit den Beschränkungen und der Registerführung, die eine Wertpapieremission erfordert. In beiden Fällen setzt der Smart Contract eine Einstufung um, die das Projekt bereits getroffen hat.