MPC Wallet Development: Distributed Key Management

We develop multi-party computation wallets for distributed key management without a single point of failure. Traditional crypto wallets hold a private key in one place: a device, HSM, or cloud. Any compromise means loss of funds. Multi-Party Computation solves this fundamentally: the private key never exists entirely in any system. Instead, multiple parties hold key shares and jointly compute a signature without revealing their shares to each other.

This is not multisig. In multisig, a transaction signature requires M out of N signatures, each visible on-chain. In MPC, the final signature looks like a normal ECDSA signature of a single key. No on-chain overhead, no protocol changes. This is critical for: lower gas costs (30% less than multisig), privacy (hides key management scheme), and compatibility with any chain or dApp. Over 5 years in blockchain development, we have delivered 30+ projects, including MPC wallets for leading DeFi protocols.

MPC wallets are 1.43 times more gas-efficient than multisig, saving $300 per month for a protocol processing 10,000 transactions at $0.10 each.

How MPC Wallet Mathematics Work

Shamir's Secret Sharing and Threshold Schemes

MPC wallets rely on threshold signature schemes (TSS). The most used are GG18, GG20 (Gennaro-Goldfeder), CGGMP (Canetti-Gennaro-Goldfeder-Makriyannis-Peled), and DKLS.

Shamir's Secret Sharing is a basic concept, not TSS itself. In SSS, a secret is split into N shares; M of N suffice for reconstruction. Problem: reconstruction requires assembling shares in one place – a vulnerability. TSS eliminates this: the signature is computed without reconstructing the key.

Threshold ECDSA (we use secp256k1 as in Bitcoin/Ethereum):

Let the private key d = d1 + d2 (mod q) for a 2-of-2 scheme. Each party holds d1 and d2. During signing:

1. Each party generates its own nonce: k1, k2
2. Jointly compute R = (k1 + k2)^(-1) * G (commitment protocol)
3. Each party computes its part of s: s1, s2
4. Final signature: s = s1 + s2 (mod q)
5. Signature (r, s) – a normal ECDSA signature

The complexity is in step 2: direct computation would require revealing k1 or k2. Therefore, we use Oblivious Transfer, Paillier encryption, or Curve25519-based protocols for secure computation.

Protocols: GG20 vs CGGMP

GG20 – long the de facto standard. Used in Fireblocks, ZenGo, Coinbase Wallet. Supports threshold t-of-n for arbitrary t and n. Requires Paillier encryption for secure multiplication. Drawbacks: complex implementation, expensive keygen (O(n²) communication), vulnerability to rogue key attack requiring range proofs that increase message size. GG20 requires 15 communication rounds for signing.

CGGMP – current state-of-the-art. Fixes GG20 vulnerabilities, more efficient signing (3 rounds instead of 15). Supports identifiable abort – if a party misbehaves, it can be identified with cryptographic proof.

DKLS – an alternative based on Oblivious Transfer. More compact messages, but fewer production implementations.

Key Refresh

A critical operation: periodic update of key shares without changing the public key (hence no address change). If an attacker compromises one share but hasn't obtained a final signature before refresh, the compromise is neutralized.

Refresh protocol (simplified):
1. Each party generates new random shares: r1, r2, ...rn
2. Sum: Σri = 0 (zero net change)
3. Each party adds its ri to its current di
4. Public key d*G unchanged: Σ(di + ri)*G = d*G + Σri*G = d*G

Recommended refresh frequency: every 30–90 days, or upon suspicion of compromise of any participant.

Production MPC Wallet Architecture

Typical 2-of-3 Scheme for a Mobile Wallet

┌──────────────────────────────────────────────────────┐
│  User Device (Mobile)   │  Company Server  │  Backup  │
│  Share 1 (locally,      │  Share 2         │  Share 3 │
│  encrypted with biometrics) │ (HSM/TEE)       │  (MPC    │
│                         │                  │  backup) │
└──────────────────────────────────────────────────────┘

Signing: Device + Server (2-of-3)
Recovery: Device + Backup or Server + Backup

