OpenZeppelin und ERC-3643: So entsteht ein Security Token

Ein Team, das die Emission eines Security Tokens mit Eignungsanforderungen vorbereitet, etwa eine Anleihe, die verifizierten Anlegern vorbehalten ist, oder Aktien mit einer Obergrenze für die Zahl der Inhaber, stößt in der Regel schnell auf zwei Namen.OpenZeppelin Contractsist eine Bibliothek von Solidity-Contracts, die in auditierten Versionen veröffentlicht wird, mit Implementierungen von Tokens, Zugriffskontrolle und aktualisierbaren Proxies.ERC-3643ist der Ethereum-Standard, im Status Final, für Tokens mit Berechtigungen: Er definiert, wie der Token mit einem Identitätsregister und mit einem Compliance-Contract verbunden wird, der für jede Operation entscheidet, ob sie zulässig ist.

Die Beziehung zwischen beiden ist konkreter, als ihr gemeinsames Auftreten vermuten lässt. Die Referenzimplementierung von ERC-3643, die SuiteT-REX, übernimmt von OpenZeppelin die Ownership der Contracts, deren Initialisierung und einen Teil der Proxies, in Version 4.8 der Bibliothek, und schreibt Token, Identität und Compliance selbst. Der Bau eines Security Tokens damit läuft auf drei Engineering-Entscheidungen hinaus: welche OpenZeppelin-Version verwendet wird und wie die Contracts aktualisiert werden, wer welche Berechtigung über den Token hat und wie jede Operation separat getestet wird, denn nicht alle durchlaufen dieselben Prüfungen.

Was T-REX von OpenZeppelin übernimmt und in welcher Version

Die ERC3643 Association pflegt die Suite in einemöffentliches Repositoryunter GPL-3.0-Lizenz, dessen zuletzt veröffentlichte Version die 4.1.3 vom Juni 2025 ist; Tokeny, das Unternehmen, das T-REX entwickelt hat, hält sein eigenes bei 4.1.6. Beide deklarieren @openzeppelin/contracts und @openzeppelin/contracts-upgradeable im Bereich ^4.8.3 als Abhängigkeiten, also jede 4.x-Version ab 4.8.3.

Was die Suite aus dieser Bibliothek nutzt, ist begrenzt. Der Token, das Identitätsregister und sein Storage, das Register vertrauenswürdiger Aussteller, das der Claim-Topics und der Compliance-Contract erben direkt oder über die Agentenrolle von OwnableUpgradeable, der aktualisierbaren Variante des Ownership-Contracts von OpenZeppelin, und die Proxies der Suite stützen sich auf Initializable. Die aktualisierbaren Compliance-Module nutzen UUPSUpgradeable und werden hinter einem ERC1967Proxy deployt. Der Token hingegen erbt nicht die Implementierung vonERC-20aus OpenZeppelin: Er importiert nur das Interface IERC20 und führt seine eigene Buchführung über Salden, Einfrierungen und Transfers. Auch die Agentenrolle nutzt nicht AccessControl, sondern eine suiteeigene Bibliothek namens Roles.

Die Version ist vor allem wegen der aktualisierbaren Contracts wichtig. Die stabile Linie von OpenZeppelin ist heute die 5.x, mit der 5.6.1 vom Februar 2026 als letzter auditierter Version, und ihrDokumentationwarnt, dass bei aktualisierbaren Contracts das Storage-Layout zweier Hauptversionen als inkompatibel zu betrachten ist: Ein In-place-Upgrade von 4.9.3 auf 5.0.0 ist nicht sicher. Die 5.x speichert den Zustand jedes Contracts in einem eigenen Namespace (ERC-7201), während die 4.x ihn sequenziell anordnet. In einem Projekt mit T-REX hat das eine praktische Konsequenz: Ein eigenes Compliance-Modul, das von den Basis-Contracts der Suite erbt, erbt auch deren OpenZeppelin-Version, und der Wechsel auf 5.x erfordert, diese Basis-Contracts neu zu schreiben und neue Contracts zu deployen, statt die bestehenden zu aktualisieren. Die Version wird vor dem ersten Deployment festgelegt und schriftlich festgehalten.

