Skip to main content
Account recovery lets a user regain access to their wallet after they can no longer use their original passkey. The most common reasons are a lost or damaged phone, a passkey deleted during a device reset, or a failed migration to a new authenticator. Recovery does not create a new wallet and does not move assets — it replaces the authentication credential so the user can sign in again with a new passkey while accessing the exact same wallet they had before.
Recovery is a high-privilege operation. A successful recovery permanently replaces the credential that controls a wallet. You must implement robust identity verification before authorising a recovery request. Weak verification is the primary attack surface for account takeover.

What recovery is and is not

SocketFi recovery replaces the authentication credential, not the wallet. Think of it as re-issuing a lost key to an existing lock — the lock (wallet), its contents (assets), and its address on the blockchain stay exactly the same. After recovery completes, the user authenticates normally with their new passkey and lands in the same wallet as before.

When users need recovery

Recovery is the right flow when the user cannot access their current passkey:
  • Lost, stolen, or destroyed phone
  • Passkey deleted during a factory reset or OS reinstall
  • Failed device migration (old device disposed before credential was transferred)
  • Authenticator app uninstalled or reset
If the user still has access to their current passkey but wants to move to a new device, use Credential Rotation instead. Rotation is simpler, faster, and does not require identity verification because the user can prove ownership directly with their existing credential.

The recovery flow

Recovery security requirements

Before shipping your recovery flow to production, confirm:
  • Identity verification is mandatory — there is no path through recovery that bypasses it
  • Recovery tokens are server-side only — never expose the raw token in a URL or client-side log
  • Rate limiting is in place — limit recovery attempts per wallet per time window to deter brute-force attacks
  • All recovery events are logged — timestamp, wallet, outcome, IP, and verification method
  • Users are notified — send a push notification or email when a recovery is initiated, approved, and completed

UX recommendations

Surface recovery prominently but not obtrusively. Place a “Can’t sign in?” link on your login screen, but don’t make it more prominent than the normal sign-in button. You want it easy to find in a moment of stress, not so visible that it encourages casual misuse. Explain what recovery does before it starts. Many users worry they will lose their assets. A single sentence — “Your wallet and assets are safe; we’re just replacing your sign-in credential” — dramatically reduces support requests. Use step indicators. Recovery takes multiple steps across multiple screens. Show a numbered progress indicator (e.g. “Step 2 of 3”) so users know they are making progress and have not accidentally reached a dead end. Keep error messages actionable. “Identity verification failed” is unhelpful. “The code you entered doesn’t match. Please check your email and try again, or contact support.” is clear and gives the user a next action. Test the complete flow before launch. Recovery is rarely triggered, which means it is rarely tested. Walk through the entire flow on a staging environment before going live, and schedule a periodic test drill to catch regressions.

Monitoring recovery events

Log and monitor every stage of the recovery lifecycle:
src/server/services/recoveryAudit.ts
Repeated recovery failures for the same wallet — especially if they originate from different IP addresses — may indicate an account takeover attempt. Set up alerts for this pattern and have a response plan ready.