Loading…
A successful download or matching balance is not sufficient recovery evidence. Prove that an independently recovered key and retained data work together after the original device or provider is unavailable. Start with the recovery inventory and BRC-38/39 integration guide.
This is a reusable acceptance plan, not a claim that TS Stack or any wallet has passed every scenario. Use synthetic wallets and local/testnet fixtures. A production restore, provider promotion or real-money spend needs a separate operator-approved procedure; do not use this checklist to authorize one.
Record exact wallet/package versions, network, storage backend, device/runtime, schema/migrations, selected profile and recovery point. Use at least two distinct wallet identities so accidental cross-profile handling is detectable. Include:
Keep an independent expected inventory. The archive has 13 table arrays; backend sync protocols may count their entity stores differently. Compare relationships and values, not just a single total or balance. Make explicit which product data is excluded and how it is restored separately.
restore mode intentionally rejects a now-nonempty target;
repeat restoration uses another empty target.| Scenario | Expected result |
|---|---|
| Clean-device recovery | Same independently derived wallet identity; expected records and tested wallet behavior restored without the original installation |
| Seed/key only | Product explains missing data and offers recovery from an available backup; does not report complete recovery |
| Archive only, missing root key | Data can be inspected by an authorized holder of its passphrase, but product does not claim signing authority |
| Lost provider | Independent key and data copies remain accessible; document any dependency that still prevents recovery |
| Wrong password, truncated file or modified tag | Clear failure; no activation or modification of the existing wallet |
| Unsupported header, invalid fields or broken references | Rejected before import; original archive retained |
| Wrong profile or network | Host blocks before writes; profile switching during preview/commit cannot redirect the import |
| Nonempty restore target | Explicit rejection; no automatic deletion, overwrite or fallback to merge |
| Interrupted import or lost save acknowledgement | Product identifies uncertain/incomplete state and offers a safe retry; no false “backed up” or “restored” status |
| Old backup after new receives/spends | Product shows the recovery point and unresolved gap; stale spendable flags do not authorize a spend |
| Repeated merge/sync | No duplicated semantic transactions/outputs or revived tombstones; compare data rather than demanding zero bookkeeping updates |
| Concurrent source writes | Export uses the documented consistency procedure; no claim that sequential reads form a database snapshot |
| Low-memory device and large file | Enforced product limits, measured peak memory/time and usable failure/progress UI; no weakened cryptography |
| Browser eviction, app uninstall, device loss | Recovery succeeds through independent copies, or the exact unsupported case is clearly disclosed |
| Vendor A export → vendor B import | Same identity/network and compatible row semantics; unsupported product extensions disclosed; test the reverse direction when claimed |
| Key/share or passphrase dependency unavailable | Document the supported combinations and actual failure behavior; no circular recovery assumption |
For operator backups, additionally restore a retained database backup into a separate environment, apply only reviewed schema migrations, restore required external data and secret-store access, and measure actual recovery time/data loss. Keep monitor/background jobs disabled until their side effects and replay state have been reviewed. Replicas, backups and service health are separate evidence.
| Symptom | Safe next step |
|---|---|
| File cannot decrypt | Check original bytes and passphrase entry; do not modify KDF/header fields or promise a password reset |
| Import rejects target | Inspect network, schema and emptiness; provision a new isolated store rather than clearing the existing one |
| Data imports but wallet identity differs | Stop before activation; recover the correct key/profile and repeat preview |
| Balance/history differs | Compare full data inventory, backup time, relationships, pending state and product exclusions; do not rely on rescan as a universal repair |
| Proofs are stale or a spend fails | Use supported canonical proof/status recovery; preserve transaction IDs and avoid duplicate payment attempts |
| Merge or sync was interrupted | Preserve both sides; inspect committed state and use the tested retry path or restore the isolated target from its pre-import backup |
| Schema migration fails | Preserve the database and migration journal; follow the version-specific recovery procedure, never delete journal rows blindly |
Store real recovery evidence privately. Public records should use synthetic fixtures and redact wallet identifiers, balances and storage topology when they are sensitive. Never include keys, shares, passphrases, manager snapshots or plaintext/export files.
Recovery drill ID / date / owner:
Wallet version / source commit / exact package versions:
Runtime / device / network / backend / schema version:
Synthetic fixture ID / profile count / data classes covered:
Key recovery method / unavailable factors tested (no secret values):
Data recovery method / consistent recovery point / archive digest:
Product data included / excluded / separate restoration method:
Source device/provider dependencies removed for the drill:
Restore or merge target and authority decision:
Expected vs actual inventory / relationships / binary-data verification:
Identity / read / controlled spend / restart / retry outcomes:
Negative, resource-limit and cross-wallet scenarios with results:
Observed data-loss interval / restore duration vs declared objectives:
Unresolved gaps / user-visible limitations / remediation owner:
Cutover authorized separately? / rollback evidence:
Reviewer / next drill due / evidence location:Use “passed” only for an executed scenario with retained evidence. Keep unexecuted tests and unsupported recovery paths visible. Feed failures back into the product guidance and agent implementation brief.