User loses phone → recovery via Server + Backup shares. Server hacked → no access without Device or Backup. This is the model used by ZenGo and similar non-custodial MPC wallets.

System Components

• Key generation service. Implements Distributed Key Generation (DKG) protocol among participants. Result: each participant receives its share (32 bytes), no one knows the full key. Implementations: tss-lib (Binance, Go), multi-party-ecdsa (ZenGo, Rust), threshold-sig-lib (Fireblocks internal).

// ZenGo's curv + tss-lib example (Rust)
use curv::elliptic::curves::{Secp256k1, Point, Scalar};
use multi_party_ecdsa::protocols::multi_party_ecdsa::gg_2020::party_i::*;

// Phase 1: each party generates commitment
let party1_keys = Keys::create(1);
let (commit1, decom1) = party1_keys.phase1_broadcast_phase3_proof_of_correct_key();

// Phase 2: exchange commitments, compute VSS
// Phase 3-5: verification and finalize shares
// Result: party1_keys.u_i – private share of party 1

• Signing service. Orchestrates signing sessions between participants. Must support: concurrent sessions (multiple transactions in parallel), timeout handling (if a participant does not respond), session IDs for message correlation.

• Communication layer. Encrypted P2P channel between participants. TLS + additional end-to-end encryption of protocol messages. Unencrypted channels cannot be used: intermediate messages contain partial values that could leak shares if accumulated.

• HSM/TEE integration. Server share stored in HSM (AWS CloudHSM, Thales) or TEE (Intel SGX, ARM TrustZone). Critical: share operations execute inside the secure environment; the share never leaves that memory. Azure Key Vault Managed HSM and AWS CloudHSM support custom key operations via PKCS#11 interface.

Recovery Protocol

A crucial UX aspect: how the user recovers access without a seed phrase.

• Social recovery with MPC. Backup share encrypted with keys of trusted guardians. Recovery requires consent from M of N guardians. Implementation: backup share encrypted via threshold encryption for the guardian set. A guardian can be: another user device, an email service (via KMS), a trusted friend (via their public key), or a recovery service.

• KMS-based backup. Backup share encrypted with a user KMS key. Recovery: pass KYC/authentication via KMS provider → decrypt backup share → perform re-sharing with a new device share.

Multi-Chain Support: Multi-Curve MPC

Different blockchains use different elliptic curves:

TSS for ed25519 differs from secp256k1: it uses a Schnorr signature-based scheme (FROST – Flexible Round-Optimized Schnorr Threshold). FROST is simpler to implement and more communication-efficient (3 rounds, same as CGGMP). For a production multi-chain wallet, both must be supported.

Hierarchical Deterministic (HD) in the MPC context. Classic BIP32 cannot be applied directly: there is no single seed. Solution: threshold BIP32 – each party stores its share for the master private key; child key derivation is performed via MPC operations or by storing separate shares for each derived path (less efficient but simpler).

Security and Audit Recommendations

Attack Vectors

• Malicious party in signing protocol. A participant may try to learn about others' shares through anomalous messages. Defense: range proofs, zero-knowledge proofs of correctness for each intermediate value. CGGMP is specifically designed with identifiable abort: the protocol can prove which party misbehaved.

• Replay attack on signing sessions. Intercepted messages from one signing session must not be usable in another. Defense: session ID included in every message; sessions are one-time.

• Side-channel via timing. Implementations in Java/Python are vulnerable to timing attacks on big-number operations. Production implementations must use constant-time arithmetic (library ct-codecs, Rust subtle crate).

