How It Works
What is MPC?
Multi-Party Computation (MPC) is a cryptographic technique that allows a group of parties to jointly compute a function — in this case, a digital signature — without any party ever learning the inputs of the others. In the context of a crypto wallet, this means no single participant ever holds a complete private key. The private key never exists as a whole in any one place, not even during signing.
This is fundamentally different from multi-signature schemes (like Bitcoin’s native multisig), where each signer holds a full private key and the chain verifies multiple signatures. In MPC, the blockchain sees a single standard signature, while the security properties come from the off-chain key splitting.
The Vault uses an audited, production-grade threshold ECDSA protocol suitable for institutional use.
Threshold Signing (k-of-n)
The Vault uses a configurable k-of-n threshold scheme: a master key is split into n shares during key generation, and any k of those shares are sufficient to produce a valid signature. Both values are stored per master key, so different wallets within the same deployment can use different threshold configurations.
The threshold is set during the Distributed Key Generation ceremony and recorded alongside the master key. The platform enforces it automatically — there is no way to sign with fewer than k shares.
Default Configuration: 3-of-4
The recommended starting configuration uses four shares and requires three to sign. One share is held by each of four independent signers, each generated locally during DKG:
| Signer | Type | Location | Always Online |
|---|---|---|---|
| Server Signer 1 | Backend service | Your infrastructure | Yes |
| Server Signer 2 | Backend service | Your infrastructure | Yes |
| Mobile Signer A | iOS/Android app | Device of authorised approver | No |
| Mobile Signer B | iOS/Android app | Device of authorised approver | No |
With this setup, the two always-online server signers plus at least one mobile signer must participate. This means:
- No transaction can be signed without a human confirming signing on a registered mobile signer device. (This holds for any wallet with enrolled mobile signers — the signing quorum always reserves a mobile signer slot. The exception is a deliberately-created server-only wallet.)
- If one server signer is temporarily unavailable, signing can still proceed with both mobile signers.
- Compromise of a single server signer alone is insufficient to sign any transaction.
Other Configurations
Because k and n are configurable, organisations can tailor the scheme to their operational requirements:
| Configuration | Use Case |
|---|---|
| 2-of-3 | Smaller teams where availability is prioritised over redundancy. |
| 3-of-5 | Higher redundancy — two signers can be offline simultaneously. |
| 5-of-5 | Maximum control — every signer must participate. |
The only constraint is that k must be at least 2 (a threshold of 1 would defeat the purpose of MPC) and k ≤ n.
Signing Flow
At a conceptual level, every transaction goes through four stages:
The signing stage is where MPC happens. The threshold scheme requires k of n parties to cooperate — server signers participate automatically, while mobile signers receive a push notification and require explicit human approval, authorised with the app PIN on the paired device:
The full private key never exists at any point — only the final signature is reconstructed, and only the blockchain ever sees it.
Key Share Generation (Distributed Key Generation)
When a new master key is created, the MPC coordinator runs a Distributed Key Generation (DKG) ceremony:
- All n signers participate simultaneously.
- Each signer generates its key share locally; shares are never transmitted in plaintext.
- The ceremony produces a single master public key and n independent, encrypted key shares. The chosen threshold k is cryptographically bound to the key material at this stage.
- Each signer stores only its own share. No share is ever combined or reconstructable from fewer than k parties.
Individual wallets and blockchain addresses are then derived from this master key without repeating the DKG ceremony (see Child Key Generation below). A single master key can back many wallets across multiple chains.
Child Key Generation
Wallets are created by deriving child keys from the master key using HD derivation (BIP-32 / BIP-44). Generating new wallets and addresses never involves a mobile device, human approval, or the full signing threshold — it is not a signing operation. A wallet’s first child key is computed server-side by the MPC coordinator from the existing key shares; further addresses on an existing account-based wallet (e.g. EVM, TRON) are derived locally from that child key with no MPC interaction at all.
Key Refresh
The key refresh process cryptographically rotates all key shares without changing the master key or any derived wallet addresses. After a refresh, each signer holds a new share that is mathematically unrelated to the old one.
This protects against piecemeal attacks: if an attacker compromises one node at one point in time, the stolen share becomes useless after a refresh. All parties participate in the refresh ceremony.
Recovery
The platform provides a secure key share restoration mechanism based on Publicly Verifiable Encryption (PVE).
If a server fails or a mobile device is lost, the remaining participants can collaboratively reconstruct the missing share on a new device — without revealing their own secret shares at any point. This ensures continuity of signing capability even when a signer is permanently lost.
MPC System Architecture
The MPC layer consists of three core components:
| Component | Role |
|---|---|
| Coordinator | Accepts requests from the application layer (wallet creation, transaction signing) and orchestrates MPC protocol sessions among the participating nodes. |
| Relay | A secure communication tunnel that enables real-time interaction between nodes. The Relay functions solely as a message router — it cannot see or decrypt the MPC protocol traffic (encrypted end-to-end via Noise Protocol). |
| Signers (Parties) | The nodes that hold encrypted key shares. These can be distributed servers (across different cloud providers or TEE-protected infrastructure) or mobile devices (share encrypted at rest in the device’s secure storage). |
Architecture Diagram
Security Properties
- No single point of key compromise — an attacker must simultaneously control at least k signers.
- Human-in-the-loop — including mobile signers in the party set ensures a human authorises every transaction.
- Key shares are never combined — the full private key never exists in memory anywhere.
- Device binding — each mobile signer is bound to a specific device via an X.509 certificate; the key share cannot be extracted and used on another device.