Turnkey MPC Wallet Development for Institutional Custody

We build custodial MPC wallets where the private key never exists in full form on any device. Instead, each party holds a "share" of the key, and transaction signatures are computed jointly via the MPC protocol. Stealing one share is useless—all participants in the scheme are required to sign. This architecture eliminates the single point of failure and makes the wallet resilient to server compromise: even if an attacker gains access to the server share, they cannot sign a transaction without the user's share. Our engineers have 10+ years of blockchain development and cryptography experience, with over 20 successful MPC wallet projects delivered for exchanges and custodians. We guarantee your service will get institutional-level custody without a single point of failure. This is enterprise crypto storage at a new level—a wallet without a seed phrase, where access is restored through a backup share.

This is a fundamental difference from traditional on-chain multisig (M-of-N): multisig is visible on the blockchain, requires N on-chain signatures (gas), and the fact that multisig is used is public. An MPC signature looks like a regular single signature—neither the blockchain nor an observer can see that it resulted from joint computation. Fireblocks, ZenGo, Coinbase WaaS, Web3Auth—all are MPC-based products. The banking and institutional sector is moving to MPC precisely because of the absence of a single point of failure in key storage. Gas savings can reach 50% compared to on-chain multisig; clients typically see a 40-60% reduction in transaction fees.

MPC Wallet Operation

Threshold Signature Scheme (TSS)

For Ethereum (secp256k1), the most common protocol is GG20 (Genaro-Goldfeder 2020) or its improved version CGGMP21. A t-of-n scheme: any t out of n participants can compute a signature; without t, it is impossible. The protocol requires 3 rounds for keygen (each ~200 bytes) and 2 rounds for signing.

The process consists of two phases:

• Keygen (distributed key generation): Participants interactively generate shares without revealing the final key. Upon completion, each has share_i, and the public key P = G * privateKey is known to all. The private key privateKey never exists anywhere.
• Signing: To sign a transaction, t participants run the MPC protocol, each inputs their share_i, and the output is a valid ECDSA signature. No participant learns the keys of others.

Real MPC Libraries

Production-ready implementations:

• tss-lib (Binance): Go library, implements GG18/GG20. Used in Binance Chain, Thorchain. Open source.
• multi-party-ecdsa (ZenGo): Rust, implements GG20. More up-to-date, active support.
• @sodot/sodot-node-sdk: Commercial SDK for MPC-as-a-service. Fast start, no need to implement the protocol yourself. Licensing ~$5,000–$20,000/year.
• Silence Laboratories SDK: Academically verified implementation, used in Web3Auth for MPC as a service.

Implementing the MPC protocol yourself takes months of cryptographer time and carries a high risk of errors. For most projects, the right choice is a ready-made library or MPC-as-a-service.

Choosing an MPC Library

Why MPC Wallet Is Better Than Multisig

MPC is justified for: institutional custody, wallets-as-a-service, seedless wallets (mobile-first), embedded wallets in apps. Gnosis Safe (on-chain multisig) is justified for: DAO treasuries, team wallets, cases where maximum on-chain transparency is needed. MPC wallets are fully compatible with any EVM network, making them ideal for DeFi protocols and wallets-as-a-service. Clients save up to 50% on gas costs and avoid the complexity of multisig.

2-of-2 MPC Wallet Architecture

A typical scheme for a consumer wallet: one share on the user's device, one on the server. A transaction requires participation of both parties.

The server does not know the full key. The device does not know the full key. Without the server, the user cannot sign (protection against device theft). Without the device, the server cannot sign (server cannot steal funds).

Keygen Flow

// Simplified flow illustration (not production-ready code) import { MpcSigner } from '@sodot/sodot-node-sdk'; class MPCWallet { private deviceSdk: MpcSigner; private serverSdk: MpcSigner; async generateKey(): Promise<string> { const keygenId = crypto.randomUUID(); const [deviceShare, serverShare] = await Promise.all([ this.deviceSdk.initKeygen(keygenId, { threshold: 2, parties: 2, partyIndex: 1 }), this.serverSdk.initKeygen(keygenId, { threshold: 2, parties: 2, partyIndex: 2 }), ]); await this.runKeygenRounds(keygenId, deviceShare, serverShare); const publicKey = await this.deviceSdk.getPublicKey(keygenId); const address = ethers.computeAddress('0x' + publicKey); await this.deviceSdk.storeShare(keygenId, deviceShare); await this.serverSdk.storeShare(keygenId, serverShare); return address; } async signTransaction(address: string, transaction: ethers.TransactionRequest): Promise<string> { await this.authenticateUser(); const txHash = ethers.keccak256(ethers.Transaction.from(transaction).unsignedSerialized); const signingId = crypto.randomUUID(); const signature = await this.runSigningProtocol(signingId, txHash, address); const signedTx = ethers.Transaction.from({ ...transaction, signature }); return signedTx.serialized; } } 

