Blockchain.info Legacy Wallet: Mnemonic Present, Backup File Present—Funds Inaccessible
BlockedCustodial platform became inaccessible — the holder had no independent key control.
In 2015, the user created a Blockchain.info wallet and purchased Bitcoin, then implemented two backup strategies: a 17-word legacy mnemonic phrase and an encrypted wallet.aes.json file exported directly from the platform. The dual-backup approach was intended to provide redundancy and recovery assurance.
Approximately seven years later, in 2022, the user attempted to access the account but encountered password rejection. Troubleshooting revealed the root cause: an operating system keyboard layout setting was interfering with password entry. Using the 17-word mnemonic phrase as a legacy login credential, the user regained account access.
However, the recovered account displayed zero balance. A single address appeared in the wallet interface with no transaction history and no on-chain balance recorded. The user then attempted to import the wallet.aes.json backup file using Blockchain.info's import function, encrypting it with their login credentials. The import completed without error messages, but the wallet continued to display 0.00 BTC.
Support requests to Blockchain.info were not answered. The incident remained unresolved at the time of posting. The underlying cause could not be definitively established. Possible explanations included: the wallet.aes.json file may have corresponded to an address that never received funds; a data inconsistency existed between the mnemonic phrase and the wallet file; Blockchain.info experienced platform-side data loss or corruption; or the user made an error during the backup process itself. The case highlighted a critical assumption failure: possession of an encrypted wallet file plus its encryption password was insufficient for recovery on Blockchain.info, exposing fundamental opacity in the platform's wallet architecture and the unreliability of relying solely on platform-provided backup mechanisms.
| Stress condition | Vendor lockout |
| Custody system | Exchange custody |
| Outcome | Blocked |
| Documentation | Partial |
| Year observed | 2015 |
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.