Blockchain.com Wallet Zero Balance: Seed Phrase and Backup File Present, Funds Inaccessible
IndeterminateCustodial platform became inaccessible — whether funds were recovered is not documented.
In late 2015, the user rory4ever created a Bitcoin wallet using Blockchain.info (the platform's name before rebranding to Blockchain.com) and deposited approximately 0.3 BTC. At the time, they created a comprehensive backup including the mnemonic seed phrase and an encrypted wallet.aes.json file protected by their password. The laptop containing the wallet remained in the user's physical possession but became inaccessible for reasons not fully specified in available records.
In November 2018, approximately three years later, rory4ever attempted to recover the funds. Using the original wallet ID and password, they successfully authenticated to Blockchain.com and accessed the wallet interface. However, the account displayed a zero balance and contained zero transaction history, showing only a single Bitcoin address with no on-chain activity recorded.
The user then attempted recovery using Blockchain.com's legacy wallet import feature, uploading the wallet.aes.json file and decrypting it with their original password. The import process succeeded and generated a new wallet ID, but this imported wallet also displayed a zero balance.
The discrepancy between the successful authentication, possession of valid backups, and zero balances across both the original and imported wallet IDs suggested either: (1) the original deposit was sent to an imported address not covered by the mnemonic seed backup; (2) funds were moved after initial backup creation; (3) a platform-level issue rendered the wallet inaccessible; or (4) address format incompatibilities (compressed versus uncompressed keys) masked the true holdings. Community members recommended checking email records from purchase exchanges, using third-party tools like wallet-key-tool to decrypt the JSON file directly, querying blockchain explorers for the original address, and reviewing wallet settings to distinguish between native and imported addresses. No resolution was documented.
| Stress condition | Vendor lockout |
| Custody system | Exchange custody |
| Outcome | Indeterminate |
| Documentation | Partial |
| Year observed | 2018 |
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