Cold Storage vs. Multisig vs. MPC für tokenisierte RWA

Was sich ändert, wenn der Vermögenswert ein tokenisierter RWA ist und nicht einfach ETH

Die Verwahrungsfrage sieht auf den ersten Blick identisch aus: Sie haben einen Private Key, Sie wollen ihn sicher aufbewahren, Sie wollen Transaktionen signieren. Tokenisierte Real-World Assets (RWA) wie OUSG von ONDO, BUIDL von BlackRock oder in MNT denominierte Treasury-Produkte von Mantle ändern die Kryptografie nicht. Was sie ändern, ist die Arbeitslast, die darauf aufsetzt.

Ein tokenisierter Geldmarktfonds oder Treasury-Fonds gibt Anteile typischerweise nach einem Zeitplan aus und nimmt sie zurück. OUSG wickelt Rücknahmen zum Beispiel auf T+1 ab. BUIDL schüttet Rendite kontinuierlich aus und unterstützt Transfers auf Token-Ebene sowie Rücknahmen über den Emittenten. Dieser Takt bedeutet, dass ein Treasury-Team nicht eine Woche lang auf einer einzelnen unsignierten Transaktion sitzen kann, wie es ein langfristiger BTC-Holder tun kann. Die Signer-Warteschlange muss innerhalb eines Geschäftstags abgearbeitet sein, oft innerhalb einer Stunde, wenn sich ein Rücknahmefenster schließt.

Die zweite Änderung ist die Prüfbarkeit. Bei gewöhnlichem ETH reicht der On-Chain-Datensatz für ein internes Finanzteam meist aus. Bei einem regulierten RWA gibt es auf der Off-Chain-Seite Wirtschaftsprüfer, Transfer Agents und manchmal eine Aufsichtsbehörde, die einen Nachweis verlangen wird, dass eine Rücknahme von namentlich benannten Menschen gemäß einer dokumentierten Richtlinie autorisiert wurde. Diese Anforderung formt die Verwahrung um, weil „wer signiert hat“ genauso wichtig ist wie „die Signatur ist gültig“.

Die dritte Änderung besteht darin, dass der operative Schlüssel selten der einzige Schlüssel ist. Die meisten RWA-Produkte trennen einen Policy Key, einen Schlüssel für den Tagesbetrieb und einen Guardian Key, und jeder unterliegt anderen Kontrollen. Sie als ein einziges Signierproblem zu behandeln, ist der Punkt, an dem viele Treasury-Designs scheitern.

Die Abwägung zwischen operativer Latenz und Angreiferkosten

Verwahrung ist keine einzelne Entscheidung, sondern eine Abwägung zwischen zwei Zahlen. Die erste ist, wie lange es dauert, eine gültige Signatur zu erzeugen, wenn das Geschäft sie benötigt. Die zweite ist, wie viel ein Angreifer aufwenden muss oder wie viele unabhängige Ausfälle er auslösen muss, bevor er eine betrügerische Signatur erzeugen kann.

Cold Storage im strengen Sinn treibt die Angreiferkosten sehr weit nach oben und die Latenz gleich mit. Der Schlüssel befindet sich auf einem Gerät, das nie mit dem Internet verbunden war, idealerweise in einem Tresor, und Signieren bedeutet, ihn physisch zu holen. Das ist großartig für eine langfristige BTC-Treasury und miserabel für einen Fonds, der ONDO oder BUIDL an jedem Geschäftstag zurücknehmen muss. Die Kosten der Langsamkeit sind nicht abstrakt: Verpasste Rücknahmefenster können Strafgebühren auslösen, Sie in den nächsten Zyklus schieben oder die Position in Extremfällen bis zum nächsten Cut des Emittenten sperren.

Multisig verschiebt die Abwägung, indem Vertrauen auf Signer und Geräte verteilt wird. Ein 3-von-5-Setup bedeutet, dass ein Angreifer drei unabhängige Signer kompromittieren muss, was deutlich schwieriger ist als einen zu kompromittieren, während die Latenz der Geschwindigkeit Ihrer schnellsten drei Signer entspricht. Der Haken ist, dass „unabhängig“ hier sehr viel Arbeit leistet. Wenn drei Ihrer Signer von derselben Person, auf demselben Betriebssystem und mit demselben Backup-Schema verwaltet werden, hat Ihnen die Multisig nicht die Schwierigkeit von drei Angreifern eingebracht. Sie hat Ihnen eine eingebracht.

