Samourai Wallet Balance Lost After Android Downgrade — Recovered via Older APK
SurvivedCustodial platform became inaccessible — an alternate access path or process existed.
The user maintained a deliberate hybrid custody model: cold storage via Tails-generated paper wallets and a Digital Bitbox hardware wallet for larger holdings, with Samourai Wallet configured as an everyday mobile spending interface. The seed phrase and associated password were backed up across two password manager instances and one physical paper copy—a documented and seemingly redundant safety structure. The user had successfully restored Samourai three times prior without incident. When the user downgraded their Android 9.
0 Beta device to stable release in order to improve system stability, Android required a factory reset. Upon restoring Samourai with the identical seed phrase and password credentials from the password manager, the wallet displayed zero balance and zero transaction history. The blockchain independently confirmed the deposit transaction was valid and unspent. Multiple restoration attempts using the same credentials produced identical blank results.
During the initial troubleshooting phase, the user observed an anomalous transaction behavior: change from a spend had been sent to a non-segwit address instead of the expected segwit change address, prompting the user to review historical Samourai vulnerabilities, particularly a 2017 derivation issue. The user engaged with the Bitcoin community seeking diagnosis and assistance. After approximately twelve months of troubleshooting, the user downloaded an older version of Samourai Wallet via the Aptoide third-party Android application repository. The legacy APK immediately displayed the full balance and transaction history.
The user then performed a controlled transfer of the recovered Bitcoin directly to the Digital Bitbox hardware wallet, securing the funds under that device's PIN and passphrase. The root cause—whether a wallet derivation path algorithm change, Android version incompatibility, or a software regression in the contemporary release—remained unresolved.
| Stress condition | Vendor lockout |
| Custody system | Software wallet |
| Outcome | Survived |
| Documentation | Partial |
Why custodial Bitcoin fails differently than self-custody
Exchange custody transfers the custody problem from the holder to the institution. The holder no longer needs to manage seed phrases, maintain hardware, or understand cryptographic concepts. They need only to maintain their account. This simplicity has a cost: the holder no longer controls the private keys. Access depends entirely on the continued operational, financial, and regulatory health of the exchange.
Cases in this archive show that exchange failures cluster around specific event types: bankruptcy and insolvency, regulatory seizure, geographic sanctions, and account-level access failures (lost 2FA, forgotten email credentials). Each event type has a different recovery path and a different timeline. Bankruptcy proceedings typically take 6-24 months and produce partial recovery. Regulatory seizure timelines depend on legal process. Account access failures may be resolvable through platform support or may not.
The distinguishing feature of vendor lockout cases is that recovery — when it occurs — happens through processes the holder did not design and cannot control. They become claimants in a process rather than holders of an asset.
The primary protection against vendor lockout is not using a vendor for custody beyond what is needed operationally. Holdings intended to be stored long-term are most exposed to institutional risk. Exchange custody is well-suited for active trading and conversion; it is poorly suited for long-term storage of significant value. Moving Bitcoin off exchange into self-custody eliminates platform dependency at the cost of taking on personal custody responsibility.
Translate