Wallet recovery boundaries
Identify what was backed up
A Sigma master backup, member backup, connected-wallet recovery record, and external wallet backup are different artifacts. Review the backup format and selected identity before importing anything. A member/WIF backup grants its included account authority; it cannot reconstruct the master or sibling profiles.
Connecting an external wallet does not upload that wallet's seed or guarantee Sigma can restore it. Use that wallet's own supported backup/recovery process for its original funds and keys.
Connected-wallet metadata
Sigma can store a BSV address, provider/connection method, and client-supplied Type42 recovery metadata such as the scheme, BAP identity ID, counterparty public key, and invoice signature. Preserve that metadata with the compatible client implementation. It is not a substitute for the required private signing material.
Do not derive a funding key by hashing a public BAP ID, chain ID, or wallet address. Public identifiers do not provide secret entropy. Older public-input address-derivation examples are not a supported recovery recipe; do not use them to secure funds.
Portable recovery
Export a supported encrypted backup, retain its version and derivation information, and test recovery locally before depending on it. Import keys only into a wallet that explicitly supports that key format and derivation scheme. No universal import promise is made for hardware wallets, custodial services, or arbitrary EVM/Bitcoin wallets.
Recovering key material does not automatically discover transaction history, inscriptions, tokens, profile metadata, or every derived address. Those may require the original wallet's indexer and derivation metadata. Never generate a new root key to work around a missing-profile lookup.
See backup formats, wallet API, and signing.