Back

Crypto wallet development: custody models, build vs buy, security

Custodial, non-custodial, MPC and smart account wallets compared, when to use an embedded wallet provider, the security failures to design against, and the compliance line that custody draws.

Crypto wallet development: custody models, build vs buy, security

Crypto wallet development starts with one decision: who controls the keys. That choice sets your regulatory status, your security work and most of your budget. If you're adding a wallet to an app (a game, a marketplace, a payments product), use an embedded wallet provider and spend your time on the product. Build your own key management only if the wallet is the product, or if custody is a business you're licensed or planning to be licensed for.

This guide covers the four custody models, the build-versus-buy decision, the security failures that have actually drained wallets, and where the compliance lines sit in the EU and US.

The four wallet models

ModelWho controls keysUser experienceRegulatory weightTypical use
CustodialYou (the company)Email and password; you handle everythingHighest. Custody is a licensed activity in most marketsExchanges, fintech apps, brokerages
Non-custodial (seed phrase)The user, aloneInstall a wallet, back up 12 or 24 wordsLowest, if you never touch keysCrypto-native users, self-custody wallets
MPCKey shares split between parties (user device, provider, sometimes a backup)Login-based, no seed phraseDepends on whether you can sign without the userEmbedded wallets, institutional custody
Smart accountA contract with rules; signers can be passkeys, devices, guardiansPasskey login, gas sponsorship, recoveryDepends on who holds the signersConsumer apps, DAOs and treasuries

"Embedded wallet" isn't a fifth model. It's a delivery method: a wallet created inside your app at sign-up, usually built on MPC, secure enclaves or a smart account, offered by a provider.

Custodial

You hold the keys and maintain an internal ledger of who owns what. Users get a bank-like experience: password reset, support, no gas. You get the full risk. Hot wallet compromise, insider theft, ledger reconciliation errors and licensing all become your problem. Build custodial only when the business model requires it, for example an exchange or a brokerage, and plan for a custody partner or an institutional platform under the hood rather than a homegrown key store.

Non-custodial with a seed phrase

The user's device generates and stores the key. You never see it. This is the lowest regulatory exposure and the worst onboarding: users must back up a phrase, and when they lose it, there is nothing you can do. Consensys, explaining its Web3Auth acquisition, cited data that 35% of users do not back up their seed phrases. Build this kind of wallet only if self-custody is the product.

MPC

Multi-party computation splits signing power so no single party ever holds the full key. A common setup is one share on the user's device, one with the provider and one as a backup, with two of three needed to sign. Users log in with email or social accounts and never see a phrase.

The tradeoff is complexity. Threshold signature protocols are hard to implement correctly. In 2023 Fireblocks researchers disclosed BitForge, a set of flaws in GG18, GG20 and Lindell17 implementations that affected more than 15 wallet providers, blockchains and open-source projects, including Coinbase WaaS and Zengo, which have since fixed them. Don't implement MPC yourself. Buy it from someone whose implementation has been reviewed by cryptographers.

Smart accounts

A smart account is a contract wallet. It can accept passkeys, let your app pay gas, batch actions and support recovery through guardians or a second device. On EVM chains this is account abstraction, and we cover ERC-4337 and EIP-7702 in detail in our account abstraction guide. Smart accounts combine well with MPC or enclave-based signers: the signer handles login, the contract handles rules.

Our default for a consumer app in 2026: an embedded signer (passkey or provider-managed) controlling a smart account, with gas sponsored for the first actions. Our default for a treasury or DAO: a multisig smart account with hardware wallet signers.

Build vs buy

The embedded wallet market consolidated in 2025, and large payment and custody companies now own the main providers:

That consolidation is mostly good news for buyers: these providers are backed by companies with security teams and balance sheets. It also means your wallet layer now depends on a vendor's roadmap and pricing.

FactorBuy (embedded provider)Build
Time to a working walletDays to a few weeks (our planning estimate)Several months before it's safe to hold user funds (our planning estimate)
Key securityProvider's audited stackYour team, your audits, your incident response
Cost structurePer monthly active wallet or per signatureEngineering salaries, audits, infrastructure, on-call
ControlLimited to the provider's chains, auth methods and UIFull
Lock-inReal. Check how keys can be exported or migratedNone, but you own every bug
Regulatory exposureDepends on the provider's custody model; read their docsDepends on your design

Buy when the wallet supports your product. Build when the wallet is your product, when you need a chain or signing scheme no provider supports, or when your custody license requires you to control the stack.

Before you sign with a provider, ask:

  1. Can a user export their key or move to another wallet if you shut down or switch vendors?
  2. Who can sign a transaction without the user? The provider? You? Under what legal process?
  3. Which chains, signing curves and account types are supported, including Solana or non-EVM chains you might add?
  4. What audits and penetration tests have been published, and when?
  5. What happens to users if the provider has an outage?
  6. How is pricing calculated once you have 100,000 monthly active wallets?

The first question matters most. If the honest answer is "no", you've chosen a custodial relationship with extra steps, whatever the marketing says.

Security: how wallets actually get drained

Most wallet losses come from a short list of causes. Design against each.

Weak key generation

A key is only as random as the generator that made it. The Profanity vanity address tool seeded its generator with 32 bits, which let an attacker rebuild private keys by brute force. That was linked to Wintermute's roughly $160 million loss in 2022. In 2023, the "Milk Sad" bug in Libbitcoin Explorer limited bx seed entropy to 32 bits, and affected wallets were drained in the wild. Use the platform's cryptographically secure random source, use well-reviewed libraries for BIP-39 and key derivation, and test your generator's output.

