Custodial vs non-custodial vs MPC wallets: how to choose

Custodial, non-custodial, and MPC wallets differ in who holds the keys. Compare control, recovery, risk, and regulation, with product examples for each.

A custodial wallet means a company holds the private keys on the user's behalf. A non-custodial wallet means only the user holds them. An MPC wallet splits signing power into key shares held by several parties, so no single party can move funds alone. The right model depends on who handles recovery and who carries the regulatory risk.

MPC is the confusing one. It's a technique, not a custody model, and an MPC wallet can be custodial or non-custodial depending on who holds the shares. This guide compares all three for product and engineering leads choosing what to build on. For the wider picture of what a wallet integration involves, start with what is crypto wallet integration.

What is the difference between custodial, non-custodial, and MPC wallets?

The difference is who holds the private key, because whoever holds the key controls the funds. A custodial wallet puts the key with a company. A non-custodial wallet puts it with the user. An MPC wallet never assembles the key at all: shares held by different parties cooperate to sign.

A private key is the secret that authorizes transfers from a wallet address. In a non-custodial wallet the user usually backs it up as a recovery phrase, 12 or 24 words defined by the BIP-39 standard. Anyone with the phrase can rebuild the wallet, and anyone without it can't.

MPC, multi-party computation, lets several parties compute one signature together without any of them seeing the full key. NIST's Multi-Party Threshold Cryptography project is working to standardize these threshold schemes. A 2-of-3 MPC wallet, for example, has three shares, and any two can sign.

How does each custody model work?

Each model answers the same three questions differently: who holds the keys, who signs a transaction, and what happens when a user loses access. The answers decide your support load, your security architecture, and your licensing position.

Custodial wallets

  • Who holds the keys: the provider, or your company if you run the wallets yourself.
  • Who signs: the custodian's systems, following instructions from the user's account.
  • Lost access: the user recovers the account with an identity check or password reset, like a bank login. The funds are still there.

Many custodial products don't give each user an on-chain wallet at all. They pool funds in a few omnibus wallets and track each user's balance on an internal ledger. The balance is a claim on the custodian, not an on-chain asset in the user's name.

Non-custodial wallets

  • Who holds the keys: the user, on a phone, browser extension, or hardware device.
  • Who signs: the user, in their wallet app, for every transaction.
  • Lost access: if the recovery phrase is gone, the funds are gone. Nobody can reset it.

Smart-contract wallets soften that last point. With account abstraction, the wallet is a smart contract with programmable rules instead of a single key, and ERC-4337 is the main Ethereum standard for it. A smart account can add recovery guardians, spending limits, or passkey sign-in while the user stays in control.

MPC wallets

  • Who holds the keys: nobody holds a full key. Shares sit on different machines, for example one on the user's device, one on the provider's server, and one in a backup.
  • Who signs: a threshold of shareholders runs a signing protocol together, under policies the operator sets.
  • Lost access: the remaining shares can often generate a replacement share, if the setup allows it.

MPC is different from multisig. A multisig wallet uses several complete keys and an on-chain rule that checks how many signed, so it works differently on each chain. MPC produces one ordinary signature off-chain, so it works on any chain whose signature scheme the provider supports. That detail matters for multi-chain products: Ethereum and Tron use ECDSA signatures, while Solana and Stellar use Ed25519. Ask any MPC provider which schemes it supports.

How do the three models compare?

Custodial wallets win on user experience and lose on counterparty risk and regulatory exposure. Non-custodial wallets are the mirror image. MPC sits in between, and where exactly depends on how the shares are split.

CustodialNon-custodialMPC
Who controls fundsThe provider or your companyThe userWhoever holds a signing threshold of shares
Recovery experienceAccount recovery, like a bank loginRecovery phrase or smart-account guardians; a lost phrase means lost fundsA replacement share from the remaining ones, if the setup allows
Counterparty riskHigh: users depend on the custodian's solvency and securityNone from a provider; the risk is the user's own key handlingLower when no single party holds a threshold alone
Regulatory exposure for your companyHighest: likely money transmission or custody licensingLowest, if you never control user fundsDepends on whether you or your vendor can sign without the user
User experienceEasiest: email and passwordHardest: recovery phrases, gas, signing promptsClose to custodial, often with passkeys or social login
Best fitUsers new to cryptoCrypto-native users and treasury teams with their own key securityBusiness treasuries with approval policies, embedded consumer wallets

When should you choose custodial, non-custodial, or MPC?

Choose custodial when your users should never see a key, non-custodial when they already have wallets, and MPC when a business needs approval policies or consumers need a wallet that recovers like an account. Three scenarios for each:

