Die Notwendigkeit von Interoperabilität in Sicherheits-Token-Protokollen – Thought Leaders

Eine kurze Geschichte der Token

Es sind über 10 Jahre vergangen, seit Bitcoin erstmals die Blockchain‑Technologie der Welt vorstellte. In dieser Zeit hat sich die Liste potenzieller Anwendungsfälle für verteilte Ledger rasch erweitert, von digitalen Währungen über Lieferketten bis hin zum Identitätsmanagement. Im Kern folgen jedoch viele dieser Anwendungsfälle einer ähnlichen Struktur: Sie ermöglichen es Nutzern, digitale Vermögenswerte peer‑to‑peer zu halten und zu übertragen. Kurz gesagt, wir können jetzt digitale Vermögenswerte handeln und verfolgen, ohne dass eine zentrale vertrauenswürdige Instanz den Prozess verwaltet.

Diese Entwicklung des Raums führte natürlich zur Erfindung von „Token“ – digitalen Vermögenswerten auf einer Blockchain, die Eigentum sein und zwischen Personen übertragen werden können. Token werden in zwei Hauptkategorien unterteilt: solche, die einen nativ digitalen Vermögenswert repräsentieren, und solche, die einen zugrunde liegenden realen Vermögenswert darstellen. Durch die Nutzung dieses neuen Paradigmas wurden bereits hunderttausende verschiedener Token allein auf Ethereum erstellt, mit einer kombinierten Marktkapitalisierung von über 15 Milliarden $ zum Zeitpunkt der Erstellung.

Eine der vielversprechendsten Anwendungen von Token ist die Darstellung realer Wertpapiere on‑chain, wodurch traditionell illiquide Vermögenswerte wie Gewerbeimmobilien fraktioniert und peer‑to‑peer übertragen werden können. Dieser Prozess, bekannt als „Tokenisierung“, hat sowohl bei etablierten Institutionen als auch bei neuen Start‑ups erhebliches Interesse geweckt, da er das Potenzial hat, viele bestehende Schmerzpunkte in den Kapitalmärkten zu lindern.

Regulatorische Konformität

Obwohl die Blockchain den technischen Transfer von Eigentum erleichtern kann, unterliegen Sicherheits‑Token denselben Gesetzen und Vorschriften wie traditionelle Wertpapiere. Die Sicherstellung, dass Sicherheits‑Token den regulatorischen Vorgaben entsprechen, ist daher für jede potenzielle Tokenisierung entscheidend und war bisher ein Hindernis für die Akzeptanz. Wie in der nachfolgenden Grafik zu sehen ist, wird regulatorische Unsicherheit allgemein als das größte Hindernis für die Blockchain‑Adoption angesehen.

Zahlreiche Projekte sind im Blockchain‑Umfeld entstanden, die jeweils ein Protokoll entwerfen, das die Regulierung, den Handel und das Management von Sicherheits‑Token vereinfachen und standardisieren soll. Betrachtet man allein Ethereum, so gehören zu den Projekten, die Standards zu diesem Problem veröffentlicht haben, Securitize, Harbor, Polymath und weitere. Ohne jedoch Änderungen an der aktuellen Gestaltung dieser Protokolle vorzunehmen, werden Investoren und Börsen weiterhin erhebliche Reibungen beim Kauf und Verkauf tokenisierter Wertpapiere erfahren. Warum das so ist? Interoperabilität.

Interoperabilität ist entscheidend

Interoperabilität ist einer der bedeutendsten Vorteile der Tokenisierung. Sie ermöglicht es einem gesamten Ökosystem von Kapitalmarkt‑Anwendungen und -Produkten, miteinander zu interagieren, weil sie gemeinsame Software‑Standards teilen. Damit Interoperabilität auf Anwendungs‑ und Produktebene ermöglicht werden kann, muss sie jedoch bereits auf der untersten Ebene – bei den Token selbst – beginnen. Im Bereich der Sicherheits‑Token ist Interoperabilität für zwei zentrale Parteien unerlässlich: Börsen und Investoren.

Als Börse möchten Sie in der Lage sein, Investoren für den Kauf jedes Sicherheits‑Tokens zu autorisieren, für den sie berechtigt sind – unabhängig davon, welches Unternehmen den Token erstellt hat. Das bedeutet, dass keine maßgeschneiderte Integration für jeden einzelnen Sicherheits‑Token nötig ist, sondern eine einfache und generische Integration, die für alle Sicherheits‑Token einheitlich ist.