• Compromised communication channel. TLS with certificate pinning plus additional authenticated encryption at the protocol level (each MPC message signed with the sender's long-term key).

Audit Recommendations

MPC protocol is cryptographically complex. Auditing must include:

• Verify correctness of the specific protocol (GG20/CGGMP) implementation against the paper
• Side-channel resistance analysis
• Fuzz testing of signing sessions with anomalous messages
• Verifiable key generation (public key matches expected)

Audit providers for MPC: NCC Group, Kudelski Security, specialized in cryptographic implementations.

Gennaro & Goldfeder show that threshold ECDSA is possible without reconstructing the full key, which forms the basis of production MPC wallets.

Compared to multisig, MPC wallets reduce gas costs by 30% and lower on-chain interaction complexity. The final signature is indistinguishable from a regular ECDSA signature, making MPC ideal for private DeFi solutions.

Ready Libraries vs Custom Implementation

Our recommendation: for most projects, integrate with Web3Auth MPC Core Kit or Fireblocks MPC SDK rather than writing from scratch. Custom MPC protocol implementation requires deep expertise in applied cryptography and takes 6–12 months. An error in MPC implementation = potential leakage of user private keys.

What's Included in Our Work

• Architecture documentation with protocol selection, share storage scheme, and recovery model.
• Core MPC implementation: keygen, signing, key refresh based on a proven library.
• HSM/TEE integration for the server key share.
• Multi-chain support: ECDSA, EdDSA, HD derivation.
• Recovery flow implementation: social recovery or KMS-based backup.
• Cryptographic audit by partners (NCC Group, Kudelski Security).
• SDK for mobile and web applications.
• Post-release support and monitoring.

We also provide training for the client's team on secure MPC wallet usage.

Development Stages

A minimal production-ready MPC wallet (2-of-2, one chain, basic recovery) takes 4–5 months. A full-featured multi-chain wallet with social recovery and HSM takes 8–12 months. Typical project cost ranges from $150,000 to $400,000 depending on complexity.

Contact us to discuss your project. Get a consultation on an MPC solution for your DeFi protocol or crypto application.

We develop crypto wallets turnkey — from custodial solutions for fintech to smart contract accounts on EIP-4337. 5+ years in blockchain development, 40+ projects implemented. Let's examine which architecture to choose for your task and why MPC or Account Abstraction solve the private key problem that MetaMask and classic HD wallets could not close.

Why are classic wallets dangerous for business?

A seed phrase in a browser extension is the only way to restore access. For retail users, this is a barrier to entry (lost phrase = lost money). For corporate treasuries, it is incompatible with compliance (KYC/AML, role model, multisignature). Any single key leak compromises all funds. These risks are built into the architecture, not poor UX.

We eliminate them at the protocol level: MPC wallets (key never fully assembled), smart contract wallets (authorization logic in code), hardware HSM for institutional storage. Details below.

What is the real difference between custodial and non-custodial?

Custodial — the provider stores the private key. User authenticates via email/password/OAuth. Recovery is trivial, KYC/AML built-in. For centralized financial applications, often the only regulatory acceptable option. Risk: single point of failure (e.g., Bitfinex hack — $72M, FTX — $600M+ client funds).

Non-custodial — keys are with the user. Provider has no access to funds. Storage responsibility falls on the user. For 99% of people, this model is unworkable without additional protection — hence MPC.

MPC wallets: the key that doesn't exist

Multi-Party Computation (MPC) is a cryptographic protocol that allows multiple parties to jointly sign a transaction without revealing their partial secrets. The private key never exists in its assembled form.

Standard scheme: 2-of-3 MPC between user (share on device), provider server, and backup cloud storage. Transaction is signed by any two of three parties. Lost phone — recovery via server + cloud. Server compromised — attacker holds only one share, signing impossible.

TSS (Threshold Signature Scheme) is a concrete implementation of MPC for ECDSA/EdDSA. Algorithms: GG18, GG20, CGGMP21 (the latter is faster and has better security proofs). Libraries: tss-lib (Go, from Binance), multi-party-sig (Go, from Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC requires no on-chain changes — to the blockchain, the signature looks like a normal single-key signature. This saves gas and keeps the key management scheme confidential (not published in chain) — unlike multisig.

Account Abstraction (EIP-4337): smart contract as wallet

EIP-4337 completely changes the model: instead of EOA (Externally Owned Account), a smart contract Account is used. Authorization logic is in contract code, not in protocol cryptography. This opens up arbitrary signing logic, social recovery, session keys, sponsored transactions, and batch operations.

How the EIP-4337 stack works:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — a new type of object (not an L1 transaction). Bundler collects UserOps from an alternative mempool, packs them into one transaction, and sends to EntryPoint. EntryPoint calls validateUserOp on the Account contract — Account decides if the signature is valid.

Practical capabilities:

Social recovery. The contract stores a list of guardians (other addresses or a service). Lost key — guardians vote for replacement. Argent has used this scheme since 2020.

Session keys. A temporary key with limited rights: interaction only with a specific contract, until a certain date, up to a certain amount. For GameFi and dApps — user does not sign every micro-transaction.

Paymaster. A third-party contract pays gas for the user. Onboarding pattern: user does not hold ETH, gas is sponsored by dApp or taken from ERC-20 tokens.

Implementations: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). EntryPoint v0.6/v0.7 is deployed and active on Ethereum mainnet, Polygon, Arbitrum, Optimism. We guarantee compatibility with the latest contract versions.

What is a Hardware Security Module for corporate wallets?

For treasuries and institutional storage: HSM (Hardware Security Module). The key is generated and never leaves the secure chip. Signing happens inside the HSM. Hardware attestation is supported. Solutions used: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (for small volumes). Integration via PKCS#11 or cloud-specific API.

A combination of HSM + MPC is optimal for institutional use: key shares are stored in HSMs on different servers/jurisdictions, signing via TSS. This ensures compliance with regulatory requirements (e.g., for crypto custodians).

Integration with dApps: WalletConnect and standards

Any wallet must be able to interact with dApps. Standard: WalletConnect v2 (Sign API): QR code or deep link, peer-to-peer encrypted channel via relay server. For browser extensions: EIP-1193 (Ethereum Provider API).

On the frontend, we use wagmi + viem — one interface for MetaMask, WalletConnect, Coinbase Wallet, injected providers. For Account Abstraction: EIP-5792 (wallet capabilities) and EIP-7677 (paymaster service).

Development process

1. Threat model — who is the user (B2C, B2B, institutional), what operations, what is the acceptable risk model. Architecture depends on this.
2. Selection and design of key storage scheme — MPC, HSM, multisig, or a combination.
3. Development of Account contract (if EIP-4337) or integration of MPC library.
4. Backend — MPC coordination, session management, paymaster service (if needed).
5. Mobile/browser application — UI with WalletConnect integration, biometrics, QR.
6. Integration with dApps — EIP-1193, WalletConnect v2.
7. Audit of contracts and cryptographic implementations — mandatory step. MPC libraries have known vulnerabilities (GG18 susceptible to attack with malicious participant without abort protocol). We use libraries with up-to-date security reviews (CGGMP21). Experience passing audits with Certik, Hacken, Trail of Bits — we have certificates.

What is included in the work (deliverables)

• Source code of smart contracts (Solidity/Rust) with documentation
• Backend MPC coordination service (Go or Rust) with API
• Mobile application (iOS/Android) or browser extension
• Integration with WalletConnect, Ledger/Trezor (if required)
• Preparation for security audit (vulnerability report)
• Administrator and user documentation
• Access to repository, CI/CD, monitoring (Tenderly, Etherscan API)
• Training of your team (2-3 sessions)
• Post-launch support — 1 month

Timeline and cost

Cost is calculated individually for your project. We will estimate within one day — contact us by email or Telegram. We provide a guarantee on code and timeline.

Typical mistakes in crypto wallet development (and how to avoid them)

• Using outdated MPC libraries — GG18 without abort protocol. Choose CGGMP21 or tss-lib with up-to-date audit reports.
• Tight coupling to a single blockchain — not abstracting for L2/sidechains. Use viem/wagmi for cross-chain.
• Ignoring MEV attacks — when using multisig without timelocks. Add tx simulation (Tenderly) and sandwiching protection.
• Lack of fallback recovery mechanism — for Account Abstraction, not setting up social recovery. Include from the first release.

We eliminate these pitfalls at the design stage — for each project, we create a threat model and security checklist.

Need a reliable wallet with no compromises? Get a consultation from our architect — we will analyze your task and propose an architecture with a precise estimate. Leave a request — we will respond within a day.