Non-custodial wallet infrastructure

Self-custody wallets. No keys held.

Signatorie is a developer-grade SDK and API for building self-custody wallets into your platform. Your company cannot access user funds — not by policy, but by construction. The non-custody property is architecturally enforced and cryptographically verifiable.

Built for K-VASP, MiCA, DTSP, FSA, and 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',});

The problem

Custody has a cost. Non-custody has a catch.

Across the five major crypto regulatory frameworks, custody triggers the heaviest obligations. Korea's K-VASP regime under the Specific Financial Information Act requires a capital floor above KRW 3 billion, ISMS certification, and real-name banking integration. Europe's MiCA mandates CASP authorization — fully in force since December 2024. Singapore's MAS DTSP regime, Japan's FSA VASP registration, and Hong Kong's SFC VASP regime each impose their own licensing stack: ongoing audit requirements, internal control frameworks, dedicated compliance functions. For most platforms, entering the custodial perimeter is not a paperwork problem — it is a capital and organizational commitment that reshapes the business.

The obligations attach specifically to custody. A company that genuinely never holds user keys — and can prove it — operates outside that perimeter. The catch has always been the proof: until now, genuine non-custody meant either building threshold cryptography from scratch or accepting a product experience your users would reject. Signatorie collapses that trade-off. The provable property comes with an integration surface that a developer team can ship against in days.

  • K-VASP

    Capital requirement KRW 3B+, ISMS certification

  • MiCA

    CASP authorization, in force since December 2024

  • DTSP

    MAS Singapore licensing regime

  • FSA

    Japan VASP registration

  • SFC

    Hong Kong VASP regime

How it works

Threshold signatures, by construction

Signatorie's signing system is built on a threshold signature scheme — a cryptographic primitive in which the user's signing key is split into multiple shares, and any signature requires a minimum number (the threshold) of those shares to cooperate. Signatorie's servers hold fewer shares than that threshold. The arithmetic consequence is direct: the server alone cannot produce a signature, by mathematical construction. This is not a policy about what Signatorie chooses to do. It is a structural property of the system. A full compromise of every Signatorie server — every database, every backup — still does not produce a signing-capable set of shares.

The shares that live on the user side are encrypted under the user's own authentication factors. A password is handled via PAKE (password-authenticated key exchange — a protocol that derives cryptographic material on the client without the password ever reaching the server in a useful form). A passkey is handled via WebAuthn PRF (a passkey extension that lets the user's hardware produce a deterministic secret that only that specific hardware can produce). Shares are stored encrypted in a database — Signatorie's or yours. There is no dependency on consumer cloud storage such as iCloud or Google Drive, which inherit account-recovery flows outside your control. Signatorie cannot use the shares it holds. To sign, the user authenticates, the client decrypts their shares, and the threshold signing protocol runs.

Threshold-signature architectureArchitecture diagram of the Signatorie threshold-signature signing flow. On the left, the user device holds client-side key shares protected by two factors: a password secured with PAKE (zero-knowledge password exchange that never exposes the password to the server), and a passkey secured with WebAuthn PRF (a hardware-bound secret only that device can produce). On the right, the Signatorie server stores encrypted shares in its database — no iCloud or Google Drive dependency — and deliberately holds fewer shares than the signing threshold, so it cannot sign independently. In the center, the t-of-n threshold protocol assembles shares from the user's decrypted client shares and, optionally, the server's share. Neither the platform nor Signatorie can produce a signature alone.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

Capabilities

Built for engineering teams

  • Multi-chain support

    Solana, Ethereum and EVM-compatible chains, Bitcoin, Cosmos, Polkadot, Aptos, and Sui. One integration, multiple networks.

  • Developer-first SDKs

    SDKs across the major programming languages plus a REST API for any stack. Most teams complete integration in days.

  • No consumer-cloud dependency

    Shares live encrypted in a database — Signatorie's or yours — never in users' iCloud or Google Drive accounts. Signatorie cannot use the shares it holds.

  • Cryptographic non-custody

    The server-side share count is mathematically constrained below the signing threshold. That property is auditable, not a marketing claim.

  • User-only signing mode

    An optional configuration in which the server holds zero key material and acts only as encrypted storage — the tightest non-custody guarantee the architecture supports.

  • TEE-free option

    The design does not depend on trusted execution environments. Fewer hardware dependencies, no TEE side-channel exposure to track, a simpler security review.

Integration

A wallet in under fifteen lines

Three steps, each readable at a glance: initialize the client, create a non-custodial wallet for a user ID, sign a transaction. User authentication runs entirely client-side.

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);

Regulatory

How the architecture maps to the rules

Signatorie is designed so your platform never enters custodial status. Regulator-ready architecture documentation is available for each framework.

K-VASP — Korea
Under the Specific Financial Information Act, VASP filing obligations apply to operators that custody virtual assets. Signatorie's threshold architecture is designed so the customer never enters custodial status, materially reducing the obligations that attach: the capital requirement (currently KRW 3B+), ISMS certification, and real-name banking integration. Documentation mapping the architecture to the K-VASP framework is available on request.
MiCA — EU
The Markets in Crypto-Assets Regulation has been fully in force since December 2024. It requires CASP authorization for crypto-asset service providers. Non-custodial infrastructure sits outside most CASP authorization requirements. Signatorie provides architecture documentation in a format suitable for submission to national competent authorities.
DTSP · FSA · SFC
Equivalent positioning under Singapore's MAS DTSP regime, Japan's FSA VASP registration, and Hong Kong's SFC VASP regime is documented and available on request.

Ready to evaluate?

Join the waitlist for early access, or request the technical documentation to review the architecture on your own schedule.

Signatorie — Non-custodial wallet infrastructure