Als Investor möchten Sie, dass der Onboarding‑Prozess so einfach und reibungslos wie möglich ist. Derzeit muss ein Investor, der Anteile von mehreren Stellen kaufen möchte, seine persönlichen Daten immer wieder im Rahmen des sogenannten Know‑Your‑Customer‑Verfahrens („KYC“) angeben. Die Blockchain hat das Potenzial, diesen Prozess zu transformieren, indem sie diese Informationen unveränderlich on‑chain speichert, wo sie dann von allen Sicherheits‑Token referenziert werden können. Das würde bedeuten, dass dieselben persönlichen Daten nicht jedes Mal erneut bereitgestellt werden müssen, wenn ein neuer Token gekauft wird; stattdessen würden nur ergänzende oder aktualisierte Informationen nach der ersten Registrierung benötigt. Dieser Prozess ist jedoch nur möglich, wenn Interoperabilität zwischen Sicherheits‑Token in den Standards, die das System regeln, vorgesehen ist.

Die Protokolle

Drei der führenden Sicherheits‑Token‑Protokolle von Ethereum wurden von Securitize, Harbor und Polymath veröffentlicht. Alle drei Protokolle basieren auf dem ERC‑20‑Token‑Standard von Ethereum, den sie erweitern, um Compliance in den Handel des Sicherheits‑Tokens zu integrieren. Dies wird erreicht, indem ein zweiter Vertrag abgefragt wird, der die Rechtmäßigkeit jedes Handels zum Zeitpunkt des Auftretens prüft.

Obwohl die Protokolle unterschiedliche Bezeichnungen verwenden, ist die Nutzung eines zweiten Vertrags in allen drei Fällen konsistent und erzielt dasselbe Ergebnis: die Verhinderung nicht‑konformer Trades. Dieser zweite „Regulator“-Vertrag wird durch Off‑Chain‑Dienste, die dazu autorisiert sind – beispielsweise eine Börse oder der Emittent des Tokens – mit den KYC‑ und Akkreditierungsinformationen der Nutzer auf dem neuesten Stand gehalten.

Obwohl diese drei Komponenten scheinbar alles enthalten, was zur Regulierung eines Sicherheits‑Tokens nötig ist (und in ihrer einfachsten Form sind sie das auch), bestimmt die Art und Weise, wie die Komponenten programmiert sind, tatsächlich die Interoperabilität. Leider fehlt den Protokollen in zwei Schlüsselbereichen Interoperabilität, was weiterhin Reibungen verursacht und die Adoption dieser Technologie verlangsamt:

1. Wie aktualisieren autorisierte Parteien On‑Chain‑Informationen über Nutzer?

Harbor

Harbor erklärt in ihrem Whitepaper, dass sie vorerst die einzige Partei sein werden, die autorisiert ist, Nutzerinformationen on‑chain zu aktualisieren. Die Zentralisierung dieser Rolle bedeutet, dass Börsen keine Daten, die vom Regulator referenziert werden, aktualisieren würden. Sie könnten daher keine neuen Empfänger des Tokens genehmigen, was das einfache Handeln von Tokens außerhalb der Harbor‑Plattform verhindert.

Securitize

Securitize hat bereits ein System implementiert, bei dem mehrere Parteien autorisiert werden können, sodass Investoren ihre Compliance‑Informationen an mehreren Stellen registrieren können und nicht zwingend über Securitize selbst gehen müssen. Die On‑Chain‑Daten werden dann direkt von der autorisierten Partei aktualisiert und können von allen Tokens von Securitize eingesehen werden. Darüber hinaus haben sie eine API entwickelt, die autorisierten Parteien den Zugriff auf die privat off‑chain gespeicherten Informationen über Investoren ermöglicht, sodass leicht festgestellt werden kann, ob eine Person konform ist oder ob weitere Informationen benötigt werden.

Polymath

Polymath verfügt über einen nativen digitalen Utility‑Token namens POLY, der auf ihrer Plattform für verschiedene Aufgaben erforderlich ist, einschließlich der Autorisierung einer Partei zur Aktualisierung Ihrer On‑Chain‑Daten. Damit eine Person sich selbst KYC‑prüfen kann, muss sie zunächst POLY‑Token erwerben, was keinen liquiden Fiat‑zu‑POLY‑Markt hat. Stattdessen muss die Person zunächst eine andere Kryptowährung wie Ethereum‑„Ether“ (ETH) mit Fiat kaufen und diese dann gegen POLY tauschen. Die Token können dann auf Polymaths KYC‑Marktplatz verwendet werden, um ein Angebot an einen KYC‑Anbieter zu machen. Wenn der KYC‑Anbieter das Angebot akzeptiert, wird er in POLY‑Token bezahlt, um die KYC‑Prüfung für die Person durchzuführen. Dieser Prozess stellt eindeutig eine erhebliche Onboarding‑Reibung für die Polymath‑Plattform dar und macht den Vorgang komplexer als nötig.

2. Wie diese Informationen über Nutzer dann on‑chain gespeichert und abgerufen werden?