MPC, also Threshold-Signature-Schemata wie GG20, GG20+, Lindell17 oder die neueren FROST-Implementierungen, verlagert die Berechnung der Angreiferkosten in das Protokoll selbst. Der Signierschlüssel existiert nie an einem einzigen Ort. Jeder Teilnehmer hält einen Share, und ein Threshold von ihnen erzeugt gemeinsam eine Signatur, ohne jemals den vollständigen Schlüssel zu rekonstruieren. Die Latenz kann sehr niedrig sein, vergleichbar mit einer Single-Signer-Hot-Wallet, und der Angreifer muss innerhalb eines engen Signierfensters einen Threshold von Teilnehmern kompromittieren.

Was MPC ebenfalls tut, und das ist der Teil, der nicht genug Beachtung findet, ist die Kosten operativer Fehler zu senken. Bei Multisig ist der Verlust eines Signers ärgerlich, aber wiederherstellbar, solange Sie über dem Threshold bleiben. Bei MPC hängt die Wiederherstellung vollständig davon ab, wie die Shares erzeugt wurden, wer sie hält und ob der Custodian noch existiert. Wenn Sie einen Laptop löschen und der Share nur auf diesem Laptop war, ist die Richtlinie möglicherweise schlicht nicht wiederherstellbar, und der Vermögenswert ist faktisch eingefroren, bis die zugrunde liegende Key-Share-Zeremonie mit den verbleibenden Teilnehmern erneut durchgeführt werden kann.

Warum institutionelle RWA-Verwahrer HSMs nutzen, keine Consumer-Hardware-Wallets

Eine Consumer-Hardware-Wallet, ob Ledger, Trezor, GridPlus oder Keystone, ist ein kleines Secure-Element-Gerät, das einen Seed speichert und Transaktionen offline signiert. Für einen persönlichen BTC-Bestand oder eine fünfstellige ETH-Position ist sie ausgezeichnet. Für eine Treasury, die operativ Rücknahmen in einem institutionellen RWA-Buch signiert, summieren sich die Lücken jedoch.

Die erste Lücke betrifft den Schlüsselexport und das Klonen. Hardware-Wallets sind so konzipiert, dass der Nutzer, nicht der Gerätehersteller, den Seed kontrolliert. Aus institutioneller Sicht ist das eine Haftungsquelle: Ein ausscheidender Mitarbeiter mit der Seed-Phrase und einem Backup in einem Bankschließfach ist ein Schlüsselpersonenrisiko, das sich nicht leicht beheben lässt. Institutionelle Verwahrer wollen Schlüssel, die sie gemäß einer schriftlichen Richtlinie rotieren, treuhänderisch hinterlegen oder zerstören können, und sie wollen, dass dieser Prozess von Anfang bis Ende auditierbar ist.

Genau dafür sind HSMs, Hardware-Sicherheitsmodule, gedacht. Geräte wie AWS CloudHSM, Thales Luna, Utimaco oder YubiHSM 2 sind FIPS-validiert, unterstützen rollenbasierten Zugriff und lassen sich in Policy-Engines integrieren, die jeden Signierversuch, den Initiator und die zugrunde liegende Regel aufzeichnen. Die Schlüssel verlassen das Gerät nie im Klartext, die Schlüsselrotation ist ein dokumentierter Workflow, und ein Prüfer kann eine saubere Nachweiskette sehen.

Die zweite Lücke betrifft das, was signiert wird. Eine Consumer-Hardware-Wallet zeigt dir eine Transaktion auf einem winzigen Bildschirm und fordert dich zur Bestätigung auf. Ein Treasury-Team, das mit OUSG oder BUIDL arbeitet, muss Richtlinien durchsetzen, bevor der Signierer die Transaktion überhaupt sieht: Limits pro Asset, zugelassene Gegenparteien, tägliche Rücknahmeobergrenzen, Vier-Augen-Kontrolle für alles oberhalb eines Schwellenwerts. Diese Logik gehört in eine Transaktions-Policy-Engine oder in eine Smart-Account-Schicht wie Safe (früher Gnosis Safe) mit Modulen, nicht zu einem Menschen, der auf ein 128x64-Pixel-Display starrt.

Die dritte Lücke ist der operative Durchsatz. Eine Hardware-Wallet ist für gelegentliche Nutzung gebaut, nicht für die Dutzende von Freigaben, die ein täglicher RWA-Fluss erzeugen kann, wenn man Yield-Sweeps, Gebührenzahlungen, Oracle-Bestätigungen und Abstimmungseinträge einbezieht. Die Ergonomie bricht lange vor der Sicherheit zusammen.

Multisig-Wiederherstellungsfallen, die gut aussehen, bis sie es nicht mehr tun

Multisig auf ETH wird meist als Safe-Wallet (früher Gnosis Safe) umgesetzt, mit Signierern auf Hardware-Wallets und einem dokumentierten Wiederherstellungskonzept. In der Theorie ist das robust. In der Praxis zeigen sich immer wieder drei Fallstricke.

