Skip to main content
Lost-passkey recovery adds a new app-origin passkey to the user’s existing managed smart account. It does not restore a credential from another application, copy a centralized backup into the app, or run the Custom signer guardian API. Before recovery, configure verified-identity recovery during account creation. The user must return to the same app-origin account namespace and verify the same email or OAuth identity.

Start from authentication

Use the same client and authentication entry point as normal login:
flow: "login" selects the initial presentation; it is not an authorization boundary. The service decides from verified identity and account state whether to authenticate an existing passkey or enter recovery. A user can also choose Recover account after the passkey ceremony fails.

Recovery flow

  1. The user verifies the account’s configured email or OAuth identity in Rhinestone’s identity UI.
  2. Rhinestone resolves the existing account in the current app-origin namespace.
  3. The user selects Create passkey, and WebAuthn registration runs in your application’s top-level page.
  4. The configured guardian authorizes adding that exact new credential.
  5. Rhinestone submits EVM recovery across every required EVM chain where the account is deployed.
  6. After those chains succeed, Rhinestone activates the new passkey. For a managed Solana wallet, service recovery then adds it on each cluster with an enrolled service guardian; the completion screen reports the accounts separately.
  7. Rhinestone returns a fresh app-origin session. An unfinished Solana recovery does not undo successful EVM recovery; the next sign-in with the replacement passkey offers to finish it.
The identity and recovery instructions are Rhinestone-owned UI. The final WebAuthn registration is browser-owned and remains bound to your app’s RP ID and exact origin. There is no fallback to the experimental cross-origin credential namespace.
Do not change the host name, configured RP ID, clientId, or WebAuthn mode during recovery. Recovery is namespace-specific; a credential from another app or the hosted provider RP cannot authorize this account.

After recovery

Recovery is additive. It does not silently revoke other active credentials or remove a lost Solana root. The managed SDK does not expose a normal public passkey-addition API; recovery is not a general credential-management flow. For Solana, re-read getSession() and check readiness on the intended cluster before funding or spending. EVM registry revocation does not automatically remove a Solana authority. See Recovery and authority limits. If EVM recovery fails before all required EVM chains complete, do not treat the pending passkey as active. Retry from the same application namespace. A successful result is the signal that the new credential and session are ready. For accounts whose guardians and owner rotation are managed directly through the Rhinestone SDK, follow Custom signer recovery instead.