Crypto Wallet Development: Custody Models, Keys and Signing UX

You want people to hold, send and use digital assets inside your product. That might be a standalone wallet app, a wallet embedded in an existing FinTech or e-commerce product, or a browser extension that connects to decentralized applications. In each case, crypto wallet development starts with one decision that shapes everything after it, architecture and compliance included: who holds the keys.

A well-built wallet generates and stores keys where attackers can’t easily reach them. Users can recover access without filing a support ticket that nobody is able to resolve. Every signature request says in plain language what’s about to happen. And you understand the compliance implications of your custody model before launch, instead of discovering them afterward.

Custodial, non-custodial or MPC

Custodial

You hold the keys for your users, in hardware security modules or through a specialist custody provider. For users the experience feels familiar: password resets work, and your support team can actually help them. In return you carry the heaviest security operations and, in many markets, licensing and identity checks. This model suits exchanges and FinTech products whose users expect an account that works like a bank’s.

Non-custodial

Keys are generated and kept on the user’s device, and only the user can sign. Your custody burden is light. The catch is that a lost backup means lost funds, and nobody can reverse a mistaken transfer. It’s the right model for users who want sole control and accept the responsibility that comes with it.

MPC

Multi-party computation splits signing across separate shares, typically one on the user’s device and one on your servers or a provider’s. The shares cooperate to produce a signature, and the full private key never exists in one place. Users sign in with methods they already know and never see a recovery phrase. The price is complex cryptography and a dependence on a vendor, or on an in-house implementation that has to be independently reviewed.

One test is useful when you read vendor marketing: if your servers can sign without the user, the wallet is functionally custodial, and regulators may see it the same way.

Smart contract accounts built on account abstraction standards like ERC-4337 can sit on top of any of these models. They add programmable rules such as spending limits, guardian-based recovery, batched actions, and fees sponsored by your app. Hybrids are common too, for example a custodial account for newcomers that can later withdraw to self-custody. If all you need is to accept crypto payments, a payment provider may serve you better than a wallet of your own.

Key management and recovery

In self-custody, keys are generated on the device with the operating system’s secure random number generator, usually as a BIP-39 recovery phrase with BIP-32 and BIP-44 derivation for multiple accounts and chains. Neither the iOS Secure Enclave nor the Android Keystore supports secp256k1, the curve Bitcoin and Ethereum use. So the standard pattern is to encrypt the seed with a hardware-backed key that can be used only after biometric or passcode authentication.

Secrets never go into plain storage, logs, analytics, crash reports or the clipboard. Screens that display a recovery phrase block screenshots and screen recording.

Users rarely need recovery, but when they do, they need it urgently. That’s why we design it first. The options are a recovery phrase backup with a verification step; a cloud backup encrypted on the device with a password only the user knows; guardian-based social recovery through a smart account; and MPC share refresh onto a new device, often gated by passkeys. Each one trades convenience against attack surface. Whichever we pick, we write down what happens in every failure case, such as a lost phone, a forgotten password or a compromised email account.

Custodial wallets call for a different discipline. Keys sit in hardware security modules or with a specialist provider, and hot and cold storage are kept apart. Withdrawal policies set limits, allow-lists and delays, and large movements need multiple approvals. Ceremonies for generating and handling keys are documented.

Transaction signing UX

Users lose money on the signing screen, so that’s where most of our design attention goes.

• Show what the transaction will do in plain language, with amount, token and recipient, instead of raw hexadecimal data.
• Simulate it against current chain state before signing and show the expected balance changes.
• Decode EIP-712 messages and flag the dangerous ones, such as permits and unlimited token approvals. Phishing sites favor these because a single signature, with no visible transfer, can let an attacker move a user’s tokens later.
• Guard against address poisoning, where attackers plant lookalike addresses in a user’s history. That means full addresses at confirmation, a highlight on first-time recipients, an address book and human-readable names.
• Estimate fees with sensible speed options, manage nonces, let users speed up or cancel stuck transactions, and make pending, confirmed and failed states obvious.
• Warn about known malicious contracts and phishing domains. For users with large balances, support hardware wallets.

A confusing confirmation dialog is a security flaw rather than a cosmetic one, so we prototype these screens and test them with real users before engineering starts.

Chain support and wallet infrastructure