Share Refresh (Proactive Security)

Share refresh solves the problem of server share compromise: participants periodically update their shares without changing the final key. A share stolen a year ago is useless today. We recommend weekly refresh.

async function refreshShares(walletId: string): Promise<void> { await Promise.all([ deviceSdk.refreshShare(walletId), serverSdk.refreshShare(walletId), ]); } setInterval(() => { for (const walletId of activeWallets) { refreshShares(walletId).catch(console.error); } }, 7 * 24 * 60 * 60 * 1000); 

Access Recovery on Device Loss

The 2-of-2 scheme has a weakness: if the server is unavailable, the user cannot sign transactions. A 2-of-3 scheme solves this:

• Share 1: user device
• Share 2: server (online signing)
• Share 3: backup (encrypted with user password, stored in the cloud or printed)

Normal operation: Device + Server = signature. If server is unavailable: Device + Backup = signature (emergency recovery). If device is lost: Server + Backup = recovery to a new device.

async function recoverToNewDevice( backupShare: CloudEncryptedShare, backupPassword: string ): Promise<string> { const decryptedBackup = await decryptBackupShare(backupShare, backupPassword); await verifyUserIdentity(); const newDeviceShare = await sdk.refreshWithParties([serverShare, decryptedBackup]); await secureStore.save(newDeviceShare); return 'Recovery complete'; } 

Communication channel between parties: The MPC protocol requires several rounds of message exchange between participants. For 2-of-2 (device + server), WebSocket is optimal—minimal latency. REST polling is simpler but adds 0.5-2.5 seconds to signing. Typical MPC signing time: 0.5-2 seconds with good network conditions. Show progress in the UI.

Server Infrastructure

The server share must be stored in a Hardware Security Module (HSM)—a physical device from which it is impossible to extract the key programmatically. Options: AWS CloudHSM (FIPS 140-2 Level 3), AWS KMS (software), HashiCorp Vault (self-hosted). For a startup, AWS KMS + encryption at rest is sufficient. HSM is for when you grow to institutional clients.

Authentication Before Signing

The server verifies that the sign request was initiated by an authorized user (JWT after biometrics). Additionally, transaction policies are applied: limits, address whitelists, requirement of additional verification for large amounts.

What's Included in the Deliverables

When ordering a custodial MPC wallet solution, you receive the following deliverables:

• Architecture design and MPC protocol selection (t-of-n scheme)
• Integration of MPC library (tss-lib / multi-party-ecdsa / Sodot SDK)
• Implementation of keygen and signing flows with share storage
• Mobile/web application with UX for onboarding, transactions, and recovery
• Server side: auth service, signing API, policy engine, HSM integration
• Security review and pentest (MPC protocol + infrastructure)
• Full documentation: architecture docs, API references, deployment guides
• Source code access via private repository
• Admin and developer training sessions
• Launch support and 6 months of post-launch maintenance

Deliverables include comprehensive documentation, source code access, admin training, and 6 months of technical support.

Work Process

1. Architectural design (1-2 weeks): select MPC protocol, share distribution, backup/recovery flows, server infrastructure.
2. Keygen and signing implementation (3-4 weeks): integrate MPC library, communication channel, share storage.
3. Mobile/web application (2-3 weeks): UX onboarding, transaction flow, progress indicators, recovery UI.
4. Server side (2-3 weeks): auth, signing API, policy engine, HSM integration.
5. Security review (2 weeks): protocol security analysis, pentest, share storage review.
6. Testing and launch (1-2 weeks): end-to-end tests, load testing.

Full MPC wallet cycle: 4-6 months. Development cost starts at $150,000 for a basic 2-of-2 scheme, ranging to $300,000 for a fully customized enterprise solution. This is more complex than a regular wallet due to the MPC protocol and the need for cryptographic expertise. The cost is calculated after detailing the scheme and selecting the MPC library.

We will evaluate your project for free—contact us to discuss the architecture. Also read about Secure multi-party computation for a general understanding of the technology. With over 10 years in blockchain and 20+ projects, we deliver institutional-grade custody. Get a consultation for your project—our engineers will answer technical questions.