MPC Wallet Development Guide: Building a Non-Custodial Wallet in 2026

Introduction

Most crypto losses do not come from broken cryptography. They come from a private key that ended up somewhere it should not be: a screenshot of a seed phrase, a hot wallet server with the key in memory, a signer who approved something they did not understand. In its review of 2024, Chainalysis found that private key compromises accounted for the largest share of stolen crypto, at 43.8%.

That single number explains why MPC wallet development has moved from a niche topic for custodians to a normal question in product planning. If the weak point is one key in one place, the obvious fix is to make sure there is never one key in one place.

Multi-party computation (MPC) does that. The private key is split into shares at creation, the shares sign together without ever being combined, and losing or leaking one share gives an attacker nothing. Done well, it lets you ship a wallet that feels like a normal app (no 24 words on paper, recovery that works when a phone is lost) while the user stays in control of their funds.

Done badly, it gives you a wallet that looks safer than a seed phrase and is not. Several well-known MPC libraries shipped with flaws that let an attacker extract the full key, and the teams using them did not know until researchers published.

This guide is written for founders, exchange operators and product leads deciding whether to build a self-custody or MPC wallet, and how. We are iTech Soft Solutions, an AI and blockchain engineering firm founded in 2016, with a team in Malaysia and a development office in Khulna, Bangladesh. We built NexVault, a non-custodial MPC wallet, and much of what follows comes from that work. Where we cite research, standards or regulation, we link to the original so you can check it.

What You'll Learn

• What "non-custodial" means in practice, and why it is about control rather than technology
• How seed phrase, multisig, MPC and smart-account wallets differ, with a side-by-side comparison
• How threshold signatures work: distributed key generation, signing rounds, key refresh and resharing
• The difference between threshold ECDSA and threshold Schnorr/EdDSA (FROST), and why it matters for chain support
• A reference architecture for an MPC wallet, from the device to the co-signer, policy engine and chains
• The real attacks on MPC wallets (BitForge, TSSHOCK) and how to defend against that class of bug
• How time-locked, cancellable social recovery works
• The UX features users now expect: gas in any token, transaction simulation, phishing screening, limit orders
• How regulators in the EU and Dubai look at custody, and where non-custodial MPC wallets usually sit
• Build vs buy vs white-label, realistic phases and team, common mistakes, and how to choose a partner

What a Non-Custodial Wallet Actually Is

A wallet does not hold coins. Coins live on the blockchain. A wallet holds the ability to authorise their movement, which in nearly every chain means producing a valid signature for a given public key.

So the question "custodial or non-custodial?" comes down to one thing: who can produce that signature?

In a custodial wallet, the provider can. The exchange or custodian holds the keys (or enough key material to sign) and moves funds on the user's behalf. The user has a claim against the provider, not direct control of the assets. That is how most centralised exchanges work, and it is a legitimate model, but it makes the provider a regulated custodian in most jurisdictions and a target for attackers.

In a non-custodial wallet, only the user can authorise a transfer. The provider may run servers, relay transactions, show balances and even hold a piece of the key, but it cannot move funds on its own.

This is where people get confused about MPC. An MPC wallet can be custodial or non-custodial depending on how the shares are distributed and who must take part in signing:

• If the provider holds enough shares to sign without the user (for example, two of three shares on provider servers), the provider has control. That is custody, whatever the marketing says.
• If signing always requires a share that only the user's device can use, and the provider's share can only join a signature the user started, the provider cannot move funds alone. That is non-custodial.

Keep this test in mind through the rest of the guide. Every design decision, from where shares live to how recovery works, either preserves it or quietly breaks it.

Why founders build non-custodial wallets

The reasons we hear most often from clients:

• Exchanges want a self-custody option. Users increasingly want to withdraw to a wallet they control, and an exchange that offers its own branded wallet keeps those users in its ecosystem.
• DeFi and trading products need a wallet layer. A DEX, a launchpad or a trading bot needs a place for users to hold funds and sign. Sending them to a third-party wallet means losing the experience and the relationship.
• Regulatory scope. A wallet where the provider never controls user funds is usually treated differently from a custodian. That can make the difference between a product you can launch this year and one that waits on a custody licence.
• Security posture. If you never hold user keys, a breach of your servers cannot drain user wallets. That is a better place to be than defending a honeypot.

Seed Phrase vs Multisig vs MPC vs Smart-Account Wallets

There are four common ways to hold and use a crypto key today. They are not mutually exclusive (you can combine them), but each has a different shape of risk.

Seed phrase wallets (single key)

This is the classic model used by most browser and mobile wallets. The wallet generates random entropy, encodes it as a BIP-39 mnemonic of 12 to 24 words drawn from a 2,048-word list, and derives a seed from it. From that seed, BIP-32 hierarchical deterministic derivation produces a tree of keys, so one backup restores every account.

