Progressive Custody: Wallet Designs That Graduate Users from Custodial to Self-Sovereign

Most people who try a self-custodial Bitcoin wallet for the first time never complete onboarding. Industry data consistently shows that 60 to 90 percent of new users abandon the process, with the seed phrase backup step responsible for the largest single drop-off. A 2026 Oobit survey of 1,000 U.S. crypto holders found that 35 percent had lost access to a wallet or account, and only 43 percent could correctly identify what a seed phrase looks like.

Progressive custody is a design philosophy that addresses this problem directly: start users with a simple, familiar experience where the app manages keys on their behalf, then gradually introduce self-custody features as users gain confidence and accumulate value. Rather than forcing a binary choice between custodial convenience and self-sovereign responsibility, progressive custody treats the transition as a spectrum.

Why the Binary Custody Model Fails

The traditional wallet landscape presents users with a stark choice. Custodial wallets (exchanges, hosted accounts) offer familiar login flows but require trusting a third party with funds. Self-custodial wallets provide true ownership but demand that users manage cryptographic keys from day one. This binary framing creates a well-documented UX gap that keeps the majority of users on custodial platforms indefinitely.

The numbers reveal an uncomfortable truth: the security properties that make self-custody valuable are the same properties that prevent most people from using it. Progressive custody resolves this tension by decoupling the user experience from the underlying key architecture.

How Progressive Custody Works

A progressive custody wallet moves users through distinct phases, each adding more user control while preserving the option to remain at any level. The core insight is that custody responsibility should scale with user competence and asset value, not be imposed all at once.

Phase 1: Managed Keys

New users sign up with familiar methods: email, phone number, social login, or passkeys. The wallet generates cryptographic keys behind the scenes, either holding them in a custodial arrangement or splitting them across multiple parties using multi-party computation (MPC). From the user's perspective, there is no seed phrase, no backup ritual, no unfamiliar terminology. The experience feels identical to signing up for a banking app.

Phase 2: Key Awareness

As users become active (making transactions, growing balances), the app introduces key concepts incrementally. This might include: viewing a recovery key, enabling biometric authentication for transaction signing, or learning about backup options. The wallet nudges rather than demands, and users can dismiss these prompts without losing functionality.

Phase 3: Shared Custody

Users who engage with key awareness features can transition to a cooperative custody model. Here, the user holds one key while the service provider holds another, and both are required to sign transactions. This is the model that multisig wallets like Muun and BitKey use by default, where the user has meaningful control but retains a safety net.

Phase 4: Full Self-Sovereignty

Advanced users can export their keys, remove the service provider from the signing flow, or migrate to a hardware wallet setup. At this stage, the user has complete, unilateral control: no third party can move, freeze, or censor their funds.

The key principle: Users should never be forced to downgrade security to get a better experience, or sacrifice usability to get real ownership. Progressive custody lets both improve together.

Implementation Models in Practice

Several wallets have implemented versions of progressive custody, each making different tradeoffs between usability, decentralization, and the speed of the custody graduation path.

Muun: 2-of-2 Multisig with Deferred Export

Muun implements a 2-of-2 multisig model where one key lives on the user's device and the other is encrypted on Muun's servers. During onboarding, users only set a PIN code: no seed phrase, no backup complexity. The app creates the minimum cryptographic material needed to start transacting.

The progressive element comes through Muun's Emergency Kit. When users are ready (typically prompted after accumulating a meaningful balance), they can export a PDF containing both encrypted private keys and output descriptors. This Emergency Kit, combined with a recovery code written on paper, gives users full self-custody: they can recover funds using Muun's open-source recovery tool without any server dependency. The wallet defers the complexity of key management until the user opts into it.

Casa: Tiered Multisig Vaults

Casa takes a more explicit tiered approach, mapping custody complexity directly to asset value. New users start with a single mobile key for small balances. As holdings grow, Casa guides them through upgrades: first to a 2-of-3 multisig vault (user holds two keys across separate devices, Casa holds one recovery key), then to a 3-of-5 configuration that distributes keys across hardware wallets in separate physical locations.

Casa's Wealth Security Protocol formalizes this progression: the single-key tier handles balances under $1,000, the Standard plan (2-of-3, $250/year) covers up to $75,000, and the Premium plan (3-of-5, $2,100/year) is designed for holdings above $100,000. Each tier graduation adds more keys, more geographic distribution, and more recovery options.

BitKey: Hardware-Backed Simplicity

Block's BitKey uses a 2-of-3 multisig architecture with three key holders: the user's phone (mobile key), a hardware device (secured by fingerprint), and Block's server (recovery key). No seed phrase exists anywhere in the system. Users authenticate transactions by tapping the hardware device against their phone over NFC.

