Recovery
Recovery applies when the user can no longer reproduce the wallet's controlling secret, such as when biometric or visual inputs drift beyond the extractor's tolerance. Even if rare, embedded wallets need a recovery path that preserves self-custody and keeps assets in place.
Recovery is implemented through rekeying: the wallet address and on-chain state remain unchanged, control rotates to a new key derived from the user's new embedded wallet, and assets never leave the account. This avoids asset transfers, reduces operational risk, and keeps recovery fully on-chain.
Choosing a mechanism
| Mechanism | What changes | Strengths | Trade-offs |
|---|---|---|---|
| Timelocked fallback transfer | Control transfer after delay | Works even with zero guardians | Introduces “assisted recovery” ops + compliance surface; funds temporarily leave wallet |
| Social recovery (guardians) | Control key rotates | Funds stay in wallet; no single party controls recovery | Coordination risk; guardian compromise/collusion needs mitigation |
In practice, many products support both, using guardians as the primary safety net and timelocked fallback as a last resort.
Option 1: Timelocked fallback transfer (assisted recovery)
Summary
At wallet setup, the user signs a pre-signed recovery transaction that is not submitted immediately. The backend stores it and can only submit it after a timelock (e.g., 90 days) and after a manual identity verification process.
A reference UX flow typically includes:
- A clear explanation (“you sign a recovery transaction; it’s not submitted now”).
- A validity window (e.g., “valid for 90 days”).
- A “review & sign” step that highlights “all funds” and “not submitted now.”
- A passkey-confirmed action (“Confirm using passkey”).
Sequence
Key considerations
- The platform does not need the user's private keys to execute this flow.
- The platform cannot execute before the timelock.
- The user should be able to regenerate/rotate the fallback transaction while they still have access (invalidating older artifacts).
- This mechanism is subject to policy, legal, and compliance review.
Option 2: Social recovery (guardians)
Summary
The smart account is configured with a set of guardians (trusted accounts). Recovery requires approvals from a configurable threshold (e.g., 2-of-3, 3-of-5). After threshold approval, the wallet rekeys to a new controlling key derived from the user's new embedded wallet.
A reference UX flow typically includes:
- Selecting guardians (trusted contacts).
- Choosing a threshold (e.g., 2-of-3).
- A recovery screen that shows approval status and allows canceling the request.
Sequence
Key considerations
- No single guardian (or platform party) can unilaterally take control when thresholds are used.
- Funds do not leave the wallet during recovery; only the controlling key rotates.
- Security increases with more diverse guardians, but coordination becomes harder.
- Guardian compromise/collusion remains a residual risk; mitigate with thresholds, delays, and monitoring.