> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rhinestone.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Trustless recovery

> Understand which recovery guarantees are enforced onchain and which services managed recovery still depends on.

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.

<Warning>
  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.
</Warning>

## What the 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.

## 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.

| Property              | Current guarantee                                                                              |
| --------------------- | ---------------------------------------------------------------------------------------------- |
| Asset custody         | Assets remain in the user's smart account, not in a Rhinestone database.                       |
| Account authority     | Deployed account contracts enforce their current signer and guardian state.                    |
| Recovery integrity    | Signed parameters are verified onchain; replay protection applies independently on each chain. |
| Managed guardian      | Rhinestone controls the managed signing capability trusted by accounts that use it.            |
| Identity verification | Identity-provider and Rhinestone checks are offchain policy, not onchain enforcement.          |
| Recovery availability | The managed flow requires its offchain services and supported chains to be reachable.          |

<Note>
  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.
</Note>

## 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](/wallets/custom-signer/recovery/set-up), with the corresponding responsibility to secure and keep those guardians available.

For the managed flow, continue with [Set up recovery](/wallets/recovery/set-up) and [Recover an account](/wallets/recovery/recover-an-account).