It is simple and works on every chain. It also puts the whole burden on the user. Anyone who sees the phrase owns the funds. Anyone who loses it, and the device, loses the funds. There is no second factor, no policy, and no way to undo a mistake.

BIP-32 also carries a lesser-known trap that matters for wallet engineers: holding a parent extended public key together with any one non-hardened child private key is equivalent to holding the parent private key. Wallets that hand out xpubs to servers for balance tracking need to use hardened derivation at the account level.

Multisig wallets

A multisig wallet is an on-chain account that needs M of N independent signatures. On Ethereum and EVM chains, the best-known implementation is Safe. In Safe's own description, a Safe has a list of owners and a threshold of them must confirm a transaction before it executes; modules and guards can add or restrict behaviour.

Multisig is well understood and transparent. Each owner holds a normal key, and the chain enforces the threshold. The downsides: it is a smart contract, so it must be deployed on every chain you use and its behaviour differs between chains; the owners and threshold are visible on-chain; every signature costs gas to verify; and on chains without smart contracts (or with different multisig formats) you need a separate design.

MPC wallets

An MPC wallet uses threshold signatures (often called TSS). The key is generated as shares across several parties, and any threshold of them, for example two of three, can jointly compute a signature. The output is one ordinary signature for one ordinary public key.

To the blockchain, an MPC wallet looks exactly like a single-key wallet. No contract, no extra gas, and the same scheme works across every chain that uses the same curve. The threshold logic lives off-chain in the cryptographic protocol, which is its strength (portable, private, cheap) and its main risk (the protocol and its implementation must be correct, and that is hard to verify).

Smart-account wallets (account abstraction)

A smart account is a contract wallet whose code defines what a valid authorisation is. ERC-4337 made this practical without changing Ethereum's consensus rules: users submit UserOperation objects to a separate mempool, bundlers package them, a singleton EntryPoint contract validates and executes them, and paymasters can pay gas on the user's behalf, including in ERC-20 tokens.

EIP-7702 went further. It adds a transaction type that lets an ordinary externally owned account (EOA) delegate to contract code, which enables batching, gas sponsorship and restricted sub-keys for existing addresses. It went live on Ethereum mainnet with the Pectra upgrade on 7 May 2025.

Smart accounts give you programmable rules: spending limits, session keys, recovery guardians, batched approvals. The risks move into contract code, and with EIP-7702, into delegation signatures. The EIP's own security section warns that wallets should not offer a generic interface for signing delegation authorisations, because there is no safe way to do so. A user tricked into delegating their EOA to a malicious contract has handed over the account.

The comparison

In practice, the strongest consumer wallets in 2026 combine approaches: an MPC key (so there is no seed phrase and no single point of failure) that controls an account with EIP-7702 or ERC-4337 features (so users get gas sponsorship and batching). That is the design we chose for NexVault.

How MPC and Threshold Signatures Work

You do not need to implement the maths to make good product decisions, but you do need to understand the moving parts. Most security failures in MPC wallets happen at the boundary between the cryptography and the product around it.

Distributed key generation (DKG)

In a well-designed MPC wallet, the key is never created in one place. Instead, the parties (say the user's device, the provider's co-signer server and a recovery component) run a distributed key generation protocol.

Each party contributes randomness. At the end, each holds a secret share, and together they agree on one public key, which becomes the wallet address. No party, and no coordinator, ever sees the full private key.

The alternative is a trusted dealer: one machine generates the key and splits it. That is simpler, and some standards (including FROST, below) describe it, but it means the full key existed for a moment on one machine. For a non-custodial product, prefer DKG. If you use a dealer anywhere, for example in a migration, it must run on the user's own device and the key must be erased immediately.

Threshold signing rounds

When the user wants to send a transaction, a threshold of parties runs a signing protocol. Each party uses its share to produce a partial result, they exchange messages over several rounds, and the final output is one standard signature.

The history of threshold ECDSA is a history of reducing those rounds and tightening security:

• Gennaro and Goldfeder's 2018 protocol, usually called GG18 (ePrint 2019/114), showed fast multiparty threshold ECDSA for any threshold, with key generation that needs no trusted dealer.
• Their 2020 follow-up, GG20 (One Round Threshold ECDSA with Identifiable Abort), added identifiable abort, so a party that misbehaves can be identified, and a non-interactive online phase.
• Canetti, Gennaro, Goldfeder, Makriyannis and Peled's CGGMP21 (UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts) proved security in the universal composability framework, supports a preprocessing stage so only the final round needs the message, includes periodic key refresh, and keeps identifiable abort.

Two features from this lineage matter for product design.

Presigning. Most of the work can be done before the user knows what they want to sign. That makes signing feel instant. It also creates state that must be handled carefully: a presignature must never be used twice, and must be bound to the right key and session.

