Klassische Blockchain-Token wie ERC-20 wurden für offene Finanzsysteme entwickelt: Jeder kann Token an jeden senden, ohne Einschränkungen. Security Tokens bilden dagegen reale Vermögenswerte ab, etwa Aktien, Anleihen, Immobilien oder private Fonds. Mit diesen Vermögenswerten gehen rechtliche Pflichten einher. Investoren müssen KYC- und AML-Prüfungen bestehen. Übertragungen können je nach Jurisdiktion beschränkt sein. Es können Obergrenzen für Bestände gelten. Token-Inhaber müssen verifiziert sein.

Hier setzt ERC-3643 an, auch bekannt als T-REX (Token for Regulated EXchanges). Anders als ERC-20 verankert ERC-3643 die Compliance direkt in der Smart-Contract-Ebene. Bevor eine Token-Übertragung stattfindet, prüft die Blockchain die Identität beider Parteien und die Compliance-Regeln. Besteht eine Partei die Prüfung nicht, wird die Übertragung nicht ausgeführt.

Für Emittenten und Plattformen in regulierten Märkten, in Europa vor allem unter MiFID II und in Deutschland unter dem Gesetz über elektronische Wertpapiere (eWpG), hat sich ERC-3643 als De-facto-Standard für konforme Security Tokens etabliert. Für deutsche Kryptowertpapiere kommt das Kryptowertpapierregister hinzu; wie beides zusammenspielt, zeigt der Abschnitt zur regulatorischen Abstimmung. Dieser Leitfaden erklärt, wie ERC-3643 funktioniert, warum es wichtig ist und wie es umgesetzt wird.

Das Problem, das ERC-3643 löst

Ein Schritt zurück: Warum genügt es nicht, einen ERC-20-Token auszugeben und die Compliance off-chain zu regeln?

Die Antwort zeigt eine grundlegende Schwäche klassischer Blockchains: Transparenz und Unveränderlichkeit arbeiten gegen die Compliance. Jeder kann die Blockchain einsehen und jede Transaktion nachverfolgen. Grundsätzlich kann jeder Token kaufen oder empfangen, und Off-Chain-Prüfungen lassen sich umgehen oder übersehen. Wer regulierte Wertpapiere ausgibt, geht mit einer reinen Off-Chain-Durchsetzung ein Risiko ein.

ERC-3643 kehrt dieses Prinzip um. Compliance wird nicht nachträglich auf den Token aufgesetzt, sondern ist in ihm selbst angelegt. Die Smart Contracts prüfen die Berechtigung, bevor sie eine Übertragung zulassen. Daraus entsteht, was wir „Compliance by Design“ nennen.

Die Schlüsselinnovation: Anstelle eines einzigen Token-Vertrags verwendet ERC-3643 eine modulare Architektur, bei der mehrere Smart Contracts zusammenarbeiten:

• On-Chain-Identitäten halten kryptographischen Nachweis des KYC/AML-Status

• Identitätsregister ordnen Wallet-Adressen verifizierten Identitäten zu

• Compliance-Module erzwingen Geschäftsregeln (geografische Beschränkungen, Investorenobergrenzen, Sperrfristen)

• Der Token-Vertrag orchestriert alle drei Ebenen, bevor er eine Übertragung ausführt

Dieses modulare Design ist entscheidend. Dies bedeutet, dass Compliance-Regeln aktualisiert werden können, ohne den Token-Vertrag selbst anzufassen, und verschiedene Emittenten können dieselbe Infrastruktur mit unterschiedlichen Regeln nutzen.

Wie die ERC-3643-Architektur funktioniert

On-Chain Identitäten (ONCHAINID)

Jeder Teilnehmer in einem ERC-3643-Ökosystem benötigt eine ONCHAINID, einen Smart Contract, der diese Person oder Entität on-chain repräsentiert.

Stellen Sie sich eine ONCHAINID wie einen digitalen Identitätssafe vor. Sie enthält überprüfbare Angaben, die von vertrauenswürdigen Dritten ausgegeben wurden: „Diese Person hat KYC bestanden", „Diese Person ist ein professioneller Kunde nach MiFID II", „Diese Person hat ihren Sitz in der EU". Diese Angaben sind kryptografisch von vertrauenswürdigen KYC-Anbietern signiert und damit manipulationssicher.

Der ONCHAINID-Standard (basierend auf ERC-734/735) bedeutet, dass diese Identitätsverträge interoperabel sind. Eine Person kann eine einzige ONCHAINID haben, die sie über mehrere ERC-3643-Tokens und Plattformen hinweg nutzt.

Identitätsregister

