Skip to content

Encrypted wallet backup

Keep your 12-word recovery phrase offline and safe. Keep the wallet’s local data while a trade, payment, or refund is unresolved. Encrypted backup helps you recover wallet assets. It does not replace the phrase or every local record.

Top-up and deposit screens show a non-blocking reminder until you view the wallet’s recovery phrase in Settings, then Cashu. The reminder appears again each time you open one of these screens. Viewing the phrase acknowledges the reminder for the current wallet. It does not confirm the encrypted backup or prove that you made an external backup. A different wallet starts with a new reminder.

Your Nostr private key (nsec) is separate from your wallet recovery phrase. The phrase does not restore this key.

For a key created by the app, open Settings, then Nostr, then View nsec. You can back up the key even if your relay profile does not load. Confirm the warning before you view the key. Use Copy nsec only in private. The app blurs the key after 15 seconds and hides it after 60 seconds. Keep the copy safe. Do not share it with support or other users.

For an imported key, keep your original backup. Settings does not show backup controls for imported keys.

If you use a NIP-07 external signer, back up the key in that signer. bitCaster cannot display its private key.

The backup service can be unavailable, refuse an upload, or lose its data. A failed upload leaves the affected ecash records, called proofs, in local storage. The web app must not discard them as backed up.

Recovery from your phrase can reconstruct deterministic regular proofs and selected conditional-token proofs. It does not reconstruct every pending operation or refund record. In particular, it does not restore transient operation records, range locators, or refund locators. Keep the local wallet database until every active operation has a confirmed final result. Do not clear browser storage to resolve an uncertain payment or trade.

The web app has two independent wallet features. It enables both by default.

  • Encrypted proof backup stores an encrypted copy of recoverable proofs.
  • Display-only asset monitoring helps the app identify an exact asset that may be missing from the local wallet.

The live wallet database remains in your browser. These features help if the browser removes stored data or you reopen a previously used wallet.

Only keys derived from your 12-word recovery phrase can decrypt the backup. The backup service can associate an authenticated account with a wallet id. It receives an opaque asset locator, a declared amount, approximate stored size, object count, update timing, and network metadata. It does not receive raw mint URLs, condition or market ids, trade ids, proof bodies, proof secrets, or spending keys. It cannot spend your funds or read the encrypted proof contents.

Encryption protects spending authority. It does not make wallet activity anonymous from the matching engine. Asset monitoring separately lets the matching engine associate an authenticated user and wallet id with approved asset, amount, condition, and activity metadata. The matching engine and backup service can correlate the shared wallet id.

The mint receives neither your matching-engine identity nor asset-monitoring data. The mint only receives the Cashu requests that are required for wallet operations.

Asset monitoring does not store proofs for you and does not give the matching engine authority to spend. It is display-only. Its primary purpose is a best-effort display of your current and historical portfolio in base units. It uses user-approved asset, amount, condition, and activity metadata.

The history chart shows changes in estimated portfolio value. These changes can include cash flows. They do not measure profit or investment return.

Its secondary purpose is to help the web app identify an exact missing asset. The app can then make one bounded recovery attempt.

The portfolio’s Funds tab groups regular funds by mint and asset. It shows money in sats. Different mints remain separate. The portfolio refreshes after the service accepts a wallet update. An updating or unavailable value does not mean that funds are lost. Positions without a known price remain visible. Use the wallet’s payment or trade flow to check which funds it can spend.

During portfolio updates or an unfinished claim, the app can keep the last successful value estimate on screen. It marks that estimate as out of date. The estimate is not an amount available to spend. The app keeps it only in memory. Reloading the page, changing the wallet, or changing the signed-in account clears it. An unavailable initial value does not become a saved estimate. Claim progress comes from the wallet’s current operation, not from the saved estimate.

When the web app needs proofs for one asset, it uses this order:

  1. It uses proofs in local browser storage.
  2. If the validated backup inventory contains the asset, it restores that asset’s current encrypted bundle.
  3. It makes one bounded targeted recovery attempt only when monitoring identifies an exact missing asset.

