Bitcoin Passkey and Seedless Wallets: MPC vs Smart Account Approaches

Seedless Wallet Landscape

Seed phrases remain the most common backup mechanism for self-custodial wallets, but they are also the leading cause of fund loss. Users forget them, store them insecurely, or lose them in disasters. Seedless wallets eliminate this single point of failure by distributing key material across multiple parties or devices using cryptographic techniques like MPC, threshold signatures, and trusted execution environments.

The tradeoff is straightforward: seedless designs replace one trust assumption (that you can safeguard 12 or 24 words indefinitely) with another (that the distributed system managing your key shares will remain available and honest). The right choice depends on which trust model you prefer.

The following table compares six seedless wallet solutions across their key management architecture, recovery mechanisms, passkey support, chain coverage, and custody guarantees.

Key Management Models Explained

Every seedless wallet must answer the same question: if no single seed phrase exists, where does the signing authority live? Three dominant approaches have emerged, each with distinct trust properties.

MPC (Multi-Party Computation)

MPC wallets split the private key into two or more shares held by different parties. Signing requires threshold cooperation: the shares combine cryptographically to produce a valid signature without ever reconstructing the full key in one location. Zengo uses a 2-of-2 model (user device + Zengo server). Capsule/Para uses a similar 2-of-2 split where one share is protected by the user's passkey. Web3Auth creates three shares distributed across the user's device, their social login provider, and Web3Auth's infrastructure.

The primary advantage is that no single party can sign alone. The primary risk is that the MPC server must be available to co-sign transactions. If the provider goes offline or shuts down, users need a recovery path. For a deeper comparison of MPC versus traditional multisig, see our MPC vs multisig custody analysis.

TEE (Trusted Execution Environment)

TEE-based wallets store key material inside hardware-isolated enclaves (such as AWS Nitro Enclaves or Intel SGX) that prevent even the server operator from accessing raw keys. Privy combines TEEs with Shamir Secret Sharing: the key is split into three shares, and TEE infrastructure protects the signing process. Dynamic (now part of Fireblocks) can layer TEE isolation on top of its TSS-MPC signing.

TEEs offer fast signing (approximately 50ms versus 5-10 seconds for pure MPC) and strong isolation guarantees. The tradeoff is hardware trust: side-channel attacks against Intel SGX have been documented, and TEE security depends on the hardware vendor's integrity. TEE models also centralize key storage in a single infrastructure provider, even if that provider cannot read the key material.

FROST Threshold Signatures

FROST (Flexible Round-Optimized Schnorr Threshold signatures) takes a different approach. Instead of splitting an existing private key, FROST uses distributed key generation to create key shares collaboratively so that the complete private key never exists at any point. A configurable threshold of participants (t-of-n) cooperates to produce a standard Schnorr signature that is indistinguishable from a single-key signature on-chain.

This is the model used by Spark and by General Bread. The user holds one key share while Spark operators collectively hold another via FROST. Within the operator set, a 1-of-n trust model applies: as long as one operator behaves honestly, user funds remain secure. Because FROST produces native Schnorr signatures compatible with Bitcoin's Taproot (BIP-340), on-chain settlements are indistinguishable from ordinary Taproot spends. No smart contract layer is required.

For the full technical breakdown, see our FROST threshold signatures explainer.

FROST vs Script Multisig vs MPC

The choice between FROST, on-chain multisig, and MPC affects privacy, transaction cost, and flexibility. The following table summarizes the key differences.

For Bitcoin specifically, FROST has a structural advantage: it produces native Schnorr signatures that Bitcoin nodes validate without any protocol changes, while preserving the privacy and fee savings of single-signature transactions. Traditional multisig scripts expose the spending policy on-chain and cost significantly more in fees. ECDSA MPC achieves similar on-chain compactness but requires more signing rounds and more complex protocols.

The Passkey Problem for Bitcoin

Passkeys (WebAuthn/FIDO2) offer a familiar authentication experience: Touch ID, Face ID, or Windows Hello instead of passwords or seed phrases. Adoption is accelerating: the FIDO Alliance reports over 15 billion user accounts can now use passkeys, with over 1 billion passkey activations across consumer platforms. Passkey sign-ins succeed 93% of the time versus 63% for passwords, and complete 73% faster.