Identifiable abort. If a signing session fails, you want to know whether it was a network glitch or a party sending bad data. Without identifiable abort, a malicious or buggy party can block signing indefinitely without being caught.

Key refresh (proactive security)

Shares can be refreshed without changing the public key. Each party gets a new share, the old shares become useless, and the wallet address stays the same.

This matters more than it sounds. An attacker who steals one share today and another share in six months cannot combine them if a refresh happened in between. Schedule refreshes regularly, and always after an incident, a device change or a suspected compromise.

Resharing

Resharing is refresh with a change of membership or threshold. You can move from one device to another, add a backup party, or change from 2-of-3 to 3-of-5, all without moving funds or changing the address. This is the mechanism that makes seedless recovery possible.

The 2-of-3 setup and where the shares live

The most common consumer design is 2-of-3:

• Share A, the user's device. Stored in the platform's hardware-backed keystore or secure enclave where available, gated by biometrics or a passkey. On the web, it is encrypted and protected by a passkey or a password-derived key.
• Share B, the co-signer. Held by the provider's service, ideally in an HSM or a confidential computing enclave. It joins signing only when the user starts a session and the transaction passes policy.
• Share C, recovery. Encrypted and stored somewhere independent: user-controlled cloud backup, a hardware key, a trusted contact, or a separate recovery service.

Normal signing uses A and B. If the device is lost, C and B reshare to a new device. If the provider disappears, A and C can still sign and move funds out. That last property is what auditors and regulators will ask about: can the user always exit without you?

Note what the provider holds: one share. One share cannot sign. That is what keeps this design non-custodial.

Threshold ECDSA vs Threshold EdDSA and FROST

Which signature scheme you need depends on which chains you support, and it changes the engineering effort a lot.

ECDSA over secp256k1 is used by Bitcoin (legacy and SegWit) and every EVM chain. ECDSA has a non-linear signing equation, which is why threshold ECDSA needs heavy machinery: Paillier encryption, zero-knowledge range proofs, multiplicative-to-additive conversions. That machinery is where most of the published implementation bugs live.

Schnorr-family signatures, including EdDSA (Ed25519, used by Solana and several other chains) and Bitcoin's Taproot Schnorr, are linear. Threshold versions are much simpler.

The reference here is FROST. In June 2024 the IRTF published RFC 9591, the Flexible Round-Optimized Schnorr Threshold protocol. It defines a two-round signing protocol (commitments, then signature shares, aggregated by a coordinator) and five ciphersuites: Ed25519, ristretto255, Ed448, P-256 and secp256k1. Two details to note before you build on it: the RFC is Informational rather than an Internet Standard, and key generation is out of scope. It describes a trusted-dealer method in an appendix and leaves DKG to the implementer.

Standardisation is moving. NIST's Multi-Party Threshold Cryptography project finalised its call for multi-party threshold schemes (NIST IR 8214C) in January 2026, and it has been running public workshops on submissions through 2026. Until that process produces standards, "which protocol?" remains a judgement call based on peer-reviewed papers, the maturity of the implementation and the quality of its audits.

What this means in practice:

• An EVM-only wallet needs threshold ECDSA on secp256k1. Pick a CGGMP21-class implementation with public audits.
• Adding Solana, or other Ed25519 chains, means a second protocol (FROST or similar), a second set of shares, and a second audit scope.
• Bitcoin Taproot can use Schnorr; legacy Bitcoin addresses use ECDSA.

Every additional curve is another protocol to integrate, test and audit. Scope chains on the basis of what your users actually hold, not what looks good on the landing page.

Architecture of an MPC Wallet

The threshold signature is maybe 10% of the system. The rest is the product and infrastructure around it, and that is where most of your engineering time goes.

Client apps

Users expect a wallet on whichever surface they are using: a web app, a browser extension for dApp connections, and iOS and Android apps. Each holds the device share (Share A) and runs its side of the MPC protocol.

Things to get right:

• Platform key storage. Use the hardware-backed keystore on Android and the Secure Enclave or Keychain on iOS to protect the share or the key that encrypts it. In browsers, there is no equivalent, so the share should be encrypted with a key bound to a passkey (WebAuthn) or a strong user secret.
• Shared core. Write the MPC client and transaction-building logic once (Rust compiled to native and WebAssembly is a common choice) and wrap it per platform. Three independent implementations of a cryptographic protocol is three times the audit surface.
• Clear signing. Show users what they are signing in human terms. For typed messages, EIP-712 gives wallets field names and types to display instead of an opaque hex string, and its domain separator lets the wallet warn about or refuse signatures for the wrong contract or chain.

Share storage and the co-signer

The co-signer is the provider's MPC party. It holds Share B and participates in signing only after checks pass.