Der erste ist die Homogenität der Signierer. Ein 5-von-9 wirkt sicher, bis dir klar wird, dass alle neun Signierer dieselbe Wallet-Software, dieselbe Firmware-Version und dasselbe Backup-Verfahren verwenden und drei davon am selben Nachmittag von derselben Person eingerichtet wurden. Die Sicherheit von Multisig skaliert mit der Unabhängigkeit der Signierer. Die Zahl 9 ist Dekoration. Entscheidend ist die Anzahl wirklich unabhängiger Kompromittierungsvektoren.

Der zweite ist die Verfügbarkeit der Signierer. Ein Multisig funktioniert nur, wenn du den Schwellenwert erreichen kannst. Wenn deine Signierer eine Mischung aus Auftragnehmern in drei Zeitzonen, einer reisenden Führungskraft und einer Wallet sind, die in einem Tresor liegt, für dessen Zugriff zwei Tage nötig sind, kannst du plötzlich keine zeitkritische ONDO-Rücknahme signieren, weil drei deiner fünf schnellsten Signierer im Flugzeug sitzen. Die Lösung ist meist eine Kombination aus kalten und warmen Signierern, mit einer Richtlinie, die besagt, dass Hot-Signierer nur kleine Beträge genehmigen dürfen. Das funktioniert, fügt aber ein weiteres Multisig hinzu, das verwaltet werden muss, und du bist wieder beim Rekursionsproblem.

Der dritte ist die Verwahrung von Wiederherstellungsschlüsseln. Jeder Safe hat ein Wiederherstellungskonzept, meist abhängig davon, wie die Signierer erzeugt wurden. Wenn die Wiederherstellung auf einer auf Papier geschriebenen Seed-Phrase in einem Tresor beruht, hast du nun ein einzelnes Stück Papier, dessen Kompromittierung einem Angreifer einen funktionsfähigen Signierer verschafft. Wenn die Wiederherstellung auf Social Recovery über Guardians beruht, hast du das Vertrauen auf die Guardians verlagert, die in fünf Jahren möglicherweise nicht mehr die sind, für die du sie hältst. Nichts davon ist ein K.-o.-Kriterium, aber jeder dieser Punkte ist eine Stelle, an der ein sauber aussehendes 3-von-5 stillschweigend zu einem 2-von-5 mit einem Signierer in einer Schublade wird.

Das Risiko verschwindender MPC-Key-Shares, einfach erklärt

Das definierende Merkmal von MPC, dass der vollständige Schlüssel nie an einem Ort existiert, ist zugleich sein definierendes Risiko. Die Signierrichtlinie lebt in den Teilnehmern, und die Teilnehmer können verschwinden.

Das Verschwinden des Anbieters ist das am häufigsten genannte Risiko. Wenn du bei Fireblocks, Anchorage, BitGo, Fordefi oder einem ähnlichen MPC-Anbieter verwahrst, sind deine Shares zwischen dir und dem Anbieter aufgeteilt. Wenn der Anbieter übernommen wird, den Markt verlässt, einen schweren Ausfall erleidet oder einfach deine Service-Stufe einstellt, kannst du deine Assets möglicherweise migrieren, aber nur, wenn die Migrationstools verfügbar sind und du Zeit hast. Im schlimmsten Fall hältst du einen Share, der Anbieter hält einen Share, und der Schwellenwert ist nicht mehr erreichbar, weil die Anbieterseite offline oder nicht kooperationsbereit ist.

Der Verlust von Teilnehmergeräten ist das nächste Risiko. MPC-Shares werden typischerweise in HSMs, dedizierten Signierknoten oder gehärteten Laptops gehalten. Jedes Gerät hat sein eigenes Konzept für die Schlüsselverwahrung, einschließlich der Frage, wie und wo Shares gesichert werden. Verlierst du zwei dieser Geräte, hast du ein Wiederherstellungsproblem, nicht nur eine Unannehmlichkeit. Die Minderung besteht in Share-Backups, aber Share-Backup ist selbst eine Verwahrungsentscheidung: Wo liegen die Backup-Shares, wer kann sie entschlüsseln, und wie weist du einem Prüfer nach, dass keine einzelne Person den Schlüssel aus den Backups wiederherstellen kann?

