MPC Protocol
This page describes The Vault’s MPC security model at a posture level. The full protocol specifications — DKG rounds, threshold-signing internals, storage sealing, refresh, and recovery cryptography — are part of the security package provided to customers under NDA. For the operator’s guide (how to run a DKG ceremony, refresh shares, or recover a device), see Platform → Keys.
This section describes The Vault’s Multi-Party Computation (MPC) security model: how key shares are generated, stored, used for signing, and refreshed — and what attack scenarios the design protects against.
Cryptographic Protocols
The Vault uses an independently audited threshold cryptography library that implements:
- Threshold ECDSA (secp256k1) for Ethereum, TRON, and Bitcoin (P2WPKH SegWit)
- Distributed Key Generation (DKG) based on a verifiable secret sharing scheme
- Key Share Refresh (proactive secret sharing) for re-sharding without key reconstruction
The protocol is provably secure against a malicious adversary controlling up to t-1 parties.
Threshold Scheme
The Vault uses a configurable k-of-n threshold scheme (default 3-of-4):
| Signer | Environment | Role |
|---|---|---|
| Server Signer 1 | Hardened server-side signing service in a hardware-backed secure environment | Automated server-side signer |
| Server Signer 2 | Hardened server-side signing service in a hardware-backed secure environment | Automated server-side signer |
| Mobile Signer A | Mobile device; share encrypted at rest, encryption key in the OS secure storage | Human-controlled signer (device 1) |
| Mobile Signer B | Mobile device; share encrypted at rest, encryption key in the OS secure storage | Human-controlled signer (device 2) |
Any 3 of the 4 signers can cooperate to produce a valid signature. No single compromised component — nor any pair of compromised components — can produce a signature or reconstruct the private key.
How It Works
- Key generation (DKG). The master key is created by a dealerless Distributed Key Generation ceremony: each signer generates its own share locally, the master public key is computed jointly, and the full private key is never assembled anywhere.
- Threshold signing. To sign, any k of the n signers each compute a partial signature; these are combined into a single standard ECDSA signature. No party ever holds or reconstructs the full key.
- Key share storage. Server-signer shares are sealed inside a hardware-attested TEE (Confidential Computing); mobile-signer shares are stored encrypted at rest in the device’s secure storage. Shares are never persisted, logged, or transmitted in plaintext.
- Refresh & recovery. Shares are periodically refreshed via proactive secret sharing (without changing the master key or any wallet address), and a lost share can be restored to a replacement device through an encrypted backup / recovery flow.
The step-by-step specifications for each of the above — round structures, sealing and attestation details, and the recovery cryptography — are provided to customers under NDA.
Attack Scenarios
| Scenario | Impact | Mitigation |
|---|---|---|
| Server Signer 1 compromised | Attacker has 1 of n shares — cannot sign | Configurable k-of-n threshold (default 3-of-4); requires additional parties |
| Both Server Signers compromised | Attacker has 2 of 4 shares — cannot sign | Still requires 1 mobile signer (human approval) |
| Mobile device stolen | Attacker has 1 of 4 shares — cannot sign | Device blocking (immediate logout + local share wipe); PIN-gated key share |
| Mobile device stolen + SS1 compromised | Attacker has 2 of 4 shares — cannot sign | Still requires 1 more party |
| Database compromised | Attacker has encrypted shares — cannot decrypt without the KMS-managed wrapping key | KMS-wrapped storage; tightly scoped IAM access to the wrapping key |
| API gateway compromised | Attacker can submit transactions — still needs mobile approval | Policy engine and MPC signing layer are independent of the gateway |
| Signing coordinator compromised | Attacker sees partial signatures in flight — cannot combine without k partials | Partial signatures alone are cryptographically worthless |
Because no single party ever holds a full key, forging a signature requires compromising a threshold number of independent signers at the same time. The architecture is designed to make that infeasible: server signers run on isolated, dedicated infrastructure, mobile signers live on separate personal devices, shares are refreshed via proactive secret sharing, and all parties communicate over mutual TLS with no direct signer-to-signer channel.
Cryptographic Parameters
| Parameter | Value |
|---|---|
| Elliptic curve | secp256k1 |
| ECDSA scheme | Threshold ECDSA |
| DKG scheme | Verifiable secret sharing |
| Refresh scheme | Proactive secret sharing |
| Hash function | SHA-256 / Keccak-256 |
| KMS wrapping key | AES-256-GCM (cloud-provider KMS) |
| Mobile share-protection key | Symmetric key that encrypts the share at rest, held in the device’s OS secure storage (iOS Keychain / Android Keystore, hardware-backed where available) |
| Share encryption at rest | Authenticated encryption (AES-256-GCM) with hardware-derived keys |
| TLS version | TLS 1.3 minimum |