Skip to main content
Recovery separates onchain authorization from offchain identity policy. A counterfactual smart account has an onchain address before deployment; its code and state are deployed when first needed, and assets remain at that address. Once deployed, the account contract enforces who may authorize recovery. The current managed flow still relies on offchain services to verify identity, register a replacement passkey, produce a guardian signature, and relay the recovery.
Managed recovery is not trustless end to end. Rhinestone currently operates the managed guardian signing capability. Control or compromise of that capability can authorize a replacement passkey and gain control of an account configured to accept the managed guardian. An outage cannot transfer assets or change account authority, but it can prevent recovery.

​
What the EVM account enforces onchain

On every chain where the smart account is deployed, its contract stores and enforces the active signer and guardian configuration. Recovery succeeds only when the configured guardian authorizes the operation accepted by the account’s recovery module. The guardian authorization binds the account, replacement credential, recovery nonce, and expiry. The managed flow intentionally signs with chainId: 0, making one authorization valid across the configured chains. Each chain consumes the nonce independently and rejects reuse on that chain. These checks prevent a relayer or observer from substituting another passkey, using the authorization for another account, or replaying it on the same chain. The authorization is intentionally not bound to one chain. The contract verifies authorization by a configured guardian; it does not verify that Rhinestone followed its offchain identity policy.

​
Managed Solana authority

Solana setup installs a permanent root, the service recovery key, and active passkeys in the Swig. Hosted recovery uses the email or OAuth service guardian to add a replacement passkey; it does not accept an EVM PRF-derived or backup-file user guardian. The EVM chainId: 0 authorization described above is not the Solana authorization model. The enrolled service key stays fixed; advertising a new key does not automatically rotate it. Losing that key removes the service-recovery path, though working user passkeys remain usable. A compromised authority requires an explicit per-wallet onchain response; EVM registry revocation does not propagate to Solana. Recovery adds a passkey without revoking lost credentials or removing the original root. The service guardian’s ability to add a controlling passkey remains an account-control risk. There is no Solana user-held recovery path or either-guardian policy.

​
What managed recovery trusts

Verified-identity recovery combines independent checks across several components:
  1. The identity provider issues a signed token that proves control of an identity.
  2. The user’s authenticator creates the key pair and credential. The passkey service provides registration options, verifies the registration and attestation response, records the public credential, and issues its credential token.
  3. The Rhinestone-managed recovery signer verifies the identity-provider token, its recovery nonce, the new-credential token, and the account’s identity commitment before producing a guardian signature.
  4. A relayer submits the signed request, but cannot change the request that the guardian authorized.
  5. The smart account performs the final guardian, nonce, and expiry checks onchain.
The recovery signer uses a separate signing key from the relayer. Compromising or operating the relayer alone does not create a valid guardian authorization. However, Rhinestone operates the managed guardian and the services that apply its identity policy before signing. The current signer retrieves the account-bound identity commitment through an authenticated Rhinestone service endpoint, and the flow depends on Rhinestone infrastructure, the configured identity provider, chain RPCs, and transaction submission being available.
A decentralized recovery signer, including the Lit Protocol design described in earlier architecture material, is not part of the current released recovery flow. Do not rely on it as an available fallback.

​
Plan for recovery availability

Configure recovery when the account is created, and test it from the same application namespace. Keep the app’s host name, RP ID, client ID, and WebAuthn mode stable; recovery cannot use a credential from another app namespace. Do not present verified-identity recovery as protection against permanent loss or compromise of every managed dependency. Managed guardians rely on Rhinestone’s signing capability and identity policy. Independent custom guardians instead rely on the people or systems that hold their signing keys. If your threat model requires recovery infrastructure that your organization controls, use Custom signer recovery, with the corresponding responsibility to secure and keep those guardians available. For the managed flow, continue with Set up recovery and Recover an account.