• Run it in an HSM or a confidential computing enclave so that operators with server access cannot read the share.
• Authenticate every signing session to the user, with a device-bound key or passkey, not just a session cookie. The co-signer must never be able to start a signature on its own.
• Rate-limit and log every session. A sudden spike in signing requests from one wallet is a signal.
• Plan for the co-signer being down. Users should see a clear status, and the A + C path should let them exit if the outage is long.

Policy engine

Because the co-signer must take part in every normal signature, it is the natural place to enforce policy:

• Per-transaction and daily limits
• Address allowlists with a cool-off period for new entries
• Velocity checks (many transfers in a short window)
• Step-up authentication for large transfers or a new device
• Blocking known malicious contracts and addresses

The user chooses and changes their policy (with a delay for loosening it), and the co-signer enforces it. This is the main security advantage MPC has over a seed phrase: a stolen device alone cannot drain the wallet, because the second share will not sign a transfer that breaks policy.

Transaction simulation and phishing screening

Before the co-signer signs, the wallet should simulate the transaction against current chain state and show the user the result: which tokens leave, which arrive, which approvals are granted and to whom.

The same step screens the destination address, the contract, the token and the dApp domain against threat intelligence. Approval-drain scams, address poisoning (lookalike addresses planted in transaction history) and fake airdrop contracts are all visible at this stage. Signing an unlimited token approval to an unverified contract should be a loud warning, not a default.

Relayer, paymaster and gas abstraction

If users can pay gas in any token, or get gas sponsored, you need a relayer or paymaster service. With ERC-4337, this is a paymaster contract plus a bundler. With EIP-7702, the user's EOA delegates to a contract that can accept a sponsored call and reimburse the sponsor in a token. Either way, the service needs its own float management, pricing oracle and abuse controls.

RPC nodes and indexer

The wallet needs reliable RPC access on every chain to read state, estimate gas, manage nonces and broadcast. It also needs an indexer for balances, token metadata, NFT holdings and transaction history. Use more than one RPC provider per chain with automatic failover, and cache aggressively. A wallet that shows a zero balance during a provider outage generates support tickets and panic.

Back office

Even a non-custodial wallet needs internal tools: support views that show a user's wallet state without exposing anything sensitive, incident controls (pause the co-signer for a chain, raise policy thresholds), metrics on signing latency and failure rates, and audit logs for every co-signer decision.

Security: Known Attacks and How to Defend

MPC wallets have a specific risk profile: the cryptography can be broken in ways that are invisible in normal operation. The protocol still produces valid signatures. Nothing looks wrong. Meanwhile a malicious party is collecting enough information to reconstruct the key.

Two public disclosures in August 2023 made this concrete.

BitForge (Fireblocks, 2023)

On 9 August 2023, Fireblocks published BitForge, a set of zero-day vulnerabilities in widely used MPC implementations affecting more than 15 wallet providers, blockchains and open-source projects.

• In GG18 and GG20 implementations, a missing zero-knowledge proof allowed extraction of the full private key. Depending on the implementation, the attack needed from 16 to as many as a billion signatures.
• In Lindell17 two-party ECDSA implementations, where vendors deviated from the academic specification in how they handled failed signatures, the party finalising the signature could extract the key after about 200 signature requests.

Fireblocks gave vendors a 90-day disclosure window, and several fixed their implementations before publication.

TSSHOCK (Verichains, 2023)

A day later, Verichains presented TSSHOCK at Black Hat USA 2023: new key extraction attacks on threshold ECDSA implementations. The attacks targeted the zero-knowledge proofs inside the protocols, specifically the dlnproof:

• α-shuffle exploited ambiguous encoding when values were concatenated before hashing in the Fiat-Shamir transform, so different inputs could produce the same challenge. It affected tss-lib and its forks, and Taurus's multi-party-sig.
• c-split affected implementations that replaced repeated proof iterations with a single large challenge, which is unsafe in a composite-order group.
• c-guess affected implementations that cut proof iterations; Verichains cites one that reduced them from 128 to 1.

Verichains' recommendations are worth repeating: update to patched versions; after patching, generate new keys and move funds, because an attacker may already have collected key material; do not treat TSS as protection against trusted insiders; and commission rigorous, independent reviews of any cryptographic optimisation before deploying it.

Lessons for your build

These were not obscure research libraries. They were production code used by real wallets and bridges. The common causes were:

1. 1Deviating from the paper. Skipping a proof, reducing iterations "for performance", or handling an error case differently from the specification.
2. 2Ambiguous serialisation. Hashing concatenated values without unambiguous, length-prefixed encoding.
3. 3Abandoned forks. Copying a library, modifying it, and never pulling upstream fixes.

Defences that work:

• Use a maintained, publicly audited implementation of a modern protocol (CGGMP21-class for ECDSA, FROST for Schnorr/EdDSA). Do not write your own unless you have specialist cryptographers on staff, and even then, budget for multiple external audits.
• Do not optimise the cryptography. If a proof looks expensive, it is there for a reason. Any change to protocol parameters needs a written security argument and an external review.
• Track upstream. Subscribe to the library's security advisories, pin versions, and have a process to patch and rotate keys within days.
• Refresh keys regularly. Proactive refresh limits how long collected material stays useful.
• Validate everything. Every message from another party is untrusted input: check group membership, range proofs, and session identifiers, and abort and identify on any failure.
• Separate duties. Engineers who can deploy co-signer code should not also have access to share backups.
• Monitor signing behaviour. Many attacks need hundreds or more signing sessions. An unusual pattern of failed or repeated sessions should alert someone.

Audits

Plan for at least three audit scopes:

• Cryptographic audit of the MPC library and your integration of it, by a firm with published threshold-cryptography work.
• Application and smart contract audit for the wallet apps, co-signer, policy engine and any account-abstraction contracts.
• Infrastructure and penetration testing for the co-signer environment, HSM or enclave configuration, CI/CD and cloud accounts.

Then add a public bug bounty at launch, with rewards large enough to matter to the researchers who found BitForge and TSSHOCK-class bugs.

Recovery and Social Recovery

Recovery is where most wallets either lose users or lose their security model. A seed phrase is a recovery system with no safety net: lose it and the funds are gone; leak it and the funds are gone. MPC lets you do better.

What recovery has to achieve

A good recovery flow gets the legitimate owner back in after a lost or broken device, without:

• giving the provider the ability to take over the wallet,
• giving any single guardian or contact that ability,
• or making it easy for an attacker with a stolen phone or a phished email to trigger.

Time-locked, cancellable recovery

The pattern we recommend, and the one NexVault uses, is a time-locked recovery that the owner can cancel:

1. 1The user installs the wallet on a new device and starts recovery, proving identity with the recovery share or with guardians they chose in advance.
2. 2A waiting period begins. In NexVault this is 48 hours. During it, the new device cannot sign anything.
3. 3Every channel the user has (email, push to the old device if it still works, other linked devices) is notified that recovery has started.
4. 4If the real owner did not start it, they cancel with one action. Nothing changes.
5. 5If no one cancels, the window closes and the shares are reshared to include the new device. The old device's share is invalidated. The address and funds stay the same.

The delay is the security feature. An attacker who has the user's email password and a stolen recovery code still has to get through 48 hours of alerts without the owner noticing. Meanwhile, a genuine user who lost their phone accepts a two-day wait as a reasonable price for getting their wallet back.

Design choices to make

• Who can be a guardian. Friends' wallets, a hardware key, a second device, an email-based factor, or a recovery service. Require more than one where possible.
• Length of the window. Longer is safer and more annoying. 24 to 72 hours covers most designs; consider letting users choose a longer one.
• What happens during the window. Freeze outgoing transfers from the old share set, or not? If the device was stolen, freezing protects funds; if the attacker started the recovery, freezing could be abused for a denial of service. Policy limits plus cancellation are usually enough.
• Provider exit. Document and test how a user recovers if your company is unavailable. Regulators and serious users will ask.

UX Features Users Now Expect

A secure wallet that is hard to use loses to an insecure one that is easy. These are the features that close the gap.

Gas in any token, and sponsored gas

New users arrive with USDT and no ETH, then cannot move their USDT because they have no gas. Account abstraction fixes this. With ERC-4337 paymasters, or an EIP-7702 delegation that lets a relayer pay gas and be reimbursed in a token, the user pays the network fee in the asset they hold. Apps can also sponsor gas for onboarding or for specific actions.

Batching

Approving a token and then swapping it should be one confirmation, not two. EIP-7702 and ERC-4337 both support atomic batches, which also removes the dangerous pattern of leaving an unlimited approval in place after a single swap.

Simulation and plain-language confirmation

Show the outcome of a transaction, not its calldata: "You send 500 USDT, you receive at least 0.16 ETH, and you approve Uniswap to spend exactly 500 USDT." When the simulation shows something the user did not expect (a token leaving that they did not mention, an approval to an unknown contract), stop and say so clearly.

Phishing and address screening

Warn on known drainer contracts, newly deployed contracts, lookalike addresses that match the first and last characters of an address in the user's history, and dApp domains on blocklists. Make the user type or confirm something deliberate to proceed past a high-risk warning.

Limit orders and recurring buys

Trading-oriented wallets increasingly offer order types that used to require an exchange account. Gasless limit orders work by having the user sign an order off-chain; a solver or relayer executes it when the price is reached and pays the gas from the trade. Recurring buys (dollar-cost averaging) use the same idea with a schedule. Both need careful design so the signed order can only execute under the exact terms the user approved, with an expiry and a cancellation path.

Human-readable everything

Address book names, ENS and other naming services, token logos from a curated list rather than whatever the contract claims, and clear network labels. Many losses start with a user sending to the right address on the wrong chain.