Harbor

Aus dem Whitepaper und den Smart Contracts auf GitHub geht hervor, dass es technisch möglich ist, dass viele der Tokens von Harbor denselben Regulator‑Vertrag und dieselbe Quelle von Nutzerdaten teilen, jedoch ist dies aufgrund unterschiedlicher Regulierungen zwischen den einzelnen Tokens unwahrscheinlich. Das Fehlen von Live‑Tokens von Harbor auf Ethereum hat nicht geklärt, ob dies beabsichtigt ist oder ob jeder Token mit einem eigenen Regulator bereitgestellt wird.

Securitize

Das Protokoll von Securitize ist so konzipiert, dass ihr Regulator‑Vertrag einen dritten Smart Contract abfragt, der Nutzerinformationen speichert. Dies ermöglicht es jedem Token, individuelle Regelungen in seinem eigenen Regulator zu kodieren, während gleichzeitig eine gemeinsame Quelle von Nutzerdaten im dritten Vertrag geteilt wird, sodass wenn ein Nutzer KYC für einen Securitize‑Token durchführt, seine Informationen für zukünftige Token bereitstehen.

Polymath

Im Whitepaper wird nicht explizit angegeben, ob Polymath eine zentrale Quelle von Compliance‑Daten on‑chain hat, mit der jeder Regulator interagiert, oder ob die Tokens jeweils eine lokale Informationsquelle besitzen. Basierend auf den Beispielverträgen von Polymath scheint jedoch jeder Token eine lokale Informationsquelle zu nutzen, die nicht zwischen verschiedenen Tokens geteilt wird. Während dies Vorteile haben kann, birgt diese Konfiguration das Risiko von Datenredundanz und Inkonsistenzen.

Betrachten Sie folgendes Beispiel: Bob hat Interesse an zwei Polymath‑Sicherheits‑Tokens, ABC und DEF, und wurde für beide als Investor genehmigt. Diese Information wird an den Regulator‑Vertrag jedes Tokens gesendet. Einen Monat später versucht Bob, weitere DEF‑Tokens zu kaufen, aber es wird festgestellt, dass er nicht mehr akkreditiert ist. Diese Information wird an den Regulator von DEF gesendet, um Bobs Investor‑Status auf nicht‑akkreditiert zu aktualisieren. Jetzt gibt es on‑chain widersprüchliche Informationen: ABC geht davon aus, dass Bob ein verifizierter Investor ist, DEF jedoch nicht. Es ist leicht zu erkennen, dass eine zentrale Informationsquelle solche Diskrepanzen verhindern würde.

Interoperabilität der Protokolle

Wie bereits zuvor erörtert, gibt es zwei Hauptparteien, die an der Emission und dem Austausch von Sicherheits‑Tokens beteiligt sind und für die Interoperabilität von großer Bedeutung ist: Börsen und Investoren. Beide Parteien wünschen sich ein reibungsloses Erlebnis beim Umgang mit verschiedenen Sicherheits‑Tokens. Wenn also die Protokolle unverändert verwendet werden, schauen wir uns an, wie Börsen und Nutzer davon betroffen sind.

Börsen

Als Börse ist die Integration dieser Protokolle für Transferzwecke einfach: alle Tokens nutzen den ERC‑20‑Standard, der eine einheitliche Schnittstelle für Transfers, Genehmigungen und Kontostandsabfragen bereitstellt. Die weitere Integration des Compliance‑Aspekts jedes Protokolls wird jedoch deutlich komplexer. Sie erinnern sich, dass es derzeit nicht möglich ist, dass eine vertrauenswürdige Partei im Harbor‑Protokoll autorisiert wird – sie muss stattdessen die Nutzer zu Harbor leiten, um dort KYC zu absolvieren. Um dann das Securitize‑Protokoll zu integrieren, muss die vertrauenswürdige Partei von Securitize autorisiert werden, was ihr den Zugriff auf Investor‑KYC‑Daten über die Off‑Chain‑API ermöglicht und das Aktualisieren von On‑Chain‑Informationen im On‑Chain‑Datenspeicher erlaubt.

Die Integration des Polymath‑Protokolls ist wahrscheinlich am komplexesten. Die vertrauenswürdige Partei muss sich als KYC‑Anbieter auf Polymaths KYC‑Marktplatz registrieren und sich einrichten, um Gebote in POLY‑Token als Gegenleistung für KYC‑Dienstleistungen zu erhalten. Beim Erbringen von KYC‑Dienstleistungen für Investoren muss die vertrauenswürdige Partei dann sicherstellen, dass die duplizierten On‑Chain‑Daten, die über jeden Sicherheits‑Regulator gespeichert werden, nicht inkonsistent werden.