BitKey's progressive element is subtle: for small, everyday transactions, the mobile key and server key can co-sign without the hardware device. Larger transfers require the hardware key, adding friction proportional to risk. The user never manages raw key material, but the 2-of-3 structure means Block cannot unilaterally access funds. Recovery works through secure cloud backups rather than paper seeds.

Fedi: Community Custody via Federated Mints

Fedi introduces a distinct model: community custody. Built on the Fedimint protocol, Fedi lets communities form federations where a group of trusted guardians collectively manage Bitcoin using threshold signatures. No single guardian can access or move funds: a quorum (for example, 3-of-5 guardians) is required for any operation.

For end users, the experience is simple: join a community, deposit Bitcoin, and transact using e-cash tokens within the federation. There are no seed phrases, no key management decisions, and no hardware requirements. Users trust their community's guardians rather than a single corporation. The progressive path here is social: users start by trusting a federation, then can withdraw to personal self-custody on Layer 1 whenever they choose.

ZenGo: MPC with Biometric Recovery

ZenGo eliminates seed phrases entirely through MPC (multi-party computation). The wallet creates two cryptographic key shares: one stored on the user's device, one on ZenGo's servers. Both shares must participate to sign any transaction, but neither party ever possesses the complete private key. Recovery uses biometric authentication (face scan) rather than a written backup.

ZenGo represents the MPC approach to progressive custody: the onboarding is as simple as a custodial wallet, but the key-splitting architecture provides meaningful security guarantees from day one. In April 2026, eToro acquired ZenGo for approximately $70 million, signaling institutional confidence in the seedless wallet model.

Comparing Progressive Custody Approaches

Each implementation makes different tradeoffs between onboarding simplicity, the degree of trust required, and how quickly users can reach full self-sovereignty.

The Technical Building Blocks

Progressive custody relies on a small set of cryptographic and architectural primitives. Understanding these helps clarify what each implementation actually provides.

Multi-Party Computation (MPC)

MPC protocols allow multiple parties to jointly compute a function (in this case, a digital signature) without any party revealing its private input to the others. For wallets, this means the private key never exists as a single entity: it is split into shares at creation and reconstructed only mathematically during signing. If one share is compromised, the attacker cannot sign transactions. MPC enables seedless wallets because there is no single seed to back up.

Threshold Signatures

Threshold signature schemes like FROST generalize multisig by allowing any t-of-n participants to produce a valid signature. Unlike on-chain multisig (which reveals the signing structure in the transaction), threshold signatures produce a single standard signature. This matters for privacy and fee efficiency: a threshold-signed transaction is indistinguishable from a single-key transaction on the blockchain.

Key Rotation and Export