But passkeys cannot directly sign Bitcoin transactions. The reason is a curve mismatch: passkeys use the NIST P-256 curve (secp256r1), while Bitcoin uses secp256k1. These are mathematically incompatible. Every passkey wallet therefore needs a bridging architecture: either a TEE that holds the actual Bitcoin key and releases signatures after verifying the passkey assertion, an MPC scheme where the passkey protects one key share, or a PRF-based derivation that generates Bitcoin keys on-device from passkey material.

This means the passkey itself is an authentication layer, not the signing key. The security of a passkey wallet depends on what sits behind that authentication layer. For the full analysis, see our Bitcoin passkey wallet authentication research.

Seven Risks of Passkey-Only Wallets

Using passkeys as the sole key management mechanism introduces failure modes that developers and users should understand:

1. Cross-platform lock-in: iCloud passkeys do not sync to Android devices and vice versa, fragmenting access across ecosystems
2. Domain binding: passkeys are locked to the creating domain, preventing wallet portability between applications
3. Recovery delegates custody to Big Tech: compromising an Apple ID or Google account can compromise the wallet
4. No agent or server-side signing: biometric verification is required for every transaction, blocking automated or programmatic use
5. Recovery paradox: backup recovery phrases reintroduce the same seed phrase complexity that passkeys were meant to eliminate
6. Inconsistent sync reliability: documented cases of passkeys being wiped from Apple Keychain after OS updates
7. On-chain verification cost: verifying P-256 signatures on EVM chains costs approximately $25 per transaction on L1 without precompile support (RIP-7212)

These risks explain why most production seedless wallets use passkeys as an authentication layer on top of MPC or threshold signatures rather than as the sole signing mechanism.

Are Passkey Wallets Truly Self-Custodial?

The answer depends on the architecture behind the passkey. Seedless wallets exist on a spectrum of self-custody strength:

• TEE-mediated models: users cannot access raw key material directly. If the provider shuts down, access may be lost. This is the weakest self-custody guarantee
• MPC-based models (passkey as auth): stronger guarantees. Even if the provider is compromised, attackers cannot sign without the user's passkey share. But provider availability is still needed for co-signing
• FROST-based models (Spark): the user holds a genuine key share, and the operator set uses a 1-of-n trust model. No single operator can block or steal funds. Combined with unilateral on-chain exit mechanisms, this provides the strongest seedless self-custody guarantee without smart contract dependencies
• PRF-based derivation: derives Bitcoin keys entirely on-device using the WebAuthn PRF extension. Eliminates server dependency for signing but is the least mature approach

The critical question is whether the user can exit the system unilaterally if the provider disappears. Wallets that support key export (Privy) or on-chain settlement to a user-controlled UTXO (Spark) provide genuine exit paths. Wallets that depend entirely on server co-signing without an exit mechanism are functionally custodial, regardless of how they market themselves.

How Spark Enables Seedless Self-Custody

Spark's approach combines FROST threshold signatures with a distributed operator model to achieve seedless self-custody on Bitcoin without requiring smart contracts or EVM compatibility.

When a user creates a wallet through the Spark SDK (as General Bread does), a FROST distributed key generation ceremony produces key shares for the user and the operator set. The user's share can be gated behind a passkey via standard WebAuthn libraries. The operator set uses FROST internally with a 1-of-n threshold: any single honest operator is sufficient to maintain system integrity.

Signing a transaction requires cooperation between the user's share and the operator group. Neither party can move funds unilaterally. The resulting signature is a standard BIP-340 Schnorr signature that Bitcoin nodes validate natively. On-chain, the transaction looks identical to any other P2TR (Pay-to-Taproot) spend: there is no on-chain evidence of the threshold structure.

This design avoids the dependency on account abstraction or smart contract wallets that EVM-based seedless solutions require. Bitcoin's UTXO model and native Schnorr support make FROST a natural fit for seedless custody without protocol-level changes.

Choosing a Seedless Wallet

The right seedless wallet depends on your chain requirements, trust preferences, and use case:

If you need a consumer-ready mobile wallet for Bitcoin and major chains: Zengo offers the most mature user experience with over 1.5 million users since 2019 and no reported wallet compromises. Its 2-of-2 MPC model is well-tested but requires Zengo's server to co-sign every transaction.