Nicht nur haben die Protokolle unterschiedliche Schnittstellen, die die vertrauenswürdige Partei integrieren muss, sondern jedes Protokoll hat auch eine andere Methode, um Fehlermeldungen an die Börse zu übermitteln. Beim Aufbau einer Schnittstelle ist es wichtig, alle auftretenden Fehler in etwas zu übersetzen, das für Nutzer verständlich ist. Beispielsweise kann ein Nutzer einen Token nicht kaufen, weil das Wertpapier eine Haltedauer hat, die noch nicht erfüllt ist, oder weil die maximale Anzahl zulässiger Inhaber beschränkt ist. Um diese Meldungen an die Nutzer zu kommunizieren, müsste die Börse für jedes Protokoll eine andere Methode der Fehlermeldungs‑Übermittlung integrieren.

Investoren 

Die unterschiedlichen Methoden, mit denen das Onboarding von Investoren in den Protokollen derzeit gestaltet ist, führen dazu, dass Investoren wahrscheinlich persönliche Informationen mehrfach an verschiedene Plattformen und auf unterschiedliche Weise bereitstellen müssen. Dies wird dadurch verursacht, dass Harbor keine anderen Parteien autorisiert hat und Polymath von Investoren verlangt, KYC‑Prozesse mit POLY‑Token zu beauftragen. Die durch diese Compliance‑Methoden verursachte Reibung kann Investoren davon abhalten oder unfähig machen, Wertpapiere zu kaufen, die sie sonst erwerben würden.

Das Ausmaß dieser protokollbedingten Reibung für Investoren könnte etwas gemindert werden durch die Art und Weise, wie Börsen die einzelnen Protokolle integrieren. Wenn ein Investor beispielsweise auf einer Börse KYC durchführt, um einen Polymath‑Token zu kaufen, könnte diese Börse, sofern autorisiert, gleichzeitig die Daten von Securitize aktualisieren. Das würde bedeuten, dass die Investor‑Informationen on‑chain verfügbar sind, falls sie in Zukunft benötigt werden. Ohne Änderungen an den aktuellen Protokolldesigns bleibt jedoch der Registrierungs‑ und Kaufprozess von Wertpapieren weiterhin abschreckend.

Lösungen

Die Lösung dieses Problems muss nicht komplex sein. Tatsächlich ist es möglich, bestimmte Lösungen einzuführen, ohne bereits auf Ethereum aktive Tokens zu ändern. Eine ideale Lösung, die minimale Reibungen für sowohl Börsen als auch Investoren erzeugt und Dateninkonsistenzen, die durch viele verschiedene Quellen von Compliance‑Daten entstehen, verhindert, würde Securitizes zentralen On‑Chain‑Datenspeicher stark ähneln; jedoch muss ein solches Setup branchenweit übernommen werden.

Durch eine zentrale Informationsquelle on‑chain werden Risiken von Dateninkonsistenzen eliminiert, und Investoren können verschiedene Wertpapiere durch nur eine Compliance‑Verifizierung erwerben. Dieser zentrale Vertrag würde die Überprüfung durchführen, dass die Übertragung für alle Sicherheits‑Tokens konform ist, und die Übertragung würde fortgesetzt oder zurückgerollt. Die Off‑Chain‑API, die allen autorisierten Börsen zugänglich ist, ermöglicht es, Investor‑Compliance‑Informationen an Börsen zu kommunizieren und reduziert die Anzahl der Anfragen, bei denen Investoren Daten bereitstellen müssen. Diese Aspekte zusammen reduzieren den Integrationsaufwand für Börsen massiv.

Die Einführung eines neuen Systems wie dieses verursacht natürlich einige Komplikationen, und es müssten noch mehrere Punkte geklärt werden. Beispielsweise bei der Gestaltung, wie jede Börse autorisiert wird: Wer entscheidet, dass eine Börse vertrauenswürdig ist? Es muss Zeit investiert werden, um ein System zu entwerfen, das einen Konsens ermöglicht.

Fazit

Die Tokenisierung von Wertpapieren befindet sich noch in einem frühen Entwicklungs- und Adoptionsstadium, was zum Teil auf die Komplexität der regulatorischen Konformität zurückzuführen ist. Während die Veröffentlichung von Protokollen die Einhaltung vieler dieser Vorschriften vereinfacht, indem sie deren Durchsetzung in jedem Transfer ermöglichen, liegt noch ein weiter Weg vor uns, bis dieser Prozess nahtlos ist. Solange wir keine Einigung zwischen den Protokollen darüber haben, wie Investor‑Informationen sowohl on‑chain als auch off‑chain gespeichert und aktualisiert werden, wird es weiterhin erhebliche Reibungen im Registrierungs‑ und Investitionsprozess für alle beteiligten Parteien geben.