EVM chains share an address format and a signing scheme, so each additional EVM network is mostly configuration, RPC endpoints, token lists and testing. Non-EVM chains are a different story. Bitcoin with its UTXO model, or Solana with its own account and fee rules, needs separate derivation, signing, fee logic and indexing, which makes each one a new module to build and maintain. Every chain stays a maintenance cost for as long as you support it, so start with the ones your users actually need.

A wallet also leans on backend infrastructure, the same kind of indexing and node work we describe in blockchain development. That means RPC access with failover across providers or your own nodes, an indexer for balances and history, price data, and notifications for incoming transfers. It also means token metadata and filtering for spam tokens, which get airdropped to lure users to scam sites. In a non-custodial design the backend never sees keys, and we build it so that compromising it can’t move funds.

To connect with decentralized applications, we implement WalletConnect and the standard browser provider interfaces, EIP-1193 and EIP-6963. Smart contract accounts and modules follow the same practices as our smart contract development work, independent audits included.

Mobile and web wallet engineering

On mobile we build natively in Swift and Kotlin, or in React Native with native modules for the security-critical parts. Cryptographic primitives come from well-reviewed libraries; we never hand-write them. On top of secure storage, we add app attestation through App Attest and Play Integrity, which lets your servers tell a genuine app from a modified one. We treat jailbreak and root detection as a risk signal, not a guarantee. Apple and Google both have store policies specific to crypto apps, and we check the current versions during discovery. For how we choose between native and cross-platform in general, see our article on mobile app development.

On the web, a browser extension handles keys only in its isolated background context, runs under a strict content security policy, and never exposes secrets to the pages it connects to. Embedded web wallets keep key material on a separate origin. On every platform the dependency tree is an attack surface, and wallet libraries have been targets of supply-chain attacks. We pin versions, review updates and keep the dependency list short.

Security reviews and compliance awareness

Each wallet gets a threat model written for its custody model, and we revisit it whenever the design changes. Before launch, an independent firm reviews the app, the backend and the cryptographic implementation. Smart account contracts, if you have any, get a separate audit. By launch there’s also a bug bounty and an incident plan that covers freezing custodial withdrawals, forcing app updates and notifying users.

Compliance is a question for your lawyers, and none of this is legal advice. We can help you ask the right questions, though. In many jurisdictions, holding or controlling keys for users can make you a regulated virtual asset service provider. That brings licensing, identity verification, anti-money-laundering checks, sanctions screening, and rules for passing sender and recipient information along with transfers. Non-custodial wallets aren’t automatically outside regulation either, particularly once they offer swaps or fiat on-ramps.

We build what your legal team specifies, such as identity verification integrations, address screening, transaction monitoring and reporting exports. The product is designed so those pieces can be added without rebuilding it.

How a crypto wallet development engagement works

Discovery settles the custody model, the chains, the feature set and the threat model, and it ends with a list of compliance questions for your counsel. Designers then prototype the onboarding, backup, recovery and signing screens and test them with users. Engineering works iteratively, with testnet builds you can install along the way, and QA tests across a device matrix and against adversarial signing scenarios. After the independent security review, the launch is gradual, with transaction limits that rise as confidence grows.

A typical team has a business analyst, a product designer, mobile or web engineers, a backend engineer and QA, with external reviewers brought in at agreed points. You’ll get regular demos and written reports, and the code, documentation and runbooks are yours.

Frequently asked questions

Should we build our own wallet or use a wallet SDK?

It depends on how central the wallet is. Embedded-wallet and MPC providers get you to market faster, but you pay in fees, vendor dependence and less control over recovery and UX. If the wallet is your core product, owning it usually pays off. If it’s a supporting feature, an SDK is often the sensible choice.

Can users recover a non-custodial wallet after losing their phone?

Only if they have a backup: a recovery phrase, an encrypted cloud backup, guardians or an MPC backup share. The app should make creating that backup easy and skipping its verification hard.

Which chains should we support first?

The ones your users and their assets are already on. Adding EVM networks later is comparatively cheap. Each non-EVM chain is a project of its own.

Do we need a license to run a wallet?

It depends on your custody model, features and markets, and only a lawyer can answer it. Ask during discovery, since the answer can change the architecture.

Can you add a wallet to our existing app?

Yes. After reviewing your app and backend, we add the wallet as an isolated module with its own security boundary.

Once you know which assets and chains the wallet has to support, send us that list and a few lines about your users, and we’ll come back with a proposed custody model and architecture.