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.

quickstart.ts
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.

Schwellenwertsignatur-ArchitekturArchitekturdiagramm des Signatorie-Schwellenwertsignatur-Signierflusses. Auf der linken Seite hält das Nutzergerät clientseitige Schlüsselanteile, geschützt durch zwei Faktoren: ein Passwort, gesichert per PAKE (Zero-Knowledge-Passworttausch, der das Passwort nie dem Server preisgibt), und einen Passkey, gesichert per WebAuthn PRF (ein hardwaregebundenes Geheimnis, das nur dieses Gerät erzeugen kann). Auf der rechten Seite speichert der Signatorie-Server verschlüsselte Anteile in seiner Datenbank — keine Abhängigkeit von iCloud oder Google Drive — und hält bewusst weniger Anteile als den Signierschwellenwert, sodass er nicht eigenständig signieren kann. In der Mitte assembliert das t-of-n-Schwellenwertprotokoll Anteile aus den entschlüsselten Client-Anteilen des Nutzers und optional dem Server-Anteil. Weder die Plattform noch Signatorie können allein eine Signatur erzeugen.User devicepassword · ZKP PAKEpasskey · WebAuthn PRFclient key sharesauthenticates · decrypts sharesThreshold signingrequires t-of-n sharesruns across user + serverSignatorie serverencrypted shares in DBno iCloud / Drive neededholds < thresholdcannot sign alonesignature

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.

create-and-sign.ts
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.

Signatorie — Nicht-verwahrende Wallet-Infrastruktur