Das Identitätsregister ist der Vertrag, der Identitäten zur Zeit der Übertragung überprüft. Es pflegt eine Zuordnung: Wallet-Adresse → ONCHAINID-Vertrag.

Wenn eine Token-Übertragung initiiert wird, führt die isVerified()-Funktion des Identitätsregisters eine Prüfung durch:

• Ist die Wallet des Senders mit einer gültigen ONCHAINID verknüpft?

• Hält diese ONCHAINID die erforderlichen Angaben (z.B. „KYC bestanden", „Nicht in den USA ansässig")?

• Ist der Empfänger auch mit den gleichen Anforderungen verifiziert?

Wenn beide Prüfungen bestanden werden, wird die Übertragung fortgesetzt. Wenn eine davon fehlschlägt, wird die Transaktion zurückgesetzt.

Diese Überprüfung erfolgt on-chain und ist prüfbar: Sie haben einen permanenten Nachweis darüber, wer welche Tokens hielt und ob diese zum Zeitpunkt der Transaktion konform waren.

Compliance-Modul

Die Identitätsverifizierung stellt sicher, wer Tokens halten kann. Das Compliance-Modul definiert, wie Tokens bewegt werden können.

Beispiele für Compliance-Regeln:

• Investorenobergrenzen: Kein einzelner Investor kann mehr als 5% eines Tokens besitzen

• Jurisdiktionsbeschränkungen: Tokens können nicht an Adressen übertragen werden, die mit sanktionierten Ländern in Verbindung stehen

• Sperrfristen: Investoren können nicht innerhalb der ersten 12 Monate verkaufen

• Halterbeschränkungen: etwa weniger als 150 nicht qualifizierte Anleger je Mitgliedstaat für ein prospektfreies Privatplatzierungsangebot (Art. 1 Abs. 4 lit. b Prospektverordnung)

Das Compliance-Modul ist vom Token-Vertrag getrennt, was bedeutet, dass Emittenten Regeln im Laufe der Zeit anpassen können, ohne eine Neubereitstellung vornehmen zu müssen. Verschiedene Tokens können dasselbe Compliance-Modul wiederverwenden oder jedes kann über eine benutzerdefinierte Logik verfügen.

Der Token-Vertrag

Der ERC-3643 Token-Vertrag selbst erweitert die bekannte ERC-20-Schnittstelle, fügt jedoch ein kritisches Element hinzu: Vor jedem Transfer werden zwei Prüfungen durchgeführt.

Transfer Request ↓ Check Identity Registry → Is sender verified? Is receiver verified? ↓ Check Compliance Module → Do transfer rules allow this? ↓ If both pass → Execute transfer If either fails → Reject transfer

Dieses Design bewahrt die Rückwärtskompatibilität (ERC-3643 Tokens funktionieren in Standard-Wallets) und stellt die Compliance-Durchsetzung auf Protokollebene sicher.

Vergleich von ERC-3643 mit anderen Token-Standards

ERC-1400 setzte den Gedanken an Compliance-bewusste Tokens um, aber ERC-3643 verbessert dieses, indem es die Compliance-Logik vom Token-Vertrag selbst entkoppelt. Dadurch werden Regeländerungen vereinfacht und Tokens leichter wiederverwendbar.

Schritt-für-Schritt: Deployment eines ERC-3643 Tokens

Die Bereitstellung eines konformen Security Tokens erfordert die Orchestrierung mehrerer Smart Contracts. Die meisten Projekte erledigen dies nicht manuell: Sie nutzen eine T-REX Factory, welche den gesamten Aufbau in einer einzigen Transaktion automatisiert.

Schritt 1: Bereiten Sie Ihre Konfiguration vor

Vor der Bereitstellung müssen Sie definieren:

Token-Details:

• Token-Name, Symbol, Dezimalstellen (standardisierte Metadaten)

• Adressen der Agenten, die den Token prägen, einfrieren oder verwalten können

• Jeglichen vorhandenen Identitätsregisterspeicher, den Sie wiederverwenden möchten

• Welche Compliance-Module aktiviert werden sollen

Claim-Konfiguration:

• Welche Arten von Claims erforderlich sind (z.B. KYC bestanden, Akkreditierungsstufe)

• Welchen KYC-Anbietern Sie vertrauen, um Claims auszugeben

• Welche Claims jeder Anbieter ausstellen kann

Schritt 2: Rufen Sie die Factory auf

Sobald die Parameter zusammengestellt sind, rufen Sie deployTREXSuite() auf dem Factory-Vertrag auf. Dies führt eine einzige atomare Transaktion aus, die:

1. Ein Trusted Issuers Registry bereitstellt (verfolgt, welche KYC-Anbieter vertrauenswürdig sind)

2. Ein Claim Topics Registry bereitstellt (definiert erforderliche Claim-Typen)

