Crypto Wallet Development: Custody Models, Keys and Signing UX

How we build crypto wallets for mobile and web: choosing a custody model, managing keys and recovery, designing safe signing screens and preparing for security review.

Inferne Team 7 min read

A key built from a circle and squares approaching a padlock beside a phone, a wallet designed around who holds the key.

You want people to hold, send and use digital assets inside your product: a standalone wallet app, a wallet embedded in an existing FinTech or e-commerce product, or a browser extension that connects to decentralized applications. Crypto wallet development starts with one decision that shapes everything else, from architecture to compliance: who holds the keys.

Good looks like this: keys are generated and stored where attackers cannot easily reach them, users can recover access without a support ticket nobody can resolve, every signature request explains in plain language what will happen, and the compliance implications of your custody model are understood before launch, not discovered after it.

Custodial, non-custodial or MPC

Custodial

You hold the keys on behalf of users, in hardware security modules or through a specialist custody provider. Users get a familiar experience, with password resets and a support team that can actually help, while you take on the heaviest security operations and, in many markets, licensing and identity checks. This 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, but a lost backup means lost funds, and nobody can reverse a mistaken transfer. This suits users who want sole control and accept the responsibility that comes with it.

MPC

Multi-party computation splits signing between key shares, typically one on the user’s device and one on your servers or a provider’s, which cooperate to produce a signature without the full key ever existing in one place. Users sign in with familiar methods and never see a recovery phrase, at the cost of complex cryptography and dependence on a vendor, or on an in-house implementation that must be independently reviewed.

One test cuts through the marketing: if your servers can sign without the user, the wallet is functionally custodial, and regulators may see it that way too.

Smart contract accounts, built on account abstraction standards such as ERC-4337, can sit on top of any of these models and add programmable rules: spending limits, guardian-based recovery, batched actions and fees sponsored by your app. Hybrids are common, such as a custodial account for newcomers with the option to withdraw to self-custody. And if you only need to accept crypto payments, a payment provider may serve you better than a wallet of your own.

Key management and recovery

For 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. The iOS Secure Enclave and the Android Keystore do not support 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.

Four routes from a lost phone to a new one: a sealed paper backup, an encrypted cloud, guardians and rejoined key shares.

Secrets never touch plain storage, logs, analytics, crash reports or the clipboard, and screens that show a recovery phrase block screenshots and screen recording.

Recovery is the part of a wallet that users need least often and most urgently, so we design it first. The options include a recovery phrase backup with a verification step, an end-to-end encrypted cloud backup protected by 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 trades convenience against attack surface, and we write down what happens in every failure case: lost phone, forgotten password, compromised email account.

Custodial wallets need a different discipline: hardware security modules or a specialist provider, separate hot and cold storage, withdrawal policies with limits, allow-lists, delays and multiple approvals for large movements, and documented key ceremonies.

Transaction signing UX

The signing screen is where users lose money, so it gets the most design attention.

A key meeting a lock beside a phone signing screen that shows the transfer and balance change, a suspicious request flagged.
  • Decoded actions. Show what will happen in plain language, including amount, token and recipient, rather than raw hexadecimal data.
  • Simulation. Run the transaction against current chain state before signing and show the expected balance changes.
  • Typed signatures. Decode EIP-712 messages and flag the dangerous ones, such as permits and unlimited token approvals. Phishing sites favor them because a single signature, with no visible transfer, can let an attacker move a user’s tokens later.
  • Address safety. Defend against address poisoning, in which attackers plant lookalike addresses in a user’s history: show full addresses at confirmation, highlight first-time recipients, and support an address book and human-readable names.
  • Fees and status. Estimate fees with sensible speed options, manage nonces, allow speeding up or canceling stuck transactions, and show pending, confirmed and failed states clearly.
  • Risk signals. Warn about known malicious contracts and phishing domains, and support hardware wallets for users with large balances.

We prototype these screens and test them with real users before engineering starts, because a confusing confirmation dialog is a security flaw, not a cosmetic one.

Chain support and wallet infrastructure

EVM chains share an address format and signing scheme, so each additional EVM network is mostly configuration, RPC endpoints, token lists and testing. Each non-EVM chain, such as Bitcoin with its UTXO model or Solana with its own accounts and fee rules, needs separate derivation, signing, fee logic and indexing, which makes it a new module to build and maintain. Start with the chains your users actually need, since every chain is a permanent maintenance cost.

A wallet also depends on backend infrastructure, the same kind of indexing and node work described in blockchain development: RPC access with failover across providers or your own nodes, an indexer for balances and history, price data, notifications for incoming transfers, token metadata and filtering for spam tokens airdropped to lure users to scam sites. In a non-custodial design the backend never sees keys, and it is built so that compromising it cannot move funds.

For connections to decentralized applications, we implement WalletConnect and the standard browser provider interfaces, EIP-1193 and EIP-6963. Smart contract accounts and modules follow the practices in smart contract development, including independent audits.

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, never hand-written code. Beyond secure storage, we add app attestation through App Attest and Play Integrity so your servers can tell a genuine app from a modified one, and we treat jailbreak and root detection as a risk signal rather than a guarantee. Apple and Google have specific store policies for crypto apps, and we check the current ones during discovery. Our article on mobile app development covers how we choose between native and cross-platform more generally.

On the web, browser extensions keep key handling in the extension’s isolated background context, apply a strict content security policy and never expose secrets to the pages they connect to. Embedded web wallets isolate key material on a separate origin. Everywhere, the dependency tree is an attack surface, and wallet libraries have been targets of supply-chain attacks, so we pin versions, review updates and keep dependencies few.

Security reviews and compliance awareness

Every wallet gets a threat model for its custody model, revisited whenever the design changes. Before launch, an independent firm reviews the app, the backend and the cryptographic implementation, and any smart account contracts are audited separately. A bug bounty and an incident plan, covering how to freeze custodial withdrawals, force app updates and notify users, are in place at launch.

Compliance is a question for your lawyers, and nothing here is legal advice. What we can do is help you ask the right questions. In many jurisdictions, holding or controlling keys for users can make you a regulated virtual asset service provider, which brings licensing, identity verification, anti-money-laundering checks, sanctions screening and rules for passing sender and recipient information along with transfers. Non-custodial wallets are not 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, and we design the product so those pieces can be added without rebuilding it.

How a crypto wallet development engagement works

Discovery settles the custody model, chains, features and threat model, and produces a list of compliance questions for your counsel. Designers prototype onboarding, backup, recovery and signing screens and test them with users. Engineers build in short iterations with testnet builds you can install, while QA tests on a device matrix and against adversarial signing scenarios. After the independent security review, launch is gradual, with transaction limits that rise as confidence grows.

A typical team includes a business analyst, a product designer, mobile or web engineers, a backend engineer and QA, with external reviewers brought in at defined points. You 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?

Embedded-wallet and MPC providers get you to market faster, in exchange for fees, vendor dependence and less control over recovery and UX. If the wallet is your core product, owning it usually pays off; if it is 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, whether a recovery phrase, an encrypted cloud backup, guardians or an MPC backup share. The product’s job is to 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, while each non-EVM chain is a project of its own.

Do we need a license to run a wallet?

That depends on your custody model, features and markets, and only a lawyer can answer it. Raise the question in discovery, because the answer can change the architecture.

Can you add a wallet to our existing app?

Yes. We review your app and backend first, then add the wallet as an isolated module with its own security boundary.

A wallet is only as trustworthy as its weakest recovery path and its least clear signing screen. Tell us about your product, your users and the assets they will hold, and we will propose a custody model and an architecture that fit them.