Key recovery and the
Sovereign Personal Agent.

The cryptography is the easy part. The hard part is whether real users can survive losing their device without losing their identity.

The impartial-evaluation pass on the SLF architecture used a sharp framing: "Key recovery alone gates Phase 3. Saying 'the protocol enables sovereignty' without recovery is like saying 'the car works' without brakes, the missing piece is what determines whether the system is usable." That framing is correct. The Phase 1 prototype proves the cryptographic mechanics of recovery work. It does not prove anything about real-user UX, social-engineering resistance, or recovery-from-recovery. The page below treats those as separable.

Recovery is not one operation. The Sovereign Personal Agent must survive at least eight separable scenarios: lost device, stolen device, device damaged beyond reach, total loss of every backup, coercion, incapacitation, death, court order, provider failure (your cloud account is closed), and compromise. Each has its own threat model and its own UX flow. Most prior wallets pick one and pretend the others don't exist.

Three industry signals shape the design space. Apple iCloud Keychain leans on SMS + security code + hardware-enforced guess limits, serviceable for consumers but coupled to a single hyperscaler. Google Password Manager requires sign-in + screen-lock PIN from another device, same coupling. The most consequential signal comes from Argent: after years building social recovery (guardian friends-and-family hold shares) for a leading crypto wallet, in February 2025 it added cloud-encrypted recovery with a 48-hour cooldown as an opt-in alternative (under its "Ready" rebrand), rather than relying on guardians alone. The shift is a strong production signal: pure social recovery carried too much friction to stand as the only mainstream path.

The tension at the heart of the design is structural. Sovereignty demands "no single operator can deny recovery." Usability demands "recovery must work for people who don't understand cryptography." Regulators (eIDAS 2 and the EU Digital Identity Wallet framework) demand "credential re-issuance, not key copying." A scheme that satisfies any two of those three is easy. A scheme that satisfies all three is the hard part, and the part Phase 1 is taking a first run at.

FROST is the RFC 9591 threshold-signature scheme for Schnorr / Ed25519. Two of three shares can produce a valid signature without ever reconstructing the full signing key in process memory. The construction dates to 2020 (Komlo and Goldberg), and the Zcash Foundation's Rust implementation has been independently audited (NCC Group, 2023). The choice is grounded in constraints: FROST is the one threshold scheme that is mature, audited, and satisfies the requirement that the full key is never assembled, not even transiently.

The default consumer configuration uses three share locations: a device share held in Secure Enclave behind biometric, a cloud share wrapped by the user's cloud-provider account (Apple iCloud Keychain HSM cluster or equivalent), and a printable 28-character recovery-code share the user keeps offline. Any two reconstruct enough signing capability to recover; one alone returns Err(InsufficientSigners) cleanly. Shares zeroize on drop. The full key never exists.

Three trade-offs against alternatives are worth naming directly:

• FROST vs. classic seed phrases (BIP-39): A seed phrase is a recovery code, not a recovery primitive. Lose the words and you lose everything; possess the words and an attacker possesses everything. FROST converts that single-point problem into "do you have access to two of three locations?" Different UX, potentially better, potentially worse depending on the user's threat model.
• FROST vs. SLIP-39 (Shamir Secret Sharing): SLIP-39 reconstructs the key offline. FROST never does. eIDAS 2 requires the latter. The regulatory constraint forces FROST.
• FROST 2-of-3 vs. 2-of-2 with a trusted provider (Zengo, single cloud): 2-of-2 dies when the provider does. Zengo's 2-of-2 MPC design shows the structural version of this: if the user dies without configuring inheritance and heirs lack the recovery factors, the wallet is unrecoverable. 2-of-3 survives provider disappearance by design.

Recovery runs as a state machine with cooldowns, vetoes, and a probation period after it completes. Six states and the transitions between them:

• Onboarded Initial state after enrollment. Shares distributed, identity anchors registered, recovery contacts (optional) enrolled.
• Daily Use Steady-state operation. Wallet signs operations, presents credentials, issues grants, emits receipts.
• Recovery Initiated Threshold of recovery factors satisfied (two of three shares + identity-anchor proof). Recovery process has formally started; the system enters Cooldown.
• Cooldown 48 h False-positive cost (user locked out) is lower than false-negative cost (attacker silently drains substrate). The 48-hour window gives the old device, if reachable, time to veto. Recovery contacts can cancel. Multi-channel alerts fire continuously.
• Probation 24 h Cooldown cleared. New wallet enters restricted state, can present existing credentials (read-only), cannot issue new grants, cannot write to substrate. Existing grants are paused, not revoked. Final user veto window if the recovery was hijacked.
• Live Probation cleared. Wallet enters full operating state. Grants resume; new grants can be issued; substrate writes are permitted.

Cancellation paths exist from Cooldown back to Onboarded. The old device, a recovery contact, or a configured guardian can each abort the recovery. Cancellation itself emits a receipt, which is the audit substance the regulator or user inspects later. Emergency rotation (the user discovers compromise) skips cooldown by user choice, but skipping cooldown is itself recorded, with the user's explicit override evidence.

Every state transition emits a signed Receipt SLF (see the receipts deep-dive for the broader semantics). The design names eleven recovery-specific receipt kinds: recovery_initiation, recovery_factor_assertion, recovery_cooldown_start, recovery_cooldown_cancel, recovery_probation_clear, wallet_unit_rebind, credential_reissuance_request, credential_reissuance_complete, inheritance_trigger, proxy_designation, and court_order_disclosure. Each carries a prev_hash linking to its predecessor; the entire recovery lifecycle replays as a verifiable chain.