3. Die Compliance-Engine bereitstellt (setzt Regeln durch)

4. Den Identitätsregisterspeicher bereitstellt (speichert Identitätsdaten)

5. Das Identitätsregister bereitstellt (überprüft Identitäten zur Zeit der Übertragung)

6. Den Token-Vertrag bereitstellt (Ihr Security Token)

7. Alle Komponenten miteinander verknüpft

8. Agentenrollen für das operative Management zuweist

All dies geschieht atomar. Wenn ein Schritt fehlschlägt, wird die gesamte Bereitstellung zurückgesetzt.

Schritt 3: Vertrauenswürdige KYC-Anbieter registrieren

Bevor Investoren Tokens halten können, müssen ihre Identitäten von einem vertrauenswürdigen Anbieter verifiziert werden. Sie registrieren genehmigte KYC-Anbieter im Trusted Issuers Registry.

Diese Anbieter stellen kryptografische Claims an Investoren-ONCHAINIDs aus, die beweisen, dass sie KYC/AML bestanden haben.

Schritt 4: Investoren onboarden

Für jeden Investor:

1. Erstellen oder stellen Sie eine ONCHAINID bereit (einen Smart Contract, der ihre Identität hält)

2. Mit einem vertrauenswürdigen KYC-Anbieter zusammenarbeiten, der Claims an diese ONCHAINID ausgibt

3. Die Wallet-Adresse des Investors registrieren und im Identitätsregister mit seiner ONCHAINID verknüpfen

Erst nach der Verifizierung kann der Investor Tokens empfangen.

Schritt 5: Prägen und Übertragen

Wenn alles bereit ist, können Sie Tokens an verifizierte Investoren prägen. Jede nachfolgende Übertragung überprüft automatisch Identität und Compliance-Regeln vor der Ausführung.

Der Investor muss nichts Besonderes tun: Er nutzt Standard-Wallets und Schnittstellen. Die Compliance-Logik läuft unsichtbar auf der Smart-Contract-Ebene.

Regulatorische Abstimmung: MiFID II und eWpG

ERC-3643 wurde nicht im luftleeren Raum entwickelt. Es wurde mit Blick auf die europäische Finanzregulierung geschaffen.

MiFID II (Richtlinie über Märkte für Finanzinstrumente II) erfordert:

• Investorenidentifizierung und -verifizierung

• Einstufung der Anleger sowie Geeignetheits- oder Angemessenheitsprüfung durch den Vertrieb, wenn dieser berät oder vermittelt

• Klar dokumentierte Aufzeichnungen von Transaktionen

Die MiCAR gilt nicht für Security Tokens: Kryptowerte, die Finanzinstrumente sind, bleiben im Wertpapierrecht (MiFID II, Prospektverordnung, eWpG; Art. 2 Abs. 4 lit. a MiCAR).

ERC-3643 adressiert diese Anforderungen direkt:

• ONCHAINID und Identitätsregister erfüllen Identifikationsanforderungen

• Compliance-Module können Eignungsregeln durchsetzen

• On-Chain-Transaktionen schaffen unveränderliche Prüfprotokolle

Bei deutschen Kryptowertpapieren entsteht das Wertpapier nicht durch den Token-Standard, sondern durch die Eintragung in ein Kryptowertpapierregister, das ein Registerführer mit BaFin-Erlaubnis führt (eWpG).

Für europäische Emittenten bedeutet die Nutzung einer ERC-3643-kompatiblen Tokenisierungsplattform, das regulatorische Konformitätsrisiko erheblich zu reduzieren. Die Compliance-Logik ist transparent, überprüfbar und auf Code-Ebene dokumentiert.

Reale Implementierungen

ERC-3643 ist nicht theoretisch. Es treibt bereits die Emission regulierter Tokens voran:

• Tokeny: Eine führende Plattform für die Emission von Security Tokens auf ERC-3643, die institutionelle Einsätze in ganz Europa vorantreibt

• Private Debt-Tokens: Europäische Vermögensverwalter tokenisieren private Anleihen und Kreditfonds

• Immobilien: Fraktionierte Immobilien-Tokenisierung, mit geografischen und Investorenrestriktionen, die on-chain durchgesetzt werden

• Fonds-Tokens: Private Equity- und Hedge-Fonds-Tokens mit Sperrfristen und Akkreditierungsanforderungen

Diese Einsätze beweisen, dass ERC-3643 bei großem Umfang funktioniert und reale regulatorische Anforderungen erfüllt.

Warum ERC-3643 für die regulierte Tokenisierung wählen

Compliance als Code: Compliance-Regeln sind transparent, auditierbar und werden automatisch durchgesetzt, ohne Verlass auf manuelle Off-Chain-Prozesse.