Die Bibliothek unterscheidet außerdem Auditiertes von Nichtauditiertem. Unter dem npm-Tag latest veröffentlicht sie die auditierten Versionen und unter dem Tag dev die finalen Versionen, deren Audit noch aussteht, derzeit die 5.7.0. Dieses Audit deckt den OpenZeppelin-Code in dieser Version ab; der Code der Suite, die Erweiterungen des Projekts, seine Konfiguration und seine Integrationen brauchen eine eigene Prüfung. Mehr dazu unterwas ein Smart-Contract-Audit belegt.

Was ERC-3643 hinzufügt: Identität, Compliance und zwei Berechtigungsebenen

Auf dieser Basis definiert dieSpezifikation von ERC-3643sechs Bausteine: den Token, das Identitätsregister (Identity Registry) und dessen Storage, das Register vertrauenswürdiger Aussteller (Trusted Issuers Registry), das Register der Claim-Topics (Claim Topics Registry) und den Compliance-Contract (Compliance). Das Register verknüpft jede Wallet mit einer IdentitätONCHAINIDund einem Land; der Token fragt das Register, ob der Empfänger verifiziert ist, und den Compliance-Contract, ob die Operation die Regeln des Angebots einhält. Die Funktionsweise von isVerified und canTransfer ist imGlossareintrag zu ERC-3643beschrieben; für den Bau des Tokens interessiert vor allem, wer welchen Baustein kontrolliert.

Die Spezifikation verlangt ERC-173, den Standard für Contract-Ownership, und fügt eine Agentenrolle hinzu, die der Owner vergibt. In T-REX ist die Aufteilung klar. Der Owner des Tokens kann das Identitätsregister und den Compliance-Contract mit setIdentityRegistry und setCompliance ersetzen; der Owner des Compliance-Contracts fügt Module mit addModule und removeModule hinzu oder entfernt sie; und der Owner jedes Contracts mit Agenten, also des Tokens, des Identitätsregisters und seines Storage, ernennt oder entfernt sie mit addAgent und removeAgent. Die Agenten des Tokens führen den Betrieb aus: mint und burn, pause und unpause, setAddressFrozen und freezePartialTokens, forcedTransfer und recoveryAddress. Der Token ist nach der Initialisierung pausiert, sodass kein Transfer funktioniert, bis ein Agent unpause aufruft, ein Detail, das im ersten Integrationstest auftaucht.

In dieser Version der Suite gibt es nur eine Agentenrolle: Jeder Agent des Tokens kann alle diese Funktionen ausführen. Will der Emittent trennen, wer emittiert, wer einfriert und wer Wallets wiederherstellt, enthält dasRepository von Tokenyeinen Contract AgentManager, der die Agentenrolle erhält und sie in feinere Rollen aufteilt, etwa SupplyModifier, Freezer, TransferManager oder RecoveryAgent; das Repository der ERC3643 Association enthält ihn nicht, sodass diese Trennung explizit entworfen werden muss. Dieselbe Frage stellt sich bei derZugriffskontrolle von OpenZeppelin, wo jede Rolle eine Admin-Rolle hat: Neben der Frage, wer eine Berechtigung besitzt, ist zu klären, wer sie erteilen darf.

Die weitreichendste Berechtigung liegt nicht im Token. Die Proxys von T-REX delegieren an die Implementierung, die ein Authority-Contract, TREXImplementationAuthority, vorgibt, und dessen Owner wählt mit useTREXVersion die aktive Version, sodass alle Proxys, die auf diese Implementation Authority zeigen, gleichzeitig den Code wechseln. In der Produktion sollten sowohl dieser Owner als auch der des Tokens Multisig-Konten oder Governance-Contracts mit schriftlichem Verfahren sein, denn wer die Implementation Authority kontrolliert, kann die Logik jedes davon abhängigen Contracts ersetzen.

Tests pro Operation: was jede Funktion prüft

