Beyond Seed Phrases: How Seedless Wallets Are Reinventing Bitcoin Self-Custody

The 12-word seed phrase was supposed to be Bitcoin's great equalizer: a single backup that lets anyone become their own bank. In practice, it has become the single largest source of permanent fund loss in self-custody. Chainalysis estimates that roughly 20% of all mined Bitcoin, between 3 and 4 million BTC, is permanently inaccessible, with lost or mismanaged seed phrases accounting for the majority of those losses. A new generation of seedless wallet designs is tackling this problem head-on, replacing mnemonic backups with cryptographic techniques that distribute key material across multiple parties, devices, or recovery mechanisms.

Three approaches have emerged as frontrunners: multi-party computation (MPC) key sharding, passkey and WebAuthn integration, and social recovery via trusted guardians. Each eliminates the seed phrase, but each introduces its own trust assumptions. Understanding those tradeoffs is essential for wallet developers, protocol designers, and users deciding how to hold their Bitcoin.

Why Seed Phrases Fail

The BIP-39 mnemonic standard encodes a wallet's master secret as a human-readable word list. The design assumes users will write it down accurately, store it securely, and never lose it. Research consistently shows this assumption is flawed.

A 2025 CHI study by Carnegie Mellon researchers surveyed 643 cryptocurrency users and conducted 20 in-depth interviews on seed phrase management. The findings were stark: only 43% of participants could correctly identify a seed phrase when shown an image of one, and many believed they could "reset" their seed phrase if lost, similar to resetting a password. Users routinely stored phrases in plaintext notes apps, shared them with partners without understanding the implications, and struggled to create coherent plans for inheritance.

The data confirms what wallet developers have observed for years: seed phrases impose a security model that conflicts with how most people actually behave. The question is not whether to move beyond seed phrases, but which alternative best preserves the self-custodial guarantees that make Bitcoin valuable in the first place.

The core tension: Seed phrases give users complete sovereignty over their funds, but that sovereignty includes the sovereignty to lose everything. Seedless designs reduce that risk by distributing trust, but distribution always means depending on something beyond yourself.

Approach 1: MPC Key Sharding

Multi-party computation eliminates the seed phrase by ensuring that no complete private key ever exists in a single location. Instead, the key is generated as multiple cryptographic shares through a distributed key generation (DKG) ceremony. Each share is held by a separate party or device, and transaction signing happens through a multi-round protocol where parties compute a valid signature without ever reconstructing the full key.

How MPC signing works

In a typical 2-of-3 MPC configuration, three key shares are created: one on the user's device, one on the wallet provider's server, and one in an encrypted backup (cloud storage or a secondary device). Signing requires any two shares to participate in an interactive protocol that produces a standard ECDSA or Schnorr signature indistinguishable from a single-signer transaction on-chain.

This architecture means the provider alone cannot move funds (they hold only one share), the user alone can initiate transactions (combining their device share with the server share), and if the user loses their device, recovery uses the backup share plus the server share. No seed phrase is involved at any stage.

Leading MPC implementations

Fireblocks operates the largest institutional MPC platform, used by organizations including BNY Mellon, Galaxy, and Revolut across more than 150 blockchains. Their protocol refreshes key shares automatically, reducing the window of exposure if any single share is compromised.

Dfns takes a developer-infrastructure approach, providing MPC wallet APIs where each wallet's key shares are generated independently (not derived from a BIP-39 seed). Developers integrate Dfns without managing any cryptographic material themselves.

On the consumer side, Zengo has served over 2 million users with a fully seedless self-custodial wallet. Zengo uses a 2-of-2 MPC scheme combining a device share with a server share, with recovery handled through biometric-encrypted backup to iCloud or Google Drive. The wallet added native Bitcoin support in December 2025 and was acquired by eToro for approximately $70 million in 2026.

MPC tradeoffs