If you are building an app and need an embedded wallet SDK: Web3Auth (now MetaMask Embedded Wallets), Privy (now Stripe), Dynamic (now Fireblocks), and Capsule/Para all provide developer SDKs for integrating seedless wallets. Privy's key export capability is a differentiator for self-custody guarantees. Dynamic's use of FROST for Bitcoin and EdDSA chains reflects a protocol-aware approach to threshold signing. See our wallet SDK comparison for a broader landscape view.

If you want seedless self-custody on Bitcoin without smart contract dependencies: Spark's FROST-based model provides the strongest Bitcoin-native self-custody guarantee among seedless approaches. General Bread demonstrates this in production with passkey-based wallet creation and native stablecoin support including USDC, USDT, and USDB. For more on Bitcoin self-custody approaches, see our self-custody vs custodial guide.

Frequently Asked Questions

What is a seedless Bitcoin wallet?

A seedless Bitcoin wallet eliminates the traditional 12 or 24-word seed phrase by distributing key material across multiple parties or devices using cryptographic techniques like MPC, threshold signatures (FROST), or TEEs. The user authenticates via familiar methods such as biometrics, passkeys, or social logins. The underlying signing key is never held in full by any single party.

Are passkey wallets safe for storing Bitcoin?

Safety depends on what sits behind the passkey. A passkey alone cannot sign Bitcoin transactions due to the curve mismatch between P-256 (passkeys) and secp256k1 (Bitcoin). Passkey wallets that use MPC or FROST threshold signatures to manage the actual signing keys, with the passkey serving as the authentication layer, can provide strong security. Wallets that rely solely on a TEE behind the passkey introduce a single point of failure.

What is the difference between MPC wallets and multisig wallets?

MPC wallets perform signing off-chain: multiple parties cooperate to produce a single standard signature without ever assembling the full private key. Multisig wallets use Bitcoin Script to require multiple independent signatures on-chain. MPC produces smaller, cheaper transactions and reveals no policy information on-chain. Multisig is consensus-enforced by the network and does not depend on any external protocol. See our MPC vs multisig comparison for the full tradeoff analysis.

Can I recover a seedless wallet if the provider shuts down?

It depends on the wallet's architecture. Wallets with key export (Privy) allow you to extract your private key and import it elsewhere. FROST-based systems on Spark support unilateral on-chain settlement to a user-controlled UTXO. Some MPC wallets have dead man's switch recovery mechanisms. However, wallets that depend entirely on server co-signing with no exit path effectively hold your funds in custody, regardless of marketing claims.

How does FROST enable seedless self-custody on Bitcoin?

FROST uses distributed key generation so that the complete private key never exists. A threshold of participants cooperates to produce a standard Schnorr signature that Bitcoin validates natively via Taproot (BIP-340). Unlike EVM smart wallets that require on-chain account abstraction contracts, FROST works at the signature level and produces transactions indistinguishable from regular single-key spends.

Which seedless wallet supports the most blockchains?

Among the solutions compared here, Dynamic (Fireblocks) and Capsule/Para support the widest range of chains, covering EVM, Solana, Bitcoin, Stellar, and additional networks. Web3Auth and Privy also offer broad chain support through their SDK architectures. Zengo supports fewer chains but provides a polished consumer experience. General Bread focuses exclusively on Bitcoin via Spark, prioritizing Bitcoin-native self-custody over multi-chain breadth.

Do seedless wallets work with hardware wallets?

Generally, no. Seedless wallets and hardware signing devices serve different security models. Hardware wallets store a single private key on a dedicated device. Seedless wallets distribute key shares across multiple parties. Some wallet SDKs (like Dynamic) support connecting external hardware wallets alongside their MPC wallets, but the two approaches protect keys through fundamentally different mechanisms.

This tool is for informational purposes only and does not constitute financial advice. Wallet architectures, chain support, and company ownership change frequently. Zengo was acquired by eToro (April 2026), Web3Auth by Consensys (June 2025), Privy by Stripe (June 2025), and Dynamic by Fireblocks (October 2025). Always verify current capabilities directly with each provider before making custody decisions.