The integrity property is the same as for ordinary receipts: a verifier starting from scratch, with no shared state, can replay the chain and confirm (a) every receipt is cryptographically signed, (b) every prev_hash matches its predecessor, and (c) the state sequence is valid, the chain cannot jump from Cooldown directly to Live without passing through Probation.

This is what makes recovery auditable. Regulators inspecting whether a user's identity was recovered correctly can ask for the chain, walk from genesis through the rebind, and verify that the cooldown was honored, the probation cleared, the cancellation paths were available. The protocol's argument under GDPR Article 25 and eIDAS 2 transparency requirements is that the chain provides exactly the structured evidence those regimes ask for, first-class testable artifacts rather than implementation-specific logs.

The Phase 1 prototype is a Rust CLI workspace (spa-recovery), published at github.com/andrewcrenshaw/SPA. Its three load-bearing validations:

1. FROST 2-of-3 works as designed. Two-of-three signing succeeds. One-of-three fails with Err(InsufficientSigners). Partial signatures from mismatched commitments fail cleanly. All in pure Rust with in-memory shares; no network calls; no cloud integration.
2. The lifecycle state machine is coherent. Onboarded → Daily Use → Recovery Initiated → Cooldown → Probation → Live, with cancellation paths at every state. The clock is injectable, so 48-hour cooldowns are tested without 48-hour waits.
3. Receipt chains verify end-to-end. Generate a chain through the full recovery lifecycle. Replay it on a fresh verifier with no shared state. Confirm every link.

Out of scope, deferred to Phase 2 or beyond: iOS Secure Enclave integration, Android StrongBox, real Apple iCloud Keychain backends, real Google cloud-account binding, zero-knowledge proofs of backup correctness, UX testing with non-cryptographer users, and any kind of social-guardian onboarding workflow. Shares in Phase 1 are encrypted files under ~/.spa-recovery/ with AES-256-GCM and stub labels ("device-stub", "cloud-stub", "recovery-code-stub"), not production key sources.

Effort: roughly 1.5–2.5 weeks of work for one engineer comfortable with threshold cryptography. What this proves: the algorithmic and state-machine mechanics are correct, and the protocol does not have fundamental flaws at those layers. What it does not prove is whether real users can execute a recovery, whether family members can be relied on to hold a share, or whether cloud-provider account recovery is as smooth in practice as the Secure Enclave path is in spec.

The cryptography is the easy part. Five hard problems remain unsolved, and Phase 1 makes no claim to address any of them.

Social-recovery participant onboarding. If a recovery contact is part of the configuration, what does "accept this share" mean in practice? Email plus QR code? In-person handoff? The Apple Legacy Contact pattern points at the underlying risk: a meaningful share of users who enroll a recovery contact lose track of it over time. The recovery contact may die, may lose the share, may not understand what the share is for when asked. The design names the pattern (one optional contact who knows the user but not the secret). The operational discipline around onboarding is for Phase 2.

Family-member attack resistance. The recovery contact may be a sibling. After a family dispute, what stops the sibling from initiating a false recovery? The 48-hour cooldown provides a veto window, but only if the user is monitoring email. Travel and incapacitation are common; sophisticated social-engineering attacks against family recovery contacts are a known class. Cryptography cannot prevent this; it can only make detection deterministic after the fact.

Device-loss vs. device-compromise discrimination. If a phone is lost in a taxi, the user wants smooth recovery. If a phone is stolen by a nation-state adversary with the user's pin code, the user wants instant key rotation with no cooldown. The protocol cannot ask the user "which one happened?" because the UX is the same at the moment of loss. The architecture's response is to make the user choose the tier at enrollment, default consumer, threshold-network protected, or institutional-guardian protected. That is a high-stakes UX decision the user makes before the threat materializes, with imperfect information.

Recovery from recovery. If a user recovers their wallet because the old device is gone, then months later finds the old device intact with the old key still active, what happens? Can an attacker who acquires that old device still sign with the now-stale key? The design points at proactive secret-sharing key rotation, but the user-side UX of "you need to rotate again, here is why" is unspecified.

Post-compromise credential trust. When a user rotates keys after compromise, the credentials issued under the old key still exist with old issuers. EUDIW's Migration Object pattern says each issuer re-issues against the new key. But this depends on every issuer cooperating, and there is no protocol-level enforcement.

• Key recovery is not solved. It is approached. The impartial evaluation calls it the gate on Phase 3 explicitly, and the page agrees.
• FROST does not eliminate seed phrases. It changes the seed-phrase problem from memorization to availability. Better in some threat models, worse in others.
• The Phase 1 prototype is not a production proof. It validates mechanics. Production claims wait on Phase 2 (real platforms, real users, telemetry).
• Threshold signing does not prevent social engineering. It raises the bar by requiring compromise of two factors instead of one. A skilled attacker manipulating a recovery contact remains a real attack class.
• Three FROST shares do not cover all loss scenarios. The default consumer tier is the entry point. High-threat users need Tier 1 (no hyperscaler) or Tier 2 (3-of-5 with institutional guardian). The model scales; the entry point does not pretend to be universal.
• Recovery is not the only blocker. The impartial evaluation flags it as a gate on Phase 3, but vault-provider market viability, jurisdiction edge-case handling, ZK-circuit governance, and post-quantum migration are also open. Recovery deserves attention; it does not deserve to be treated as the singular problem.

If you are reading this with a security-research, identity-architecture, or sovereign-personal-data lens and a counter-claim is missing, an attack class is underplayed, or a mitigation reads stronger than it should, that is the feedback the draft needs. Contact details are in the header above.