Backup & Recovery

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.

const wallet = await client.createWallet();

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

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

wallet = client.create_wallet()

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

# Then continue.
address = client.derive_address(wallet, "ethereum")

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.

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

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.

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.

To enable managed recovery or discuss custom schemes, contact us at support@walletsuite.io.

Get Started

Concepts

Building

Reference

Store the wallet

Self-recovery is your backup

Managed recovery and custom schemes

Next steps

Shares & thresholds

Security overview

​Store the wallet

​Self-recovery is your backup

​Managed recovery and custom schemes

​Next steps

Shares & thresholds

Security overview

Store the wallet

Self-recovery is your backup

Managed recovery and custom schemes

Next steps