Nicht-verwahrende Wallet-Infrastruktur
Self-Custody-Wallets. Keine Schlüssel gehalten.
Signatorie ist ein entwicklerorientiertes SDK und eine API für die Integration selbstverwalteter Wallets in Ihre Plattform. Ihr Unternehmen kann konstruktionsbedingt nicht auf Nutzermittel zugreifen — nicht aufgrund einer internen Richtlinie, sondern aufgrund der Systemarchitektur. Die Nicht-Verwahrungseigenschaft ist architektonisch durchgesetzt und kryptografisch verifizierbar.
Konzipiert für K-VASP, MiCA, DTSP, FSA und SFC.
import { Signatorie } from '@signatorie/sdk'; const sig = new Signatorie({ apiKey: process.env.SIGNATORIE_API_KEY, chain: 'ethereum',}); // Non-custodial wallet, threshold-signedconst wallet = await sig.wallets.create({ userId: 'user_abc123',});Das Problem
Verwahrung hat ihren Preis. Nicht-Verwahrung hat einen Haken.
In allen fünf maßgeblichen Regulierungsrahmen für Kryptowerte zieht die Verwahrung die schwersten Auflagen nach sich. Koreas K-VASP-Regime nach dem Gesetz über spezifische Finanzinformationen (Special Financial Information Act) verlangt ein Mindestkapital von über 3 Milliarden KRW, eine ISMS-Zertifizierung sowie die Integration in das Echtname-Bankensystem. Die europäische MiCA-Verordnung schreibt eine CASP-Zulassung vor — seit Dezember 2024 vollständig in Kraft. Das MAS-DTSP-Regime in Singapur, die FSA-VASP-Registrierung in Japan und das SFC-VASP-Regime in Hongkong bringen jeweils eigene Lizenzierungspflichten mit sich: laufende Prüfungsanforderungen, interne Kontrollrahmen und dedizierte Compliance-Funktionen. Für die meisten Plattformen ist der Eintritt in den Verwahrungsbereich keine bürokratische Frage — es ist eine Kapital- und Organisationsverpflichtung, die das Geschäftsmodell grundlegend verändert.
Die Auflagen knüpfen konkret an die Verwahrung an. Ein Unternehmen, das Nutzerschlüssel nachweislich zu keinem Zeitpunkt hält — und dies auch beweisen kann — operiert außerhalb dieses Perimeters. Der Haken lag bisher im Beweis: Echte Nicht-Verwahrung erforderte entweder den Aufbau von Schwellenwertkryptografie aus dem Nichts oder die Akzeptanz einer Produkterfahrung, die Nutzer ablehnen würden. Signatorie löst dieses Spannungsfeld auf. Die beweisbare Nicht-Verwahrungseigenschaft wird über eine Integrationsfläche bereitgestellt, gegen die ein Entwicklerteam in wenigen Tagen ausliefern kann.
K-VASP
Mindestkapital KRW 3 Mrd.+, ISMS-Zertifizierung
MiCA
CASP-Zulassung, in Kraft seit Dezember 2024
DTSP
MAS-Lizenzierungsregime, Singapur
FSA
VASP-Registrierung, Japan
SFC
VASP-Regime, Hongkong
Funktionsweise
Schwellenwertsignaturen, konstruktionsbedingt
Das Signaturverfahren von Signatorie basiert auf einem Schwellenwertsignaturverfahren (Threshold Signature Scheme — der Signierschlüssel wird in mehrere Anteile aufgeteilt; jede Signatur erfordert die Mitwirkung einer Mindestanzahl davon). Die Server von Signatorie halten dabei weniger Anteile, als der Schwellenwert zur Signaturerzeugung erfordert. Die arithmetische Konsequenz ist unmittelbar: Der Server allein kann konstruktionsbedingt keine Signatur erzeugen — durch mathematische Konstruktion. Dies ist keine Richtlinienentscheidung darüber, was Signatorie zu tun wählt. Es ist eine strukturelle Eigenschaft des Systems. Selbst eine vollständige Kompromittierung aller Signatorie-Server — jede Datenbank, jedes Backup — ergibt keine signierfähige Zusammenstellung von Anteilen.
Die Schlüsselanteile auf Nutzerseite sind unter den eigenen Authentifizierungsfaktoren des Nutzers verschlüsselt. Ein Passwort wird über PAKE (Password-Authenticated Key Exchange — ein Protokoll, das kryptografisches Material auf dem Client ableitet, ohne dass das Passwort jemals in verwertbarer Form den Server erreicht) verarbeitet. Ein Passkey wird über WebAuthn PRF verarbeitet (eine Passkey-Erweiterung, die der Hardware des Nutzers ermöglicht, ein deterministisches Geheimnis zu erzeugen, das ausschließlich diese spezifische Hardware produzieren kann). Die Anteile werden verschlüsselt in einer Datenbank gespeichert — entweder bei Signatorie oder bei Ihnen. Es besteht keine Abhängigkeit von Consumer-Cloud-Speicher wie iCloud oder Google Drive, die Konto-Wiederherstellungsabläufe außerhalb Ihrer Kontrolle mitbringen. Signatorie kann die von ihr gehaltenen Anteile nicht nutzen. Zum Signieren authentifiziert sich der Nutzer, der Client entschlüsselt dessen Anteile, und das Schwellenwertsignaturprotokoll läuft ab.
Funktionen
Konzipiert für Entwicklerteams
Multi-Chain-Unterstützung
Solana, Ethereum und EVM-kompatible Chains, Bitcoin, Cosmos, Polkadot, Aptos und Sui. Eine Integration, mehrere Netzwerke.
Entwicklerorientierte SDKs
SDKs für die gängigen Programmiersprachen sowie eine REST-API für jeden Tech-Stack. Die meisten Teams schließen die Integration in wenigen Tagen ab.
Keine Consumer-Cloud-Abhängigkeit
Anteile liegen verschlüsselt in einer Datenbank — bei Signatorie oder bei Ihnen — niemals in iCloud- oder Google-Drive-Konten der Nutzer. Signatorie kann die von ihr gehaltenen Anteile nicht nutzen.
Kryptografische Nicht-Verwahrung
Die Anzahl der serverseitig gehaltenen Anteile ist mathematisch auf einen Wert unterhalb des Signierschwellenwerts begrenzt. Diese Eigenschaft ist prüfbar — kein Marketingversprechen.
Nur-Nutzer-Signiermodus
Eine optionale Konfiguration, bei der der Server kein Schlüsselmaterial hält und ausschließlich als verschlüsselter Speicher fungiert — die stärkste Nicht-Verwahrungsgarantie, die die Architektur unterstützt.
TEE-freie Option
Das Design ist nicht auf Trusted Execution Environments angewiesen. Weniger Hardware-Abhängigkeiten, keine TEE-Seitenkanalangriffe zu verfolgen, ein einfacheres Sicherheits-Review.
Integration
Eine Wallet in unter fünfzehn Zeilen
Drei Schritte, jeder auf einen Blick lesbar: Client initialisieren, eine nicht-verwahrende Wallet für eine Nutzer-ID anlegen, eine Transaktion signieren. Die Nutzerauthentifizierung läuft vollständig clientseitig ab.
import { Signatorie } from '@signatorie/sdk'; const signatorie = new Signatorie({ apiKey: process.env.SIGNATORIE_API_KEY, chain: 'ethereum',}); // Create a non-custodial wallet for a new userconst wallet = await signatorie.wallets.create({ userId: 'user_abc123', authFactors: ['password', 'passkey'],}); // Sign a transaction (user authentication happens client-side)const signedTx = await wallet.sign(transaction);Regulierung
Wie die Architektur auf die Vorschriften abbildet
Signatorie ist so konzipiert, dass Ihre Plattform konstruktionsbedingt nie in den Verwahrungsstatus eintritt. Für jeden Regulierungsrahmen steht regulatortaugliche Architekturdokumentation bereit.
- K-VASP — Korea
- Nach dem Gesetz über spezifische Finanzinformationen (Special Financial Information Act) gelten VASP-Meldepflichten für Betreiber, die virtuelle Vermögenswerte verwahren. Die Schwellenwertarchitektur von Signatorie ist so ausgelegt, dass der Kunde nie in den Verwahrungsstatus eintritt — und damit die anfallenden Auflagen wesentlich reduziert werden: die Kapitalanforderung (derzeit KRW 3 Mrd.+), die ISMS-Zertifizierung und die Echtname-Bankintegration. Eine Dokumentation, die die Architektur dem K-VASP-Rahmen zuordnet, ist auf Anfrage erhältlich.
- MiCA — EU
- Die Verordnung über Märkte für Kryptowerte (Markets in Crypto-Assets Regulation) ist seit Dezember 2024 vollständig in Kraft. Sie schreibt für Kryptowertpapier-Dienstleister eine CASP-Zulassung vor. Nicht-verwahrende Infrastruktur fällt außerhalb der meisten CASP-Zulassungsanforderungen. Signatorie stellt Architekturdokumentation in einem Format bereit, das zur Einreichung bei nationalen zuständigen Behörden geeignet ist.
- DTSP · FSA · SFC
- Eine gleichwertige Positionierung für das MAS-DTSP-Regime in Singapur, die FSA-VASP-Registrierung in Japan und das SFC-VASP-Regime in Hongkong ist dokumentiert und auf Anfrage erhältlich.
Bereit zur Evaluierung?
Tragen Sie sich in die Warteliste für Early Access ein, oder fordern Sie die technische Dokumentation an, um die Architektur in Ihrem eigenen Tempo zu prüfen.