Keys stored badly on the device

On mobile, keep keys or key shares in the Secure Enclave (iOS) or Android Keystore, gated by biometrics. In browsers, assume any extension or injected script can read memory and local storage. Never log keys, mnemonics or signing payloads, and check your crash reporting and analytics SDKs for leaks.

Blind signing and phishing

Users approve what they can't read. Every signing screen should show, in plain language, what the transaction does: tokens in and out, approvals and their limits, the contract being called. Simulate transactions before signing and flag unlimited approvals, setApprovalForAll, permit signatures and unknown contracts. EIP-7702 added a new phishing target: a delegation signature hands an attacker's contract the whole account, and Wintermute found most early 7702 delegations pointed to sweeper contracts. Wallets should only allow delegations to an allowlist of known contracts.

Supply chain and frontend compromise

The largest theft of 2025, Bybit's roughly $1.5 billion, didn't come from broken contracts or keys. Investigators traced it to a compromised Safe{Wallet} developer machine and malicious JavaScript served to the signers. Lock down CI, pin and review dependencies, use subresource integrity where you can, and give high-value signers a second, independent way to verify what they're signing.

MPC and smart account implementation bugs

Covered above: buy MPC from reviewed providers, use audited smart account implementations, and get any custom module or validator audited. Our smart contract audit checklist covers what to prepare.

Recovery that becomes a backdoor

Every recovery mechanism is also an attack path. Email-based recovery inherits email account security. Guardian recovery needs a delay long enough for the real owner to cancel a hostile attempt. Support-desk recovery is a social engineering target. Decide which you offer and test the attack, not only the happy path.

Compliance: custody draws the line

This isn't legal advice, and you need a lawyer for your markets. The general shape:

EU (MiCA). Custody and administration of crypto-assets on behalf of clients is a licensed CASP service, with duties set out in Article 75: client agreements, custody policy, segregation of client assets and liability for losses. Non-custodial tools are outside it. Recital 83 says hardware or software providers of non-custodial wallets should not fall within the scope of the regulation.

EU travel rule. Since December 30, 2024, CASPs sending or receiving transfers over €1,000 to or from a self-hosted address must verify whether that address is owned or controlled by their client. If you build a non-custodial wallet, your users will be asked to prove ownership when they move funds to and from exchanges. Message signing support makes that easier.

US. FinCEN's 2019 guidance treats hosted wallet providers that receive, store and transmit value on users' behalf as money transmitters, and generally doesn't treat unhosted wallet software that way. It also uses a four-factor test centered on who has total independent control over the value. State money transmitter laws are a separate layer.

App stores. Apple's guideline 3.1.5 allows wallet apps only from developers enrolled as an organization, and limits exchange features to regions where you're licensed. Enroll as a company early; switching later delays launches.

The practical test for MPC and embedded wallets: can you, or your provider, move user funds without the user's participation? If yes, regulators are likely to treat it as custody. Write down the answer for your design before you talk to counsel.

What a wallet MVP needs

For an app adding an embedded wallet:

  • Account creation tied to your login, with a passkey or provider-managed signer
  • Balances and history from an indexer, not raw RPC calls on every screen
  • Send and receive with address validation and a readable confirmation screen
  • Transaction simulation and clear warnings for approvals
  • Gas sponsorship for first actions, or stablecoin gas
  • Key export or an exit path to another wallet
  • Recovery that a non-technical user can complete
  • Monitoring and a way to freeze sponsorship if it's being farmed

For a standalone non-custodial wallet, add: multi-chain support, token and NFT discovery, dapp connectivity through WalletConnect and injected providers, hardware wallet support, a swap integration and a security review of the app itself, not only the contracts.

For realistic budgets across these scopes, see our blockchain app development cost breakdown. If you're building an exchange around a wallet, our crypto exchange MVP guide covers the custody and licensing side in more depth.

FAQ

How much does it cost to build a crypto wallet?

It depends mostly on custody model and scope. An embedded wallet from a provider inside an existing app is a matter of weeks of integration work. A standalone multi-chain non-custodial wallet with its own security review is a multi-month project. A custodial platform adds licensing and custody infrastructure on top. These are our planning estimates; get a scoped quote.

Is an MPC wallet custodial or non-custodial?

It depends on who can sign. If the user's share is required for every signature, it behaves like non-custodial. If the provider or the app can sign alone, it's effectively custodial, and regulators may treat it that way.

What is the safest type of crypto wallet for users?

For most consumers, a smart account with a passkey signer and tested recovery, because it removes the seed phrase and supports recovery and spending limits. For large holdings, a hardware wallet or a multisig with hardware signers.

Should I build my own wallet or use Privy, Dynamic or Turnkey?

Use a provider unless the wallet is your core product or you need something no provider supports. Building key management safely takes specialist cryptography and security work that most product teams shouldn't take on for a feature.

Do I need a license to build a crypto wallet?

A purely non-custodial wallet generally doesn't need a custody license under MiCA or count as a money transmitter under FinCEN's 2019 guidance. A custodial wallet usually does. Get legal advice for each market you serve.

If you're deciding between an embedded provider, a smart account stack or your own wallet, we can help you pick the custody model and build the parts that need to be custom. Talk to 23studio about your wallet plans and we'll tell you what we'd build first.

Ready when you are

Let's build something that matters in Web3. Whether you need a prototype next week or a full product launch, we've got the skills to make it happen.

Talk to our team
23stud.ioWe help with what you need - advice, development, team extension, or complete project delivery.
Copyright © 2025 23stud.io. All rights reserved