Backup and recovery
Sigma encrypts identity backups locally and can store the encrypted result in the cloud. Keep an offline encrypted copy as well. A cloud upload, a linked social account, an account session, and a local unlock are separate steps.
Recovery choices
| What you have | What it can do |
|---|---|
| Full encrypted backup and its password | Restore the identities and metadata contained in that file |
| Previously linked social account and backup decryption factor | Locate a stored cloud backup, then decrypt it locally |
| Enrolled PRF-capable passkey on a supported device | Unlock the backup associated with that enrollment when available |
| A member/WIF backup | Restore that included account key; not the master or sibling profiles |
| A supported seed-format phrase plus exact profile index | Recover that seed-derived profile; not automatically the complete inventory |
An ordinary account passkey and a passkey enrolled for PRF backup decryption are not interchangeable. A successful social/email login does not itself decrypt a backup.
Formats and compatibility
The auth server pins the seed-aware bitcoin-backup@0.0.14 reader/writer. Preserve the file's format discriminator, derivation metadata, and inventory when importing or exporting. Legacy master, HD, member, and WIF backups must not be silently converted to a new seed identity.
New seed creation is independently gated by GET /api/features/seed-recovery, which returns { creationEnabled }. Reader support does not mean new-account seed creation is enabled. Existing root-key backups do not have a phrase that Sigma can reveal or reconstruct.
For seed-format backups, phrase-only recovery requires an exact profile index and has an incomplete inventory. It cannot discover all sibling profiles or safely decide the next unused index. Restore a complete file before allocating/removing profiles or replacing a cloud backup from an incomplete recovery.
Save a backup
Use the account UI to export an encrypted file and upload a cloud copy while the correct identity is selected. Verify the upload/status response and keep the password separately. Do not assume linking an OAuth provider automatically creates or updates a backup.
The Backup API accepts ciphertext, not plaintext private keys or a password. Backups and durable recovery mappings live in PostgreSQL; Redis/KV is used for caching and other transient state. There is no documented ten-year retention guarantee.
Restore safely
Open Restore, choose the supported file or linked-account flow, and decrypt locally. Review the derived/loaded identity before replacing local state. A missing lookup is not permission to generate a replacement identity. Keep the last working file until the restored identity signs successfully.
See social recovery, wallet recovery limits, and backup security.