When custodial fits

  1. A neobank offering dollar balances to users who have never heard of a recovery phrase and expect a "forgot password" link.
  2. A payroll platform that holds a company's funding balance and pays contractors across Latin America from it.
  3. A remittance app where the recipient only ever sees local currency, and the stablecoin is plumbing.

When non-custodial fits

  1. A crypto-native marketplace where sellers already hold USDC in their own wallets and want to be paid there.
  2. A B2B treasury team with hardware wallets or a multisig that wants to pay suppliers without parking funds with a provider.
  3. An app that connects to the user's existing wallet through the standard EIP-1193 provider interface, so the user signs in their own wallet app.

When MPC fits

  1. A company treasury that needs two approvers above a set amount and a full audit trail of who signed.
  2. An embedded consumer wallet with one share on the user's device and one with the provider, so the user stays in control but can recover a lost phone.
  3. A payment service provider running high-volume operational wallets, signing automatically within policies and escalating anything unusual.

What are the regulatory implications of each model?

The custody model changes whether your company holds or transmits value for someone else, and that activity is what most regulators license. The general principles below are not legal advice. Rules vary by jurisdiction, so confirm your setup with counsel.

In the US, FinCEN's 2019 guidance on convertible virtual currency (FIN-2019-G001) looks at four facts: who owns the value, where it is stored, whether the owner interacts with the network directly, and whether the intermediary has total independent control over it. Hosted wallet providers, which receive, store, and transmit value for account holders, are money transmitters. A user of an unhosted wallet buying goods or services for themselves is not.

The same guidance covers the multisig case directly. A provider that only adds a second authorization key to the owner's key is not a money transmitter. A provider that also hosts the wallet, keeps the value on its own books, or has total independent control over the value is one, "regardless of the label" it uses. That test maps onto MPC: if your company holds enough shares to sign without the user, you likely look like a hosted wallet provider, whatever the marketing says.

In the EU, the Markets in Crypto-Assets Regulation (Regulation (EU) 2023/1114) lists custody and administration of crypto-assets on behalf of clients as a crypto-asset service that needs authorization. Article 75 adds duties for custodians, including a custody policy, a register of each client's positions, and segregation of client assets. MiCA stablecoin rules explained and the stablecoin regulation tracker cover the other markets.

How does custody affect cross-border payments?

Custody decides who holds the money while a payment waits, and who absorbs the damage when something breaks. Cross-border payments wait a lot: bank cut-offs, compliance reviews, returns from the receiving bank. The longer a provider holds funds, the more its own risks become yours.

In a custodial flow, you deposit stablecoins with the provider first, and they sit on its ledger until you pay out. If the provider becomes insolvent, loses its bank, or freezes withdrawals, that balance is stuck. In a non-custodial flow, the stablecoins stay in your wallet, and the provider pulls only the quoted amount when a payout executes. Your exposure shrinks to the length of the payout itself.

This is where BlindPay's design choice shows. BlindPay, registered with FinCEN as a money services business, never holds the keys to a customer's external blockchain wallet. For a payout, the customer authorizes only the quoted amount: an ERC-20 approve on EVM chains, a signed transaction on Stellar, or a token delegation on Solana. BlindPay then collects that amount, converts it, and sends local currency.

Two honest limits. During the payout itself, BlindPay does control the funds for the minutes it takes to convert and send them. And a payout that ends refunded returns the stablecoins to the wallet that funded it, while one that ends failed doesn't refund automatically and needs support (payout statuses). For teams that don't want to sign each payout, BlindPay's managed wallets, in beta, are custodial by design. Non-custodial payments explained covers the provider side of this question in more depth.

Can you switch custody models later?

You can, but it's a migration project, not a setting. Keys and key shares rarely move between providers, so switching usually means new addresses and an on-chain transfer of every balance. Five things to know before you commit:

  1. MPC shares are protocol-specific. Shares generated by one provider's protocol usually can't be imported into another provider's system. Ask whether the provider offers a key export that reconstructs a full private key, and under what conditions.
  2. New custody means new addresses. Every deposit instruction, allowlist entry, and counterparty record changes. Customers who send to an old address after the migration become support tickets.
  3. Moving balances costs gas and needs reconciliation. Plan the transfers chain by chain, with a check that every balance arrived.
  4. Smart accounts are the exception. An ERC-4337 account can rotate its signers without changing its address, so a move from a provider-held signer to a user-held passkey can keep the same address.
  5. Negotiate the exit before launch. Put key export, address export, and transaction history export in the contract while you still have negotiating power.

What to do next

Pick the custody model per flow, not per company. A consumer balance, a company treasury, and a payout flow can each use a different model, and most mature products end up with two.

Then write down, for each flow, who can sign without the user. That one answer tells you your recovery design, your security review scope, and the first question to bring to counsel.

FAQ