Blockchain.info Web Wallet (2013): Silent Login Failure, Unresolved After 3 Months
BlockedCustodial platform became inaccessible — the holder had no independent key control.
In late 2013, a user created a Bitcoin wallet on blockchain.info, then one of the most popular web-based custodial platforms. The wallet remained accessible during the active period, but when the user later attempted to log in via blockchain.com (the rebranded successor platform), the authentication process failed silently. The login page would load briefly and then return to an unchanged state—no error message, no rejection notice, no confirmation of success. The user possessed both the wallet ID and password, credentials that historically should have been sufficient to regain control of funds on the platform.
During the wallet's operational years, the user did not export the wallet JSON file or record the seed phrase—a pattern common in Bitcoin's early adoption era (2011–2015) when backup procedures were neither standardized nor widely emphasized by web wallet providers. This oversight left no alternative recovery mechanism once the platform's primary authentication channel became inaccessible.
The user contacted blockchain.com support, but the institutional response was evasive. Support indicated they were "working on it," yet no substantive resolution materialized across more than three months of waiting. Community troubleshooting suggestions focused on client-side remedies (disabling ad blockers, clearing cache, trying different browsers), but the source record does not confirm whether these were attempted or effective. The underlying failure appeared structural—an authentication or data-layer issue on the platform's infrastructure itself, not a browser compatibility problem.
This case illustrates a critical distinction: possession of a passphrase or password alone does not guarantee recovery when third-party platforms control the data layer. Without a locally exported key file or seed phrase, users are entirely dependent on the provider's willingness and ability to restore access to legacy accounts.
| Stress condition | Vendor lockout |
| Custody system | Exchange custody |
| Outcome | Blocked |
| Documentation | Partial |
| Year observed | 2013 |
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.