Ein Fachbeitrag für Bitcoin News Schweiz, basierend auf einer Analyse von OpenZeppelin.
Für ein öffentliches Blockchain-Protokoll sehen alle Adressen gleich aus: eine Zeichenkette mit einem Kontostand. Es gibt kein Feld für „verifizierter Investor“ oder „sanktionierte Entität“ im Basisnetzwerk. Genau hier setzt eine der drängendsten Fragen der Tokenisierung an: Wie bringen Banken, Vermögensverwalter und andere regulierte Institutionen ihre Sorgfaltspflichten – Identifikation von Geschäftspartnern, Sanktionsprüfung, Zugangsbeschränkungen – auf eine Infrastruktur, die per Design offen und pseudonym ist, ohne genau diese Offenheit zu zerstören?
Die Antwort entsteht nicht auf Protokollebene, sondern in einer zusätzlichen Schicht, die Institutionen selbst bauen: Onchain-Identität und Zugangskontrolle. Wie diese Bausteine zusammenspielen und wo die Compliance am Ende tatsächlich durchgesetzt wird, ist Thema dieses Beitrags.
Inhaltsübersicht
- Onchain-Identität: Wer man ist, ohne jede Transaktion einzeln freizugeben
- Zugangskontrollmechanismen: Durchsetzung am Punkt der Übertragung
- Wo Verantwortung liegt: Smart-Contract-Ebene versus Interface-Ebene
- Sicherheit, Audits und die Kosten von Fehlern
- Der Weg für Onchain-Finance
- FAQ
Onchain-Identität: Wer man ist, ohne jede Transaktion einzeln freizugeben
Onchain-Identität verknüpft eine Adresse überprüfbar mit realweltlichen Informationen – etwa KYC-Status, Akkreditierung oder Jurisdiktion. Die eigentliche Prüfung bleibt dabei weiterhin Sache einer vertrauenswürdigen Partei, etwa eines Claim-Issuers oder Anbieters von Nachweisen. Der entscheidende Unterschied zur klassischen Finanzwelt: Diese Partei prüft und stellt einen Nachweis einmal aus, statt jede einzelne Transaktion einzeln freizugeben. In der Praxis haben sich dafür einige Muster etabliert, die für Institutionen im Digital-Asset-Bereich mittlerweile als Industriestandard gelten:
- Identitätsregister und claim-basierte Standards: Frameworks wie ERC-3643 führen ein Onchain-Identitätsregister ein, das verifizierte Aussagen über eine Adresse speichert – etwa „KYC-geprüft“ oder „akkreditierter Investor“ –, ausgestellt von einem vertrauenswürdigen Claim-Issuer. Token, die auf diesem Modell aufbauen, prüfen das Register, bevor eine Übertragung zugelassen wird. Compliance-Logik liegt damit nahe am Asset selbst, statt nachträglich aufgesetzt zu werden.
- Verifiable Credentials und Attestierungen: Statt personenbezogene Daten onchain zu speichern, können Institutionen auf Nachweise setzen, die off-chain ausgestellt und onchain attestiert werden. Die Attestierung bestätigt lediglich, dass eine Prüfung stattgefunden und bestanden wurde – ohne die zugrunde liegenden Dokumente offenzulegen. So bleiben sensible Daten von der Blockchain fern, während Smart Contracts trotzdem etwas Konkretes zum Prüfen haben.
- Trennung von Identität und Konten: Manche Implementierungen, etwa ERC-3643 OnchainID, trennen Identitäts- und Nachweisinformationen von den eigentlichen Token-Konten. So kann eine Identität mit einem Satz verifizierter Nachweise über mehrere Handelskonten hinweg genutzt werden, wobei die Zuordnung im Identitätsregister definiert ist.
- Soulbound- und nicht übertragbare Token: Einige Implementierungen nutzen nicht übertragbare Token, die an eine bestimmte Adresse gebunden sind, um einen verifizierten Status abzubilden. Da der Token unter normalen Bedingungen nicht auf eine andere Wallet übertragen werden kann, wird es erheblich schwerer, die verifizierte Identität einer Partei auf eine nicht verifizierte Adresse zu übertragen.
Alle diese Ansätze lösen dasselbe Grundproblem: Sie geben einem Smart Contract eine manipulationssichere Möglichkeit, Berechtigungen zu prüfen, ohne dass eine vertrauenswürdige Partei jede Transaktion einzeln absegnen muss.
Zugangskontrollmechanismen: Durchsetzung am Punkt der Übertragung
Ist die Identität einmal etabliert, brauchen Institutionen einen Mechanismus, der Beschränkungen genau dann durchsetzt, wenn Token tatsächlich bewegt werden. Das geschieht typischerweise über Zugangskontrolle auf Smart-Contract-Ebene, in einer von mehreren Ausprägungen:
- Allowlists auf Token-Ebene: Der Token-Vertrag selbst prüft eine Liste zugelassener Adressen, bevor eine Übertragung ausgeführt wird – häufig als Whitelisting bezeichnet. Dieses Muster ist bei tokenisierten Wertpapieren und tokenisierten Fonds verbreitet, bei denen Regulierung vorschreibt, wer das Asset überhaupt halten darf.
- Permissioned Liquidity Pools: Im DeFi-Kontext beschränken manche Pools die Teilnahme auf Adressen, die einen bestimmten Nachweis besitzen oder eine Compliance-Prüfung bestehen. So kann institutionelle Liquidität mit Onchain-Märkten interagieren, ohne die Teilnahme für jede beliebige Adresse zu öffnen.
- Compliance-Module und austauschbare Regelwerke: Statt Beschränkungen fest in den Token zu programmieren, trennen viele institutionelle Implementierungen die Compliance-Logik in eine modulare Komponente, die direkt auf das Identitätsregister und die verifizierten Attestierungen zugreift. So lassen sich Regeln aktualisieren, jurisdiktionsspezifische Anforderungen ergänzen und unterschiedliche Regelwerke auf verschiedene Token-Klassen anwenden – ohne den Kernvertrag des Assets neu zu deployen.
Jeder dieser Mechanismen bringt einen anderen Kompromiss zwischen Flexibilität, Gas-Kosten und Prüfbarkeit mit sich. Welche Lösung passt, hängt stark vom jeweiligen Asset, seiner regulatorischen Einordnung und den Handelsplätzen ab, auf denen es später gehandelt werden soll.
Wo Verantwortung liegt: Smart-Contract-Ebene versus Interface-Ebene
Eine der folgenreichsten Design-Entscheidungen betrifft die Frage, wo Compliance tatsächlich durchgesetzt wird.
Die Smart-Contract-Ebene umfasst den Token-Standard, die Transferfunktion und die im Vertragscode fest verankerten Prüfungen gegen das Identitätsregister. Durchsetzung auf dieser Ebene ist konsistent und schwer zu umgehen: Ist eine Übertragungsbeschränkung im Token-Vertrag verankert, gilt sie unabhängig davon, über welche Oberfläche jemand mit dem Vertrag interagiert. Auf dieser Ebene zählt institutionelle Sicherheit am meisten, denn ein Fehler hier wirkt sich auf jede darauf aufbauende Schnittstelle aus.
Die Interface-Ebene sitzt oberhalb des Smart Contracts und umfasst die Frontends, Orderbücher und Custody-Integrationen, mit denen Institutionen und ihre Gegenparteien tatsächlich arbeiten. Kontrollen auf dieser Ebene bringen Komfort – etwa Screening vor der Transaktion oder ein reibungsloseres Onboarding –, doch ein Smart Contract lässt sich auch direkt ansprechen, wodurch jede Oberfläche umgangen werden kann. Das bedeutet: Eine Kontrolle, die nur auf Interface-Ebene existiert, ist nicht dasselbe wie eine im Smart Contract selbst verankerte Kontrolle. Beide bringen unterschiedliche Risikoprofile mit sich.
Für das Risikomanagement ist diese Unterscheidung zentral: Wer versteht, was ein Smart Contract eigenständig durchsetzt – unabhängig von einer bestimmten Oberfläche –, bekommt ein klareres Bild davon, wo die tatsächliche Durchsetzungsgrenze verläuft. Interface-seitige Werkzeuge fungieren als zusätzliche Sicherheits- und Komfortschicht oberhalb dessen, was der zugrunde liegende Vertrag ohnehin bereits erzwingt.
Sicherheit, Audits und die Kosten von Fehlern
Identitäts- und Zugangskontrolllogik ist im Grunde Risikomanagement- und Compliance-Code. Ein Bug in einer Identitätsregister-Prüfung oder in der Durchsetzung einer Allowlist kann dazu führen, dass ein reguliertes Asset auf einer Adresse landet, die es nie hätte halten dürfen. Aus diesem Grund spielen Smart-Contract-Audits und Sicherheitsprüfungen, die speziell auf Compliance-Logik zugeschnitten sind, bei institutionellen Deployments eine so zentrale Rolle. OpenZeppelin hat seit 2015 mehr als 900 Sicherheitsaudits durchgeführt und dabei über 10.000 Schwachstellen aufgedeckt, bevor sie in Produktion gelangten – Expertise, die direkt auf die Prüfung von Identitäts- und Zugangskontrolllogik vor dem Einsatz im institutionellen Maßstab anwendbar ist.
Erprobte Bibliotheken und Frameworks, die eine gründliche Prüfung durchlaufen haben, senken das Risiko subtiler Logikfehler. Eine klare Trennung zwischen Durchsetzung auf Smart-Contract-Ebene und Komfortfunktionen auf Interface-Ebene macht solche Audits zudem greifbarer, weil Prüfer die Durchsetzungsgrenze direkt nachvollziehen können, statt Compliance-Logik über mehrere Schichten des Stacks hinweg zu verfolgen.
Mit dem weiteren Wachstum der Tokenisierung realer Vermögenswerte und tokenisierter Fonds brauchen Institutionen, die in Onchain-Finance einsteigen, eine Abwicklungsinfrastruktur, die diese Regeln zuverlässig über den gesamten Lebenszyklus eines Assets hinweg durchsetzt – auch wenn sich Gegenparteien, Jurisdiktionen und regulatorische Anforderungen im Zeitverlauf ändern.
Der Weg für Onchain-Finance
Institutionelle Identität und Zugangskontrolle auf öffentlichen Blockchains bedeuten, die Compliance-Schicht mit derselben Sorgfalt zu bauen, die Institutionen bereits auf ihre bestehende Finanzinfrastruktur anwenden. Mit fortschreitender Tokenisierung werden jene Institutionen die Nase vorn haben, die Identität und Zugangskontrolle direkt in die Vertragsebene einbauen – denn ihre Compliance hält stand, wenn ein Regulator, Prüfer oder Geschäftspartner den Code selbst kontrolliert.
FAQ
Warum können Finanzinstitute öffentliche Blockchains nicht ohne zusätzliche Identitätskontrollen nutzen? Öffentliche Blockchains sind standardmäßig offen – jede Adresse kann mit jeder anderen interagieren. Finanzinstitute unterliegen jedoch regulatorischen Pflichten zur Identifikation von Geschäftspartnern und zur Beschränkung der Teilnahme, was eine zusätzliche Schicht aus Onchain-Identität und Zugangskontrolle oberhalb des Basisnetzwerks erfordert.
Was bedeutet Onchain-Identität im institutionellen Kontext? Onchain-Identität bezeichnet Mechanismen, die eine Blockchain-Adresse mit verifizierten Informationen verknüpfen – etwa KYC-Status oder Akkreditierung –, über Ansätze wie Identitätsregister, Verifiable Credentials und nicht übertragbare Token. So können Smart Contracts Berechtigungen prüfen, ohne dass eine vertrauenswürdige Partei jede einzelne Transaktion freigeben muss.
Wie funktioniert Zugangskontrolle bei tokenisierten Assets? Zugangskontrolle beschränkt, wer einen Token halten oder übertragen darf – über Mechanismen wie Allowlists (auch Whitelists genannt), Permissioned Liquidity Pools oder austauschbare Compliance-Module, die Berechtigungen prüfen, bevor eine Übertragung abgeschlossen werden kann.
Wird Compliance auf Interface- oder Smart-Contract-Ebene durchgesetzt? Die Smart-Contract-Ebene sorgt für konsistente und schwer zu umgehende Durchsetzung, da ein Vertrag unabhängig von der genutzten Oberfläche direkt angesprochen werden kann. Werkzeuge auf Interface-Ebene bringen Komfort und Screening zusätzlich mit, ersetzen aber nicht die Durchsetzung auf Smart-Contract-Ebene, sondern ergänzen sie.
Warum brauchen Identitäts- und Zugangskontrollmechanismen Sicherheitsaudits? Weil diese Mechanismen faktisch Risikomanagement-Code sind. Ein Logikfehler kann dazu führen, dass ein reguliertes Asset auf einer Adresse landet, die es nie hätte halten dürfen. Smart-Contract-Audits und speziell auf Compliance-Logik ausgerichtete Sicherheitsprüfungen helfen, solche Fehler vor dem Deployment zu entdecken.
Dieser Beitrag basiert auf einer Analyse von OpenZeppelin, „Identity, Access Control, and Institutional Participation on Public Blockchains“ (openzeppelin.com/news).