Protokoll- und Implementierungsrisiko ist das dritte Risiko. Threshold-Signature-Schemes sind komplexe Kryptografie, und die Implementierungen hatten bereits Fehler. Die Offenlegung 2022 rund um eine Schwachstelle in bestimmten GG20-Implementierungen, die neueren Erkenntnisse zu Threshold EdDSA und ein stetiger Strom von Problemen in Wallet-SDKs erinnern daran, dass "der Schlüssel existiert nie" eine stärkere Aussage ist als "der Schlüssel existiert nie und der Signiercode ist fehlerfrei." Für einen RWA-Treasury-Betrieb ist der richtige Schritt, unabhängige Sicherheitsaudits des Stacks des MPC-Anbieters zu verlangen und die Option offenzuhalten, auf ein anderes Schema zu migrieren, selbst wenn das teuer ist.

Eine wichtige Nuance sollte benannt werden: Die Sicherheit von MPC gilt pro Signiervorgang. Sobald ein Schwellenwert von Teilnehmern signiert, ist die Signatur für immer gültig, selbst wenn die Shares der Teilnehmer später zerstört werden. Beim Verschwinderisiko geht es also um zukünftige Signierfähigkeit, nicht um vergangene Signaturen. Das ist der richtige Rahmen für den Vorstand: Wir laufen nicht Gefahr, dass eine vergangene Transaktion gefälscht wird, sondern dass wir die Position nicht mehr betreiben können.

Ein praktischer Verwahrungs-Stack für RWA mit täglichen Rücknahmen

Angesichts der Arbeitslast sieht ein praktikables Setup für einen Fonds oder eine Protokoll-Treasury, die tokenisierte RWA hält, eher geschichtet als rein aus.

Die Basisschicht ist ein institutioneller Verwahrer mit FIPS-validierten HSMs für die langfristige Reserve. Hier liegt der Großteil der Position, mit richtliniengesteuertem Signieren und Rollentrennung. Für eine OUSG- oder BUIDL-Allokation, die nicht oft bewegt werden muss, ist dies der richtige Ort, weil die Latenzkosten für den Tresorzugang nur selten anfallen und die Kosten für Angreifer sehr hoch sind.

Die Arbeitsschicht ist ein Multisig Safe oder ein MPC-Cluster für Routinevorgänge: kleine Rücknahmen, Yield-Sweeps, Gebührenzahlungen, Oracle-Bestätigungen. Die Wahl zwischen Multisig und MPC hängt hier vom Signiervolumen, der Verteilung der Signierer und der Risikotoleranz des Teams im operativen Betrieb ab. Multisig ist leichter zu auditieren und leichter wiederherzustellen. MPC ist schneller und kommt mit hohen Signiervolumina besser zurecht. Viele Teams nutzen beides: einen Safe für Governance und einen kleineren MPC-Cluster für die Ausführung.

Die Policy-Schicht liegt über beiden. Eine Transaktions-Policy-Engine setzt Limits pro Asset, zugelassene Contracts, Tagesobergrenzen und Vier-Augen-Regeln durch. Die Signierer sehen keine Rohtransaktionen, sondern vorab genehmigte Absichten, und die Engine erstellt und übermittelt die eigentlichen Transaktionen. Hier wird der größte Teil des operativen Risikos tatsächlich kontrolliert, und hier reichen Consumer-Hardware-Wallets für institutionelle Nutzung nicht aus, da sie diese Richtlinie nicht vor dem Signierer durchsetzen können.

Die kalte Reserve-Schicht ist ein air-gapped Multisig für Governance- und Policy-Änderungen: Signierer ändern, Schlüssel rotieren, die Policy-Engine aktualisieren, große Beträge aus der Arbeitsschicht bewegen. Die Latenz ist hier akzeptabel, weil diese Ereignisse selten sind, und die Kosten für Angreifer sind sehr hoch, weil die Schlüssel in einem Tresor liegen.

Die ehrliche Zusammenfassung lautet, dass "Cold Storage vs Multisig vs MPC" der falsche Rahmen für institutionelle RWA ist. Der richtige Rahmen ist, welche Arbeitslast auf welche Schicht gehört und wie das Wiederherstellungskonzept aussieht, wenn ein Share, ein Signierer oder ein Anbieter wegfällt.

Wie du Entwicklungen bei der RWA-Verwahrung clever verfolgst

Die RWA-Verwahrung entwickelt sich schnell, weil sich Produkte, Verwahrer und Regulierungsbehörden alle gleichzeitig verändern. OUSG-Rücknahmen, BUIDL-Verteilungsmechanismen, Migrationen von MPC-Anbietern und Hinweise zu HSM-Firmware manuell zu verfolgen, ist ein aussichtsloses Unterfangen. Zippfeed hebt Schlagzeilen zu tokenisierten RWA mit Sentiment-Bewertung (bullish, neutral oder bearish) und einer Wichtigkeitseinstufung hervor, damit du dich auf die Ereignisse konzentrieren kannst, die dein Verwahrungsdesign tatsächlich beeinflussen, statt im Rauschen unterzugehen.