The primary concern with MPC wallets is infrastructure dependency. If the provider's servers go offline permanently, recovery depends on whether the backup share architecture allows reconstruction without the provider's participation. Well-designed MPC wallets (like Zengo's recovery kit) address this, but users must verify the recovery path before trusting their funds to any MPC wallet.

MPC also carries computational overhead: multi-round signing protocols are slower than single-key signing, and the cryptographic libraries are complex, increasing the audit surface. For Bitcoin specifically, MPC-ECDSA protocols are well-studied but more complex than the newer FROST threshold scheme built on Schnorr signatures, which Taproot enables natively.

Approach 2: Passkey and WebAuthn Integration

Passkeys, the consumer-facing name for WebAuthn discoverable credentials, let users authenticate with biometrics (fingerprint, face scan) or a device PIN instead of passwords. The FIDO Alliance reported 5 billion passkeys in active use globally as of May 2026, with 75% of consumers having enabled a passkey on at least one account. This massive adoption base creates an opportunity for wallet developers to leverage familiar authentication patterns.

From authentication to key derivation

The WebAuthn Level 3 specification includes a Pseudo-Random Function (PRF) extension that opens a path beyond simple authentication. Instead of just proving identity, the PRF extension can output deterministic cryptographic material derived from the passkey. This means a passkey can serve as the root for key derivation: the user's biometric becomes the input, and a wallet key becomes the output, with no seed phrase in between.

When combined with synced passkeys (backed up via iCloud Keychain, Google Password Manager, or a hardware security key), this approach provides cross-device wallet access without any written backup. Lose your phone, and your passkey syncs to your new device through the platform vendor's encrypted backup infrastructure.

Bitcoin wallet implementations

Breez SDK launched passkey login for seedless Bitcoin wallets, using the PRF extension to derive wallet keys directly from WebAuthn credentials. This gives wallet developers building on Breez a path to eliminate seed phrases while retaining self-custody.

Bitkey takes a different approach to passkeys: rather than using WebAuthn for key derivation, Bitkey uses passkeys as one authentication factor within its broader 2-of-3 multisig design, pairing biometric login on the mobile app with its hardware device and server key.

Passkey tradeoffs

Passkey-derived wallets introduce dependency on platform vendors. Apple, Google, and Microsoft control the sync infrastructure that backs up passkeys across devices. If a user is locked out of their platform account, they could lose access to their wallet. Hardware security keys (YubiKey, Titan) avoid this dependency but sacrifice the seamless sync experience.

The PRF extension is also relatively new. Not all browsers and authenticators support it yet, and the security properties of deriving high-value cryptographic keys from WebAuthn credentials are still being evaluated by the research community. For a deeper analysis of how passkeys interact with Bitcoin key management, see our research on passkey wallet authentication.

Approach 3: Social Recovery

Social recovery replaces the seed phrase with a set of trusted contacts (guardians) who can collectively restore wallet access. The wallet owner designates N guardians and sets a threshold M: recovering the wallet requires M of N guardians to approve the recovery request. No single guardian has enough information to access funds independently.

The Argent guardian model

Argent pioneered guardian-based recovery on Ethereum mainnet in 2020 and later migrated its primary product to zkSync Era. By April 2026, Argent had accumulated over 500,000 users, with the guardian recovery system being a significant driver of adoption.

In Argent's model, guardians can be trusted individuals, hardware wallets, or third-party services. A typical configuration might use 3-of-5 guardians: two friends, a hardware wallet, the Argent server, and a third-party recovery service. Recovery initiates a timelock period (typically 48 hours) during which the wallet owner can cancel unauthorized recovery attempts.

Social recovery on Bitcoin

Argent and most social recovery implementations rely on smart contract wallets, which are native to Ethereum and EVM chains but do not exist on Bitcoin's base layer. Bitcoin's Script language lacks the programmability to implement guardian rotation or time-delayed recovery natively.

However, Bitcoin-native approximations exist. Shamir's Secret Sharing (SSS) can split a seed into shares distributed to guardians, though this requires reconstructing the full secret during recovery, which creates a window of vulnerability. More advanced approaches combine multisig with timelocked recovery paths using Miniscript spending policies, enabling guardian-based recovery without reconstructing a single key. For a detailed examination of Bitcoin-specific social recovery patterns, see our social recovery wallet design analysis.

Social recovery tradeoffs

Guardian reliability is the central risk. Guardians must remain reachable, cooperative, and secure over potentially years-long time horizons. Social dynamics change: friends move, relationships end, devices are replaced. Guardian sets need periodic rotation, which adds operational overhead that most users neglect.

Collusion is the adversarial concern. If M guardians conspire, they can initiate an unauthorized recovery. The timelock window mitigates this (the owner can cancel during the delay period), but only if the owner notices in time. This makes social recovery less suitable for long-term cold storage where the owner may not monitor their wallet regularly.

Bitkey: A Case Study in Seedless Design

Block's Bitkey represents the most prominent production implementation of seedless Bitcoin self-custody. Launched in December 2023, Bitkey combines elements of MPC and multisig into a 2-of-3 key architecture specifically designed for non-technical users.

The three keys

Bitkey distributes signing authority across three keys, any two of which can authorize a transaction:

• App key: a hot key stored on the user's mobile device, used for everyday transactions
• Hardware key: stored on Bitkey's NFC-enabled hardware device (the original 2024 model had no screen; the 2026 version adds an OLED touchscreen for on-device transaction verification)
• Server key: held by Block's infrastructure, used only as a co-signer for app-initiated transactions and as a recovery backstop

The user always controls two of the three keys (app plus hardware). Block holds only one, so the company can never unilaterally move funds. For daily spending, the app key plus server key sign together. For high-value transactions, the hardware device is tapped via NFC to provide the second signature.

Recovery without a seed phrase

If the user loses their phone, they use the hardware device plus Block's server key to transfer funds to a new app installation. If the hardware device is lost, the app key plus server key handle recovery. Only if both the phone and hardware device are lost simultaneously does the user need to go through Block's identity verification process to pair a replacement device with the server key.

Bitkey also introduced Bitcoin inheritance in November 2024. Users designate an heir and provide them with an encrypted recovery code. The code alone cannot access funds, but it initiates a claim process with a built-in waiting period, giving the original owner time to cancel if the claim is unauthorized.

Open source with caveats: Bitkey's firmware and app code are open source, which allows independent security audits. The code is licensed under the Commons Clause, which restricts commercial use of the codebase. This transparency is unusual for hardware wallets and helps verify the security claims, though the server-side key management remains a trust dependency on Block.

Comparing Seedless Approaches

Each seedless design makes different tradeoffs between security, recoverability, usability, and trust assumptions. The following table compares the three primary approaches across the dimensions that matter most for Bitcoin holders.

Production Seedless Wallets

The following table summarizes notable seedless wallet implementations that support Bitcoin, highlighting their approach and current status.

The New Trust Surface

Every seedless design replaces one trust assumption (the user will perfectly secure a seed phrase) with a different one. Understanding these new trust surfaces is critical for evaluating whether a seedless wallet actually improves security for a given user.

MPC provider risk

MPC wallets depend on the provider remaining operational. If Fireblocks or Dfns shut down, users need a pre-established recovery path that works without the provider's servers. Zengo addresses this with an open-source recovery kit that can reconstruct the wallet using the device share and the encrypted backup share, but not all MPC providers offer equivalent guarantees. Users should test recovery before depositing significant funds.

Platform vendor risk

Passkey-derived wallets inherit the security properties of the platform that syncs them. If Apple locks a user's iCloud account, their synced passkeys become inaccessible. Hardware security keys avoid this but don't sync across devices. The tradeoff between convenience (synced passkeys) and sovereignty (hardware-only passkeys) mirrors the original seed phrase dilemma in a new form.

Guardian risk

Social recovery systems are only as reliable as the guardian set. Research on Argent's deployments suggests that users who configure guardians at setup rarely update them over time, leading to "guardian rot" where contacts become unreachable. Wallet UX should prompt periodic guardian verification and make rotation frictionless.

Hybrid approaches

The most robust designs combine multiple approaches. Bitkey's 2-of-3 model is effectively a hybrid: the hardware device provides cold storage security, the app key provides convenience, and the server key provides recovery, all without a seed phrase. Future wallet designs may layer passkey authentication on top of MPC key sharding with social recovery as a backup, creating defense in depth against any single point of failure.

Defense in depth matters: The CHI 2025 study found that users who relied on a single backup method (seed phrase written on paper) were significantly more likely to lose access than users with redundant backup strategies. Seedless wallets should offer multiple independent recovery paths to avoid recreating the single-point-of-failure problem in a new form.

What This Means for Wallet Developers

The shift toward seedless custody changes the requirements for wallet development. Developers building on Bitcoin need to choose a key management architecture that balances self-custody guarantees with the usability expectations of mainstream users.

MPC is the most mature option for Bitcoin-native seedless wallets, with production-proven implementations and broad institutional adoption. Passkeys offer the most familiar UX for end users but are still early for Bitcoin key derivation. Social recovery is powerful but best suited to smart-contract platforms unless combined with multisig or Miniscript spending policies on Bitcoin.

Regardless of approach, the seedless trend aligns with a broader movement to reduce friction in self-custodial wallet UX. Users should not need to understand BIP-39 mnemonics or derivation paths to hold their own Bitcoin securely. The wallet should handle key management invisibly, only surfacing decisions when the user's input is genuinely required.

For developers building Bitcoin wallets and payment experiences, Spark's SDK complements the seedless custody trend by handling the payment layer: instant transfers, Lightning compatibility, and stablecoin support without requiring users to manage channels or liquidity. Combined with a seedless key management solution, this creates a self-custodial Bitcoin wallet experience where the only thing the user needs to understand is their balance. Apps like General Bread demonstrate what this looks like in practice: a Spark-powered wallet where sending and receiving Bitcoin is as simple as any fintech app.

For a deeper look at how different key management architectures compare, see our research on MPC vs. multisig custody and the complete guide to Bitcoin wallet recovery methods.

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.