Ein gewöhnlicher Transfer durchläuft alle Prüfungen: Pause, Einfrierungen, freier Saldo, verifizierter Empfänger und Compliance-Regeln. Die Operationen der Agenten folgen anderen Pfaden, und an diesem Punkt stimmen Spezifikation und Referenzimplementierung nicht vollständig überein. Die Spezifikation gibt an, dass mint und forcedTransfer die Compliance-Regeln überspringen und nur einen verifizierten Empfänger verlangen. T-REX wendet sie bei mint sehr wohl an: Es ruft vor der Ausgabe canTransfer(address(0), _to, _amount) auf und lehnt die Ausgabe ab, wenn sie nicht erfüllt sind. Bei forcedTransfer prüft es nur, ob der Empfänger verifiziert ist, und gibt, wenn der Betrag den freien Saldo übersteigt, die Differenz frei; dennoch meldet es die Operation an den Compliance-Contract, sodass die Module ihre Zähler aktualisieren. burn prüft nur den Saldo. Keine der drei enthält die Pausenprüfung, sodass ein Agent bei pausiertem Token emittieren, verbrennen oder Transfers erzwingen kann.

Dieser Unterschied bestimmt, was getestet werden muss. Nehmen wir als hypothetisches Beispiel eine Anleiheemission mit einem Modul, das die Position jedes Anlegers auf 50.000 Einheiten begrenzt. In T-REX wird eine Ausgabe neuer Token, die einen Anleger über das Limit bringen würde, abgelehnt, während ein erzwungener Transfer an denselben Anleger ausgeführt wird. Das kann gewollt sein, wenn der Emittent forcedTransfer für eng definierte Fälle vorbehält, etwa die Vollstreckung eines Gerichtsbeschlusses oder die Korrektur eines Registerfehlers. Dann muss jedoch das Verfahren, das den Einsatz autorisiert, schriftlich festgelegt und getestet sein. Bei einer anderen Implementierung, die die Spezifikation wörtlich umsetzt, würde auch mint das Limit überschreiten. Fragen Sie den Anbieter deshalb, welchen Code jede Funktion ausführt, und nicht nur, welchen Standard er implementiert.

In der Anwendung für Anleger reserviert eine mit canTransfer simulierte Transaktion nichts: Zwischen Abfrage und Ausführung können sich Salden, Einfrierungen oder Attestierungen ändern. Die Oberfläche muss die Ablehnung daher als mögliches Ergebnis behandeln und darf eine Transaktion, die das Netzwerk noch nicht bestätigt hat, nicht als abgeschlossen anzeigen.

Wiederherstellung einer Wallet: was recoveryAddress bewirkt

Die Wiederherstellung ist die Funktion, die am stärksten von Verfahren außerhalb des Netzwerks abhängt. Ihre Signatur in der Spezifikation lautet recoveryAddress(lostWallet, newWallet, investorOnchainID), und in T-REX kann nur ein Agent sie aufrufen. DerToken-Contractsetzt voraus, dass die verlorene Wallet einen Saldo aufweist und die neue Wallet bereits ein Management-Key der ONCHAINID-Identität des Anlegers ist. Sind beide Bedingungen erfüllt, registriert er die neue Wallet mit demselben Land im Identitätsregister, überträgt den gesamten Saldo per forcedTransfer, übernimmt eine bestehende teilweise Einfrierung und die Einfrierung der Adresse und trägt die verlorene Wallet aus dem Register aus.

Daraus ergeben sich zwei Designentscheidungen. Die erste betrifft die Frage, wer den neuen Schlüssel zur Identität hinzufügt: War die verlorene Wallet der einzige Management-Key, kann der Anleger dies nicht mehr selbst tun. Die Identität braucht also einen weiteren Management-Key, etwa beim Identitätsverwalter der Plattform, und diese Verwahrung muss dokumentiert sein. Die zweite betrifft die Frage, wie der Agent prüft, dass der Antrag vom Inhaber stammt. Der Contract vertraut dem Agenten, sodass Identitätsprüfung, aufbewahrte Nachweise und Prüffrist Teil des Verfahrens des Emittenten sind. Der Abnahmetest deckt beide Seiten ab: eine legitime Wiederherstellung, bei der Saldo, Einfrierungen und Identität abgeglichen werden, und die Versuche, die scheitern müssen, etwa von einem Konto ohne Agentenrolle, an eine Wallet, die kein Schlüssel der Identität ist, oder von einer verlorenen Wallet ohne Saldo.