The “graduation” in progressive custody often involves key rotation: replacing a managed key with a user-controlled one. This can mean exporting encrypted key material (like Muun's Emergency Kit), adding new signing devices to a multisig quorum, or migrating from an MPC arrangement to a standard HD wallet with a user-held seed. The critical requirement is that the transition does not require moving funds to a new address: the user's balance stays intact while the custody model changes underneath.

Social Recovery

Social recovery provides a middle ground between seed phrases and full custodial management. Users designate trusted contacts (guardians) who can collectively help restore access. No single guardian can access funds alone, and the user retains normal spending authority. This model, used in different forms by Fedi and smart contract wallets on Ethereum, adds a recovery safety net without introducing a corporate custodian.

Architecture matters more than labels: A wallet labeled “self-custodial” that uses MPC with a single server co-signer has different trust properties than one using 3-of-5 multisig across geographically distributed hardware. Progressive custody is about making these tradeoffs transparent and letting users move along the spectrum as they choose.

Why Progressive Custody Matters for Bitcoin Adoption

Bitcoin's value proposition depends on self-custody: the ability to hold and transfer value without intermediaries. But this proposition is meaningless if the tools required to exercise it exclude 90 percent of potential users. Progressive custody matters because it makes the self-custody value proposition accessible to people who would otherwise remain on custodial platforms indefinitely.

Reducing Custodial Risk Without Sacrificing Growth

Every user who stays on a custodial platform due to self-custody friction faces custodial risk: exchange hacks, insolvency, regulatory seizure, or account freezes. The collapses of FTX, Celsius, and BlockFi demonstrated that custodial risk is not theoretical. Progressive custody gives these users a practical path out: start where you are comfortable, graduate when you are ready.

Matching Security to Stakes

A user with $50 in Bitcoin does not need the same security posture as one with $500,000. Progressive custody recognizes this: a mobile key is perfectly appropriate for small balances, while large holdings warrant hardware-backed multisig. Forcing the $50 user through a hardware wallet setup is not better security: it is a failed onboarding.

Enabling Non-Technical Communities

Fedi's community custody model demonstrates that progressive custody can work at the community level, not just the individual level. In regions where smartphone penetration is high but technical literacy around cryptography is low, federations provide a culturally appropriate intermediate step. Community members trust people they know (guardians) rather than abstract cryptographic concepts.

Design Patterns for Developers

Building a progressive custody wallet requires deliberate architectural decisions. These patterns have emerged from the implementations above.

Deferred Backup Prompts

Do not ask users to back up keys during initial onboarding. Let them use the wallet first. Trigger backup prompts based on behavioral signals: first deposit above a threshold, repeated usage over a time period, or explicit user request. Muun's approach (PIN-only setup, Emergency Kit deferred) demonstrates that users are far more likely to complete backup when they have assets worth protecting.

Value-Based Friction Scaling

Increase signing requirements as transaction values grow. Small transfers might require only a mobile key. Medium transfers could require biometric confirmation. Large transfers should demand a hardware co-signer or time-delayed approval. BitKey's mobile-only small transactions versus hardware-required large transactions illustrate this pattern.

Non-Destructive Graduation

When users upgrade their custody model, never require them to create a new wallet or transfer funds. The graduation should change the signing policy, not the account. This means designing the underlying key management architecture to support adding, removing, or replacing signers without on-chain migration.

Transparent Trust Indicators

Show users where they are on the custody spectrum. A clear indicator (like a security score or tier label) helps users understand what protections they currently have and what upgrading would provide. This transforms custody from an invisible technical property into a visible user feature.

Building Progressive Custody with Spark

Spark's architecture is well-suited for progressive custody because its wallet SDK separates key management from the user-facing experience. Spark wallets are self-custodial by default, but key management can be abstracted behind any authentication flow: email login, social sign-in, passkeys, or a custom provider.

Developers using the Spark SDK can implement progressive custody by starting users with server-managed key shares and migrating them to user-held keys without switching apps or moving funds. Because Spark operates as an off-chain protocol with cooperative signing, key rotation does not require an on-chain transaction. The user's balance on Spark remains intact while the custody model upgrades underneath.

The SDK is available for TypeScript (Node.js, browser, React Native), with Rust bindings covering Swift, Kotlin, Python, Flutter, and Go. Documentation and integration guides are available at docs.spark.money.

Bread is one example of a Spark-powered wallet that puts progressive custody into practice. Built as an agentic neobank on Bitcoin, Bread offers familiar fintech features (Visa debit card, Cash App and Apple Pay on-ramps, stablecoin yield) while providing self-custodial infrastructure underneath. Users start with an experience indistinguishable from a traditional banking app, backed by Spark's self-custodial wallet SDK.

Challenges and Open Questions

Progressive custody is not a solved problem. Several challenges remain for wallet developers and the broader ecosystem.

Regulatory Ambiguity

Wallets that start custodial and graduate to self-custodial occupy a gray area in regulatory frameworks. Is the wallet provider a money transmitter during the custodial phase? Do KYC/AML obligations change when the user takes full control? Different jurisdictions will answer these questions differently, and the regulatory landscape remains fragmented.

Key Deletion Verification

When a user graduates from managed keys to self-custody, the service provider should delete its key material. But cryptographic deletion is difficult to prove: there is no way for the user to verify that the provider has truly destroyed its key shares. This is a fundamental trust assumption in any MPC or cooperative custody model, and it mirrors the key deletion challenge in statechain protocols.

User Inertia

Progressive custody assumes users will eventually graduate. In practice, many will stay at the most convenient level indefinitely. If 95 percent of users remain in the managed-keys phase, the wallet is functionally custodial for most of its user base. Wallet designers must balance respecting user autonomy (not forcing upgrades) with encouraging security improvements (making graduation easy and obvious).

Interoperability

A user who graduates to self-custody on one wallet should be able to export their keys and use them elsewhere. But MPC key shares, multisig configurations, and proprietary recovery schemes are rarely portable across wallet implementations. Industry standards for custody migration (building on work like output descriptors and PSBTs) would make progressive custody more robust.

The Road Ahead

Progressive custody represents a maturation of Bitcoin wallet design. The early era of Bitcoin wallets assumed technical users who understood public-key cryptography. The exchange era swung to the opposite extreme, abstracting everything behind custodial accounts. Progressive custody finds the middle path: meet users where they are, and give them a clear road to sovereignty.

The wallets that win the next wave of Bitcoin adoption will not be the ones with the most features or the strongest security posture on paper. They will be the ones that make the journey from first download to full self-custody feel natural, gradual, and safe. For developers building in this space, the Spark SDK provides the infrastructure to build that journey, and the embedded wallet pattern shows how to deliver it inside any application.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.