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.

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.