Was beim Deployment dokumentiert sein sollte

Die Suite enthält eine Factory, TREXFactory, deren Funktion deployTREXSuite in einem einzigen Aufruf den Token, die Register und den Compliance-Contract hinter Proxys deployt, die mit der Implementation Authority verbunden sind. Um dieses Deployment später zu prüfen, braucht es ein vollständiges Inventar der deployten Komponenten. Die technische Übergabe sollte mindestens Folgendes enthalten:

• Die Version der Suite und die von OpenZeppelin, mit denen kompiliert wurde, mit der exakten Referenz des deployten Codes.
• Die Adressen der Proxys, der Implementierungen und der Implementation Authority.
• Den Owner jedes Contracts und der Implementation Authority, mit Kontotyp und Verfahren für die Nutzung des Kontos.
• Die Agenten des Tokens und der Register sowie die Funktionen, die jeder von ihnen ausführt.
• Die geforderten Attestierungstypen, die vertrauenswürdigen Aussteller und die Compliance-Module mit ihren Parametern.
• Die Testergebnisse je Vorgang, einschließlich der erwarteten Ablehnungen.

Mit diesem Inventar lässt sich jede Anforderung der Emission einer Konfiguration und einem Test zuordnen, und ein Update wird geprüft, indem man zwei Versionen desselben Dokuments vergleicht.

ERC-3643 standardisiert Identität und Compliance; die Rechte der Anleger legt die Emission fest

Der Wert von ERC-3643 liegt darin, dass der Standard gemeinsame Schnittstellen für Identität, Compliance und Verwaltung festlegt und eine öffentliche Referenzimplementierung existiert, in der sich jede Kontrolle im Code nachlesen lässt. Eine Plattform, ein Verwahrer oder ein Handelssystem, das diese Schnittstellen kennt, kann einen Token integrieren, ohne für jeden Emittenten ein anderes Modell erlernen zu müssen.ERC-1400, ein weiterer Vorschlag für tokenisierte Wertpapiere, definiert eine Familie von Schnittstellen mit Partitionen des Guthabens, wurde aber nie als EIP veröffentlicht: Der Vorschlag blieb eininzwischen geschlossenes Issue im EIP-Repository von Ethereum.

Was der Standard nicht festlegt, sind die Rechte des Anlegers, die das Emissionsdokument bestimmt, der Identifizierungsprozess hinter jeder Attestierung und der Abgleich mit dem amtlichen Register der Wertpapiere, wo das Gesetz ihn verlangt, wie in Spanien gemäßERIR. Auch nicht das anwendbare Regime: Ein Token, der ein Finanzinstrument ist, fällt nicht unter MiCA, und zwar aufgrund von derenArtikel 2 Absatz 4nicht unter MiCA und unterliegt dem Wertpapierrecht. Die Suite wendet bei jedem Vorgang die für sie konfigurierten Bedingungen an; dass diese Bedingungen der Emission entsprechen, ist Aufgabe des Emittenten und seiner Kanzlei.

Bei Metlabs entwickeln wirSecurity-Token-Emissionen mit ERC-3643und eineTokenisierungsplattformWhite-Label-Lösung, die das Onboarding der Anleger, die Zeichnung und den Betrieb durch den Emittenten abdeckt. Wenn Sie eine Implementierung prüfen,erzählen Sie uns davonInstrument, Jurisdiktion, Kriterien für die Anlegerberechtigung und bestehende Integrationen, und wir sagen Ihnen, welcher Teil Konfiguration der Suite ist und welcher Eigenentwicklung erfordert.