Picture losing a phone that held a crypto wallet, with no seed phrase ever written down anywhere. If the wallet still recovers, one of three separate models made that possible: MPC, passkeys, or social recovery. MPC splits the private key into shares held by different parties, so no single seed phrase ever exists in the first place. Passkeys rely on a device-bound biometric credential, backed up through a platform account such as Apple or Google. Social recovery works differently again: a set of trusted guardians can authorize a new signer if the original device is gone. This article explains how each model actually works, where each one can fail, and how the three differ from one another.
What “No Seed Phrase” Actually Means for Custody
Where the Seed Phrase Normally Fits
A standard crypto wallet can encode entropy as a human-readable recovery phrase, from which seed material and then one or more accounts and private keys can be derived. That phrase is the backup for everything the wallet can derive from it, and in practice functions as the entire recovery method. Anyone who reads the words can generally reconstruct the same keys and move the funds, and anyone who loses the words with no backup loses access permanently.
What Has to Replace It When the Seed Phrase Is Removed
Once the phrase is gone, something else must answer two questions: what proves ownership day to day, and what restores access after a lost device. MPC answers both with cryptography, splitting the proof into pieces. Passkeys answer the first with a biometric-unlocked credential; whether the second is answered by a platform account backup or by a different provider-specific mechanism depends on the wallet in question. Social recovery mainly answers the second, replacing a backup phrase with people who can approve a replacement key.
MPC (Multi-Party Computation): Splitting the Key So No Seed Phrase Exists
Multi-party computation lets several parties jointly sign a transaction without any single one holding the complete private key. Per Fireblocks’ explanation of MPC, participants each hold private data and jointly compute a signature without revealing what they individually hold, so the private key is never assembled in one place.
How Key Shares Are Created and Combined
When an MPC wallet is set up, several separate computers or devices each generate their own key share at the same time. Those shares mathematically combine to produce one public wallet address, but the shares themselves are never merged or sent to each other. Per the Fireblocks documentation cited above, when a transaction needs to be signed, a quorum of endpoints each independently check it and contribute a share of the signature, and the full private key never exists in one place.
Who Holds a Share, and Why That Matters
The number of parties holding shares, and who those parties are, decides how much trust the setup requires. A share can sit on the holder’s own phone, on a second device, or on a server run by the wallet provider. If the provider holds one of the shares required to sign, funds cannot move without that provider’s system staying online and cooperating. Whether a given MPC wallet counts as self-custodial is not settled by the MPC label itself; it depends on the specific signing threshold, who holds each share, and whether any other party can unilaterally change the signing or recovery policy. A wallet’s own documentation, not the term “MPC,” is what actually confirms this.
Passkeys: Device and Account-Bound Login, Not Key-Sharding
A passkey is a credential built on the WebAuthn standard, stored on a device and unlocked with a fingerprint, face scan, or PIN instead of a typed password. Per the W3C Web Authentication specification, WebAuthn defines an API for public-key credentials that authenticate a user without ever typing or transmitting a password or phrase. WebAuthn itself only covers that authentication step; it does not define how any given wallet turns a passkey into transaction signing, custody, or recovery. A passkey-capable wallet can use WebAuthn as one part of its authentication or signing design, but the wallet’s own documentation, not the WebAuthn standard, is what establishes its specific transaction and recovery route. That still makes a passkey a different mechanism from MPC’s key-splitting, since a passkey does not divide a private key among several parties.
How a Passkey Is Created and Synced
A passkey credential is created by an authenticator and is not presented to the holder as a recovery phrase that can be copied by hand. Per the W3C WebAuthn credential backup state section, WebAuthn supports both device-bound, single-device credentials and multi-device credentials that a platform can back up, for example to a linked Apple ID or Google Account; which type a given wallet uses, and whether it syncs at all, is a choice made by that wallet and its authenticator, not a universal property of passkeys. When a wallet does use a synced, multi-device passkey, a new device signed into the same platform account can use the same passkey, which also ties recovery to that platform account rather than to a written backup.
What Happens When the Device or Linked Account Is Lost
For a wallet using a synced, multi-device passkey, if a device is lost but the linked cloud account is still reachable, a new device signed into that account can retrieve the passkey and regain access. If that linked cloud account is locked out, forgotten, or was never set up to sync, or if the wallet uses a device-bound passkey in the first place, the passkey cannot be recovered from that device alone through the sync path. The specific recovery route in each case, and whether the wallet offers any separate backup path, is set by the wallet’s own documentation, not by WebAuthn or passkeys in general.
Social Recovery: Guardians Instead of a Key Backup
Social recovery replaces a written backup with a set of trusted parties, called guardians, who can jointly authorize a new signing key for a wallet. Per Argent’s official guide to recovering a wallet with guardians, a wallet owner nominates guardians and sets an approval threshold, and enough guardians approving a recovery request installs a replacement key if the original is lost. This model does not split a key the way MPC does or depend on a biometric credential the way a passkey does; it depends on guardians being reachable and willing to approve.
Choosing Guardians and a Recovery Threshold
A recovery threshold states how many guardians, out of the total chosen, must approve before a new key is installed, commonly written as a fraction such as two of three. A higher threshold makes an unauthorized recovery harder to push through, but also means more people must be reachable when a real recovery is needed. Safe’s documentation on smart account modules describes a comparable, configurable setup, where a recovery module can be given delayed authority to replace an owner once guardian approval and a timelock condition set by that module are satisfied.
What the Recovery Window Looks Like in Practice
A social recovery setup may add a mandatory delay between guardian approval and the moment the new key takes effect; whether it does, and how long that delay is, is implementation-specific and set by each wallet’s own configuration rather than a fixed industry norm. Where a delay exists, its purpose is to give the original holder time to notice and cancel a recovery attempt they did not request, in case a guardian’s account has been compromised. A shorter delay makes recovery faster, while a longer delay gives more protection against a fraudulent attempt.
Recovery and Failure Modes Compared
What Can Go Wrong With Each Model
Each model has one dominant point of failure, though the specific trigger depends on how a given wallet is configured. An MPC wallet fails if enough of the required key-share holders become unreachable at once, whether from a provider outage or a lost device. A passkey wallet that relies on platform-account sync fails if that linked account is locked or unreachable alongside the device; a wallet using a device-bound passkey with no separate backup path fails once that device is lost. A social recovery wallet fails if too few guardians can be reached to meet its threshold, or before any configured delay has elapsed.
What Determines Recovery Speed for Each Model
| Model | What is needed to recover | What actually determines recovery speed |
|---|---|---|
| MPC | Enough of the required key-share holders online and cooperating | Implementation-specific: depends on that wallet’s own quorum size and where each share lives |
| Passkey | A synced credential and access to the linked platform account (if the wallet uses sync), or a wallet-specific backup path | Implementation-specific: depends on whether the wallet uses a synced or device-bound passkey, and what backup path it offers |
| Social recovery | Approval from the guardian threshold, plus any delay the wallet configures | Implementation-specific: depends on whether the wallet sets a delay at all, and how long it is |
What the table actually says: MPC and passkey recovery can both be fast when the thing each depends on is still reachable, meaning the signing quorum for MPC or, for a synced passkey, the platform account. How fast, in either case, is set by that specific wallet’s own configuration rather than by MPC or passkeys as categories. Social recovery’s delay, where a wallet includes one, is a deliberate safety feature rather than a limitation, trading speed for protection against a forced recovery. Checking which dependency applies to a specific wallet, and what its documentation says about timing, matters more than assuming any category is inherently fast or slow.
Can These Models Be Combined?
Some wallets layer more than one mechanism rather than picking only one. A wallet might use MPC for everyday signing and add a social recovery guardian set as a backstop in case the MPC quorum becomes unreachable. Combining mechanisms like this stacks two separate systems on top of each other; it is not evidence that MPC, passkeys, and social recovery are interchangeable labels for one feature. Each layer still carries its own point of failure.
Choosing a Recovery Model for a Crypto Wallet
The right model depends on which failure a person is more exposed to personally, not on which model ranks highest in general. Someone more likely to lose a phone than to lose their Apple ID or Google Account may find a passkey wallet’s recovery path workable. Someone who trusts a small group of people, such as family members or a co-founder, more than any single company’s uptime may prefer social recovery’s guardian model. Two wallets both described as “seedless” should never be assumed to use the same mechanism.
Frequently Asked Questions
Is an MPC wallet still self-custodial?
An MPC wallet can be self-custodial when the holder’s own key share is required to reach the signing quorum and no other party can unilaterally change that quorum or its recovery policy; meeting the share requirement alone doesn’t guarantee this. If a provider’s share alone is enough to sign, or the provider can alter the policy unilaterally, the setup functions more like custodial control regardless of how it is marketed. The specific quorum and policy-change rights for that wallet, not the MPC label alone, are what actually answer the question.
What happens to a passkey wallet if the phone is lost and the linked cloud account is also inaccessible?
For a wallet using a synced, multi-device passkey, if both the device and the linked platform account are unreachable, the passkey cannot be recovered through the normal sync path. Some wallets offer a separate backup method for this scenario, but that depends entirely on what the specific provider built. Without a separate backup path, losing both the device and the account can mean permanent loss of access.
How long does social recovery actually take?
Whether a setup adds a security delay after guardians approve a recovery request, and how long that delay is, is set by each wallet’s own configuration rather than a fixed industry number. Where a delay exists, it’s intentional, giving the original holder a window to cancel an unauthorized attempt. Actual speed also depends on how quickly enough guardians can be reached and respond, and on that wallet’s documented process.
Can an MPC wallet provider access funds without the user?
Only if the provider’s key share alone meets the signing quorum, or the provider can unilaterally change the signing or recovery policy, which depends on how a specific wallet is configured. In setups where the holder’s share is required alongside the provider’s, and policy changes need the holder’s approval, the provider cannot act alone. The specific quorum and policy-change rights for any given wallet should be checked directly rather than assumed.
Is a seedless wallet safer than a wallet with a seed phrase?
No single answer applies to every case, since each seedless model shifts the failure point elsewhere, whether to a signing quorum, a platform account, or a guardian group, rather than removing risk entirely. A seed phrase concentrates all risk in one written item, while a seedless model spreads that risk differently depending on the mechanism chosen. Which is safer depends on which failure mode a person is more likely to encounter.
Can a wallet use MPC and social recovery at the same time?
Yes, some wallets layer MPC for everyday signing with a social recovery guardian set as a backup path. This combination stacks two separate mechanisms rather than merging them into one system. Each layer still carries its own distinct point of failure even when combined.