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

# Backup & Recovery

> Store the wallet you hold, keep a secure backup that doubles as your recovery, and see the managed recovery and custom-scheme options.

Your wallets are self-custodial with no seed phrase. By default each wallet is a 2-of-2: you hold the wallet and WalletSuite holds a co-signing share. Both are needed to sign, and the full key is never assembled anywhere.

You hold one of the two halves, so your backup of the wallet is what keeps it recoverable. This page covers how to store the wallet well, how self-recovery works, and the managed recovery and custom-scheme options.

## Store the wallet

Persist the wallet to durable storage you control, never a temp directory, and keep a secure backup. Create the wallet, store it, then derive an address or sign. The SDK does not persist the wallet for you, so write it somewhere durable first.

<CodeGroup>
  ```js wallet.js theme={null}
  const wallet = await client.createWallet();

  // Save the wallet first.
  await saveWallet(wallet); // your durable storage

  // Then continue.
  const address = client.deriveAddress(wallet, "ethereum");
  ```

  ```python wallet.py theme={null}
  wallet = client.create_wallet()

  # Save the wallet first.
  save_wallet(wallet)  # your durable storage

  # Then continue.
  address = client.derive_address(wallet, "ethereum")
  ```
</CodeGroup>

<Tip>
  Pick storage that survives restarts and container recycling. If the save fails, surface the error and retry before you derive an address, so every wallet you create is safely stored.
</Tip>

## Self-recovery is your backup

You pass the wallet back on every call, so where it lives between calls is up to you. Your secure backup is your recovery: restore the wallet from your backup and signing resumes. Pick a pattern that matches your custody and threat model. These combine well, so most teams use more than one.

| Pattern                      | Where the wallet lives                                    | Good fit when                                                                      |
| ---------------------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| **Your database**            | Encrypted at rest in your backend store                   | You run server-side signing and already operate a secure datastore                 |
| **KMS or HSM**               | Wrapped by a managed key in AWS KMS, GCP KMS, or an HSM   | You want the wallet encrypted under a key your application never sees in plaintext |
| **User device**              | Secure enclave or keystore on the user's phone or browser | The user signs locally and you want the wallet off your servers entirely           |
| **Passkey-wrapped envelope** | Encrypted blob decryptable by a WebAuthn passkey          | You want device-bound, phishing-resistant access with no password to lose          |

<Tip>
  A common shape is a KMS-wrapped wallet in your database with a passkey-gated copy on the user's device. The wallet stays recoverable even after a database breach or a lost phone.
</Tip>

Whatever you pick, test two things: how the wallet is restored after a device swap or database failover, and who can read it and under what authorization. Running through a restore once confirms the backup works.

## Managed recovery and custom schemes

The default 2-of-2 with your own backup is a strong baseline for most integrations. Two options extend it.

| Option               | What it gives you                                                                                  | Availability                                                     |
| -------------------- | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| **Managed recovery** | An extra recovery share you do not hold, so your half can be restored if it is ever lost           | Opt-in under separate commercial terms. Contact us to enable it. |
| **Custom schemes**   | A custom threshold such as 2-of-4, so the wallet keeps signing even if some shares are unavailable | On the roadmap                                                   |

Either option keeps the wallet self-custodial: the full key is never assembled, and no single party can sign alone.

<Note>
  To enable managed recovery or discuss custom schemes, contact us at [support@walletsuite.io](mailto:support@walletsuite.io).
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Shares & thresholds" icon="key" href="/mpc/key-shares">
    What a share and a threshold are, and the 2-of-2 model.
  </Card>

  <Card title="Security overview" icon="shield-check" href="/security/overview">
    How WalletSuite protects your wallets, audits, and the rest of the platform.
  </Card>
</CardGroup>