Investorenvertrauen: Klare On-Chain-Verifikation schafft Vertrauen in die Legitimität der Tokens.

Regulatorische Klarheit: Entwickelt für MiFID II und eWpG, reduziert es das rechtliche Risiko für europäische Emittenten.

Betriebseffizienz: Die Automatisierung der Transferverifizierung reduziert den administrativen Aufwand.

Flexibilität: Die modulare Architektur bedeutet, dass Regeln aktualisiert werden können, ohne den Token neu bereitzustellen.

Interoperabilität: Auf ONCHAINID basierende Identitäten funktionieren über verschiedene Tokens und Plattformen hinweg.

Vereinfachen Sie die ERC-3643-Implementierung mit ONINO

Das Bereitstellen und Verwalten eines ERC-3643-Token-Stacks ist komplex. Sie müssen Smart Contracts, Compliance-Regeln, Identitätsmanagement und KYC-Integrationen verstehen.

Hier kommt ONINO ins Spiel. Unsere Plattform abstrahiert die technische Komplexität, sodass Sie sich auf die Geschäftslogik konzentrieren können.

Mit ONINO können Sie:

• Ihre Plattform innerhalb einer Woche statt in Monaten einrichten, mit vorkonfigurierter ERC-3643-Infrastruktur

• KYC-Anbieter nahtlos integrieren: ONINO steuert die Identitätsprüfung über integrierte KYC-Anbieter und schreibt die Claims

• Compliance-Regeln über ein intuitives Dashboard verwalten, ohne Smart Contracts zu schreiben

• Mit vorintegrierten lizenzierten Partnern für Register, Verwahrung und KYC arbeiten

• Effizient über verschiedene Tokens und Emissionen hinweg skalieren

Ob Sie Immobilien, Private Equity oder aufstrebende Anlageklassen tokenisieren, ONINO bietet White-Label-Emissionssoftware für regulierte EU-Prozesse, mit Tokenisierung als optionaler Schiene.

Häufig gestellte Fragen

Benötigen Investoren für jedes Token eine separate ONCHAINID?

Nein. Ein Investor kann eine einzige ONCHAINID haben, die verifizierte Angaben von mehreren KYC-Anbietern enthält. Dieselbe Identität kann über verschiedene ERC-3643-Tokens und Plattformen hinweg genutzt werden. Dies reduziert die Onboarding-Reibung für wiederkehrende Investoren.

Eliminiert ERC-3643 Off-Chain-KYC?

Nein, KYC/AML-Prüfungen erfolgen weiterhin off-chain mit regulierten Anbietern. Die Ergebnisse werden jedoch als kryptografische Claims in der ONCHAINID des Investors on-chain repräsentiert. Das Token-System liest diese Claims während Transfers, um eine automatisierte On-Chain-Compliance zu ermöglichen.

Können ERC-3643-Tokens auf Sekundärmärkten gehandelt werden?

Ja, aber Übertragungen bleiben genehmigungspflichtig. Selbst wenn ein Token an einer Börse gelistet ist, muss jeder Transfer Identitäts- und Compliancetests bestehen.

Ist ERC-3643 mit Standard-Wallets kompatibel?

Ja. ERC-3643 bleibt rückwärtskompatibel mit ERC-20, sodass es in MetaMask, Hardware-Wallets und anderen Standard-Schnittstellen funktioniert. Die Compliance-Logik läuft transparent auf der Smart-Contract-Ebene.

Wie werden Compliance-Regeln aktualisiert?

Da Compliance-Module vom Token-Vertrag getrennt sind, können Regeln vom Token-Emittenten aktualisiert werden, ohne den Token selbst neu bereitzustellen. Dies ermöglicht es Emittenten, sich an regulatorische Änderungen anzupassen oder Geschäftsregeln im Laufe der Zeit anzupassen.

ERC-3643 bietet die technische Grundlage für die regulierte Tokenisierung, aber die Umsetzung erfordert Fachkenntnisse in Smart Contracts, Compliance und KYC-Integration.

Lassen Sie ONINO die Komplexität übernehmen. Unsere Plattform bietet institutionelle Infrastruktur für die Bereitstellung, Verwaltung und Skalierung von ERC-3643-Tokens, entworfen für europäische Emittenten, die MiFID II und eWpG-Anforderungen erfüllen müssen.

Vereinbaren Sie eine Demo mit unserem Team, um zu sehen, wie ONINO Ihre Tokenisierungs-Roadmap beschleunigen kann.

Oder erkunden Sie unsere White-Label-Emissionsplattform, um mehr darüber zu erfahren, wie wir konforme Asset-Finanzierung und Emission unterstützen.