Multi-Chain Support

Users hold assets across many chains, and a wallet that covers one is a wallet they will use alongside another one.

On EVM chains, an MPC key gives you one address that works on Ethereum and every compatible network. The engineering work is per chain: RPC providers, indexing, gas estimation, token lists, explorer links, and (for gas abstraction) paymaster or relayer support on each network. Chains also differ in subtle ways: fee markets, finality, reorg depth, and support for EIP-7702 and ERC-4337 infrastructure. Test every feature on every chain; do not assume.

Adding non-EVM chains is a bigger step:

• Bitcoin needs UTXO management, fee estimation, and either threshold ECDSA (for SegWit addresses) or threshold Schnorr (for Taproot), plus PSBT handling.
• Solana and other Ed25519 chains need threshold EdDSA, a different transaction model and different simulation tooling.
• Each new curve means a new DKG, new shares, a new signing protocol and a new audit scope.

Our advice: launch with the EVM chains your users actually hold assets on, make the chain layer pluggable, and add non-EVM chains as a separate, audited phase.

Compliance: Custodial vs Non-Custodial

This section is general information, not legal advice. Talk to counsel in each market you serve.

The regulatory question almost always comes back to the control test from the start of this guide: can the provider move user assets on its own?

European Union (MiCA)

The EU's Markets in Crypto-Assets Regulation, Regulation (EU) 2023/1114, defines custody and administration as the safekeeping or controlling, on behalf of clients, of crypto-assets or of the means of access to them, where applicable in the form of private cryptographic keys. Recital 83 is direct about wallets: "Hardware or software providers of non-custodial wallets should not fall within the scope of this Regulation."

The word that matters is "controlling". An MPC provider that holds enough shares to sign without the user is controlling the means of access. One that holds a single share in a 2-of-3 scheme, and can only join signatures the user authenticates, is in a much stronger position to argue it is not. MPC infrastructure provider Dfns, for example, has published its reasoning from a memo it commissioned on this question, focusing on whether the provider can move assets in the normal course of business. That is one firm's position, not regulatory guidance, but it shows how the analysis runs.

Dubai (VARA)

In Dubai (outside the DIFC), custody is a licensed activity under the Virtual Assets Regulatory Authority. VARA's Custody Services Rulebook sets out what licensed custodians must do: risk-based choice of hot and cold storage, key generation to industry best standards, backups with no single point of access, mnemonic backups split into at least two parts, mitigation of collusion among signers, and a requirement that the VASP "maintain control of each Virtual Asset at all times while providing Custody Services."

Two practical points follow. A white-label wallet that an exchange operates for its users needs a clear answer on whether the exchange or the user controls signing, because that decides whether the custody rulebook applies. And if you are building a custodial product in Dubai, those controls map naturally onto MPC: no single person or machine can sign, and backups are split by design.

Other considerations

• Travel Rule and AML. Even non-custodial wallets connected to a regulated exchange will interact with the exchange's Travel Rule and screening obligations for transfers to and from it.
• Sanctions screening. Many non-custodial wallets screen addresses as a product safety feature, independent of whether they are legally required to.
• App store rules. Apple and Google have their own policies on crypto wallets that differ by country. Check before you commit to a launch date.
• Swaps and fiat on-ramps. Integrating third-party swap aggregators or on-ramps can create obligations of their own, depending on how fees and flows are structured.

Build vs Buy vs White-Label

There are three realistic ways to get an MPC wallet in front of users.

Build in-house if the wallet is your core product, you have (or can hire) people who have shipped threshold cryptography before, and you can fund multiple independent audits. Even then, start from an established audited library rather than implementing the protocol from papers.

Use a wallet-as-a-service provider if you want MPC key management as a component inside a larger app and are comfortable with a per-usage fee and a dependency on that vendor's co-signer. Check carefully whether the vendor's model is custodial in your target markets.

White-label if you are an exchange, a fintech or a DeFi project that needs a branded self-custody wallet quickly, and the wallet supports your users rather than being the whole business. You get a product that has already been through the cryptography, apps and audit phases, and spend your effort on brand, integration with your platform and go-to-market.

For exchanges specifically, a self-custody wallet now sits next to the trading platform rather than replacing it. If you are planning both, our crypto exchange development guide covers the exchange side, and our white-label crypto exchange software buyer's guide covers how to evaluate vendors. The same questions about source code access, audits and support apply to wallet vendors.

This is also a pattern we see with our own exchange clients. Our TradexPro exchange platform, sold through Envato where we are an Elite Author, has 415 sales and a 4.89/5 rating from 149 ratings, and Xoibit has run on our TradiumPro platform for more than 24 months. Operators at that stage are asking how to give their users a self-custody option without sending them to a competitor's wallet.

MPC Wallets in Practice: NexVault

NexVault is the non-custodial DEX wallet we built at iTech. It is a working example of the design choices in this guide.

