Skip to main content
WalletSuite signing runs through MPC 2-of-2 DKLS23. WalletSuite holds one key share, the customer holds the other, and both are required for every signature. No full private key is ever assembled anywhere.

​
MPC 2-of-2

PropertyDetail
SchemeDKLS23 threshold ECDSA
Quorum2-of-2 - both shares required to produce a signature
Share custodyWalletSuite holds one share; customer holds the other
Full-key assemblyNever - no party ever holds a complete private key
Neither WalletSuite nor the customer can sign alone.

​
Share Storage

LayerDetail
WalletSuite-side shareHSM-backed; KMS envelope encryption at rest
Internal accessM-of-N quorum gated; audit-logged on every co-signing event
Share rotationPeriodic; transparent to the customer (no key-material reissue)
Customer-side shareStored on customer infrastructure, encrypted at rest with the WALLETSUITE_PASSPHRASE secret
The customer-side share never reaches WalletSuite infrastructure, and the WalletSuite-side share never reaches the customer.

​
Signing Flow

When a surface (MCP, SDK, or REST API) requests a signature:
  1. The surface prepares the unsigned transaction with no key access.
  2. The signing layer evaluates policy before any signature is produced.
  3. The customer share signs.
  4. The WalletSuite-side share signs only after policy approval, and never sees the customer share.
  5. The combined threshold signature is returned to the surface.
The surface receives only the signature, never key material.

​
What WalletSuite Never Sees

Applies to all surfaces (MCP, SDK, REST API):
SecretWhere It LivesWalletSuite Access
Full private keysNever assembledNever
Customer-side MPC shareCustomer infrastructure, encrypted at rest (WALLETSUITE_PASSPHRASE)Never reaches WalletSuite infrastructure
The surface (MCP/SDK/REST) requests a co-signature; the WalletSuite-side share signs only after policy approval and never sees the customer share.