The web app does not make a broad automatic keyset scan when monitoring does not identify an exact missing asset. If the backup service is unavailable, the web app shows a persistent error. Unavailability does not prove that an asset is absent and does not authorize automatic mint recovery. Broad recovery remains available through the CLI.

If a trade needs Engine Score and locally available funds are insufficient, the app checks wallet recovery. If recovery is unavailable, it offers Retry or Add funds. This message does not mean that other wallet funds are lost. Retry checks recovery again within the existing recovery limits. Keep browser data while a trade or payment remains unresolved.

Wallet recovery supports monetary tokens with unit msat only. The web app shows their value in sats: 1,000 msat equals 1 sat. Recovery does not convert tokens with unit sat.

Counter-zero discovery is only a selection step. It selects non-expired CTF keysets before a full recovery. It is not full recovery by itself.

One authenticated account can retain several independent wallet ids. Each wallet id belongs to one wallet seed. Funds never move between wallet ids. The web app displays only the wallet for the recovery phrase currently open:

  • entering a new recovery phrase starts a new, empty wallet;
  • entering a previously used recovery phrase downloads and opens that wallet’s latest encrypted backup again.

The service retains one current head and the current per-asset bundles for each wallet id. It does not provide old wallet states as recoverable versions. Old versions could contain proofs that have since been spent.

Browsers that use the same recovery phrase belong to the same wallet. The latest authenticated backup can tell another browser that an exact conditional proof belongs to a losing outcome, even if that browser missed intermediate backup updates. The browser keeps that proof complete and visible, but does not select it for spending. Synchronization does not silently delete the proof or overwrite an unfinished local wallet operation.

The initial 64 MiB encrypted-storage allowance is shared by all wallet ids under the same authenticated account. An account may create at most 256 distinct seed-derived wallet ids over its lifetime. Reopening a previously used seed does not consume another slot. Revoking or deleting a wallet id does not return its slot. If a recovery phrase is permanently lost, its encrypted data cannot be identified or deleted in this release. It continues to use part of the storage allowance. Keep every phrase for a wallet you may want to reopen.

The app shows Preparing wallet backup while it checks your backup. The deposit and top-up screens show this message where you enter an amount. Wait for the check to finish before you create an invoice or add ecash. You do not need to keep clicking the action button. If another tab uses the wallet, close that tab when you no longer need it.

If backup stops, select Retry wallet backup in the same screen. Retry keeps your amount, local funds, and unfinished work. It does not create or submit an invoice. After backup is ready, select the action button to continue. If the message asks you to sign in, sign in or reload the page if you are already signed in. This check does not require sign-in when backup is disabled or the wallet has no backup enrollment. Retry does not guarantee that backup or recovery can finish.

A fresh browser restores and checks the wallet’s current encrypted backup before it enables wallet actions or uploads new backup data. You can read the app while recovery runs. If recovery cannot finish, wallet actions stay paused.

Use one browser at a time for wallet actions. Another open browser can still run background work. When another browser changes the wallet backup, this browser can stop new wallet actions and automatic backup uploads.

The app keeps local proofs and unresolved operations. It does not automatically merge different browser states. Reload starts recovery. It does not delete local data or guarantee that wallet actions can resume.

The recovery message explains what remains unresolved. Use its retry action to check recovery again. Keep browser storage while recovery is incomplete. The app resumes new wallet actions only after it has checked the current backup and resolved the local state that blocks recovery.

An unpaid invoice can still block recovery if the wallet has already prepared its ecash outputs. This can happen even if you no longer intend to pay the invoice. The app keeps the invoice and its prepared outputs. It does not replace them automatically. Reloading or retrying does not guarantee that this browser can resume wallet actions.

The command-line wallet can use complete-local privacy mode. This mode can omit both encrypted backup and asset monitoring. It keeps complete wallet state in its local durable store.

The CLI also keeps broad emergency NUT-09/NUT-13 recovery. Use it when the backup service is unavailable or when you need seed recovery. It scans regular keysets. It uses counter-zero discovery to select non-expired CTF keysets, and then scans the selected keysets fully. Each keyset uses the standard 300-counter gap limit.