Key management. NexVault uses 2-of-3 MPC key splitting. The key is never whole: not when it is created, not when a transaction is signed, not during recovery. There is no seed phrase for users to write down or lose.

Safety before signing. Every transaction is simulated before the user signs, and the destination, contract and dApp are screened for phishing. The user sees what will actually happen to their balances, and a warning when something looks wrong.

Recovery. Lost devices are handled with 48-hour cancellable social recovery. The owner is alerted when recovery starts and can stop it at any time during the window.

Gas. Users can pay gas in any token, using EIP-7702, so a wallet holding only stablecoins can still transact.

Trading features. Ghost Orders are gasless limit orders: the user signs the order, and it executes when the price is reached. Autopilot handles recurring buys on a schedule.

Coverage. NexVault supports 7 EVM chains and runs as a web app, a browser extension and mobile apps.

White-label. NexVault is available as a white-label wallet for exchanges that want to offer branded self-custody to their users.

There is no public price list; scope, branding, chains and support terms vary by client, so pricing comes from a conversation with our team.

What we learned building it, briefly:

• The MPC protocol was the smallest part of the work. Simulation, phishing screening, RPC reliability and the recovery flow took far more engineering time.
• Recovery UX decides whether users trust the wallet. The 48-hour window needed careful copy and notifications so it read as protection rather than delay.
• Gas abstraction changed onboarding more than any other single feature. Users who arrive with only stablecoins can act immediately.

Cost and Timeline

We do not publish fixed prices for MPC wallet projects, and you should be wary of anyone who quotes a number before understanding your scope. The ranges are wide because the drivers are real: how many chains and curves, how many platforms, custodial or non-custodial, how much custom UX, and how deep the audits go.

What we can describe is the shape of the work.

Phase 1: Discovery sprint

Define the chains and assets, the custody model and share layout, the threat model, the regulatory position in each target market, the platforms (web, extension, iOS, Android) and the feature set. Output: an architecture document, a prioritised backlog and a fixed quote. At iTech, we quote after this sprint, not before.

Phase 2: Core cryptography

Select and integrate an audited MPC library, implement DKG, signing, presigning, key refresh and resharing, and build the co-signer's secure environment. This phase includes internal review against the protocol specification and tests for every abort path.

Phase 3: Apps and services

Build the client apps, the co-signer service, the policy engine, transaction simulation and phishing screening, the relayer or paymaster for gas abstraction, RPC and indexer integration for each chain, recovery flows and back-office tools. If you use account abstraction, the smart contracts are written and tested here.

Phase 4: Security audits

Independent cryptographic, application, smart contract and infrastructure audits. Findings come back, get fixed and get re-tested. Critical findings can send work back to phases 2 or 3, so build slack into the plan.

Phase 5: Staged launch

Launch with conservative limits, a public bug bounty, monitoring and alerting on signing behaviour, and incident runbooks. Raise limits as you gain confidence.

Team composition

A typical team for a custom build:

• A cryptography engineer (or an external specialist on retainer) for the protocol integration and reviews
• Backend and DevOps engineers for the co-signer, HSM or enclave setup, infrastructure and RPC
• Frontend and mobile engineers for web, extension, iOS and Android
• A smart contract engineer if you use ERC-4337 or EIP-7702 features
• QA and security engineers for testing, fuzzing and internal red-teaming
• A product lead who owns scope, UX and the compliance questions

What changes the timeline

• More curves. Each additional signature scheme adds protocol work and audit scope.
• More platforms. Each additional client app adds build and test time, even with a shared core.
• Custom UX. Trading features, NFTs and dApp browsers each add weeks.
• Audit findings. The single biggest source of schedule variance.
• Licensing. If your design is custodial, licensing can become the critical path.

White-labelling an existing audited wallet skips most of phases 2 and 3, which is why it is usually the fastest route for exchanges. If you are budgeting for a wider platform, our breakdown of the cost to build a crypto exchange in 2026 explains the cost drivers on the exchange side.

Common Mistakes

Calling a custodial design non-custodial. If your servers hold two of three shares, or can sign without the user's authenticated participation, you control the funds. Regulators will look at control, not at the word MPC.

Writing your own threshold ECDSA. The published attacks hit experienced teams who modified or reimplemented protocols. Use maintained, audited code, and do not "optimise" the proofs.

Using a trusted dealer for convenience. Generating the full key on a server and splitting it means the key existed in one place. That defeats the purpose.

Forgetting provider exit. If your company or co-signer goes away, can users still move their funds? If the answer is no, you have built a custodial dependency.

Weak device share protection. A share in plain local storage on a rooted phone, or in browser localStorage without encryption, is one step from compromise. Use hardware-backed storage and passkeys.

Skipping simulation. Most user losses come from signing something malicious, not from key theft. A wallet that signs whatever a dApp asks, even with perfect MPC, still loses user funds.

Instant recovery. Recovery without a delay and a cancel path turns a phished email account into a stolen wallet.

Never refreshing keys. Without refresh, a share leaked two years ago is still useful today.

One RPC provider. When it goes down, your wallet shows zero balances and fails to send. Users assume the worst.

Treating audits as a launch checkbox. Audit the cryptography early, audit again before launch, and keep a bug bounty running afterwards.

Choosing a Development Partner

If you are hiring a team to build or customise an MPC wallet, these questions separate experienced partners from the rest.

Which MPC protocol and library will you use, and why? Expect a specific answer (protocol family, library, version, maintainer) and a reason. "Our own proprietary MPC" without published audits is a warning sign.

Who holds which shares, and can the provider sign without the user? The answer should match the custody posture you need in your markets.

How do you handle security advisories in the library? Look for a documented process: monitoring, patching, key refresh and fund migration if needed.

Show me the recovery flow. Ask to see it on a real device, including what happens when the owner cancels.

What does transaction simulation cover? Which chains, which transaction types, and which threat data sources.

Who audited your previous wallet work, and can we read the reports? Published or shareable audit reports are a strong signal.

What do we own at the end? Source code, deployment scripts, documentation, and the ability to run the co-signer without the vendor.

What happens after launch? Response times for incidents, support for new chains, and how protocol upgrades are handled.

Also check the partner's broader blockchain depth. If your wallet uses ERC-4337 or EIP-7702, the smart contracts matter as much as the MPC, and our smart contract development team works on both sides.

Frequently Asked Questions

What is MPC wallet development? It is the engineering of crypto wallets where the private key is split into shares held by different parties, and a threshold of those shares (for example two of three) jointly produces signatures without the key ever being reassembled. It covers the cryptographic protocol, the client apps, the co-signer service, policy, recovery and chain integrations.

Is an MPC wallet custodial or non-custodial? It depends on the share layout. If the provider holds enough shares to sign without the user, it controls the funds and is effectively custodial. If every signature needs a share only the user can use, and the provider holds just one share, the wallet is non-custodial. Regulators such as those applying MiCA look at control, not at the technology.

What is the difference between MPC and multisig? Multisig uses several independent keys and an on-chain contract that checks M of N signatures, so it is visible on-chain, costs more gas and must be deployed per chain. MPC produces a single ordinary signature from key shares, so it looks like a normal wallet to the chain, works across chains that use the same curve, and keeps the threshold private. MPC's risk is in the off-chain protocol implementation.

Do MPC wallets need a seed phrase? No. Recovery uses a backup share and key resharing rather than a mnemonic. Some products offer an optional exportable backup for users who want one, but the design does not depend on users storing words safely.

Are MPC wallets safe after the BitForge and TSSHOCK disclosures? The disclosed issues were in specific implementations, many of which have been fixed. The lesson is to use maintained, audited libraries of modern protocols, follow the specification exactly, apply patches quickly, rotate keys after patching, and commission independent cryptographic audits.

Can an MPC wallet work with account abstraction? Yes. An MPC key can be the signer for an ERC-4337 smart account or for an EOA that uses EIP-7702 delegation. That combination gives you no seed phrase and no single point of failure, plus gas sponsorship, gas in any token and batched transactions.

Which chains can an MPC wallet support? Any chain whose signature scheme you have a threshold protocol for. Threshold ECDSA on secp256k1 covers Bitcoin and all EVM chains; threshold EdDSA, for example FROST, covers Ed25519 chains such as Solana. Each additional curve adds integration and audit work.

How long does it take to build an MPC wallet? It depends on chains, platforms, features and audit depth. A custom build runs through discovery, core cryptography, apps and integrations, independent audits and a staged launch. White-labelling an audited wallet is usually much faster because the cryptography and app work already exist. iTech gives a fixed estimate after a short discovery sprint.

Can my exchange offer a white-label MPC wallet? Yes. A white-label wallet such as NexVault gives your users branded self-custody on web, browser extension and mobile, while you keep the user relationship. Check the share model against the custody rules in your markets before launch.

Final Thoughts

MPC changes the basic security bargain of a crypto wallet. Instead of one key that must never leak, you have shares that are useless alone, a co-signer that enforces the user's own rules, and recovery that does not depend on a piece of paper.

None of that is automatic. The protocol must be implemented exactly, the shares must be distributed so that the user keeps control, every transaction should be simulated and screened before it is signed, and recovery needs a delay and a cancel button. The teams that get this right treat the cryptography as one component in a larger security system, and they audit all of it.

If you are planning a self-custody wallet for your exchange or product, whether a custom build or a white-label of NexVault, see our wallet development and integration services or contact our team to start with a discovery sprint. We will tell you which route fits your scope, what it will take, and give you a quote you can plan around.