What happens when a crypto wallet provider goes dark

Embedded wallets have made crypto feel like any other app. They have also concentrated a large share of the industry’s risk in a small number of providers, and very few apps have planned for one of those providers going offline.

Ask anyone who runs payments at a large merchant how many payment processors they use, and the answer is rarely one. Processors have outages, and nobody in payments treats that as a scandal. It is accepted as a fact of life, and redundancy is built around it so that when one route fails, the customer at the till never notices.

Ask the same question of a crypto app built on embedded wallets and, in our experience, the answer is usually one provider. If that provider becomes unavailable, there is often no second route for users to reach their funds, and in some cases there is no route at all.

In our view, the industry is still in the “ provider going down could never happen to us” phase of a risk it has not yet priced. What follows is CoinCover’s perspective on that risk across the market, rather than a statement about the security or practices of any individual provider.

The dependency most users never see

Embedded wallets are a large part of why crypto has started to feel like any other consumer app. A user signs in with an email address, a wallet is created in the background, and there is no seed phrase to write down or browser extension to install.

That convenience rests on a dependency most users are never made aware of. In one common approach, the private key is split into shares and encrypted inside a trusted execution environment (TEE), a locked-down enclave running on the provider’s infrastructure. When the user logs in, the enclave reconstructs the key, signs the transaction and encrypts the key again. The user never holds a backup, because under normal conditions they never need one.

The difficulty arises when conditions are not normal. If the key can only be rebuilt inside the provider’s systems, the user’s access depends entirely on those systems being available. In practice, one of the most effective ways to remove that dependency is an independent backup of the key held outside the provider, and for that backup to protect every user, it needs to be in place for every user before anything goes wrong.

Based on our review of publicly available documentation from a range of embedded-wallet providers, we discovered that where a route to recovery without the provider exists, it is usually optional, and it generally depends on the app having switched it on in advance. There is currently no industry standard or specific regulatory requirement for users of embedded wallets to have an independent backup, so whether they are protected comes down to a configuration choice that most of them will never know was made on their behalf.

This is not something providers are hiding, and the dependency is generally set out in their technical documentation for anyone who looks. Users, however, have little ability to protect themselves against this risk: there is nothing in their possession that they can independently back up or use to recover.

None of this is a criticism of how securely these providers operate. Security and availability are two different promises, and in our view users have mostly been given assurances about the first.

Scenario: a post-mortem from 2028

The following is an illustrative scenario, not a prediction. The provider, people, apps, dates, headlines and figures are all fictional, and are used only to show how a failure of this kind could spread.

Tuesday @ 09:14AM

Sam found the app the previous spring. It was a rewards app positioned as a sharper alternative to the large neobanks, offering stablecoin cashback, a well-designed card and sign-up in two minutes with an email address.

Every payday Sam moved £500 into it, and eight months later £4,000 was sitting in the app as the beginning of a house deposit. At 09:14 on a Tuesday, the login screen spun and failed, and then failed again. Across town, the app’s engineers were already on a call. Every sign-in, top-up and payout was failing, even though nothing in their own code had changed, and the provider’s status page carried a single word: “Investigating.”

WALLET PROVIDER OUTAGE FREEZES 1,000 APPS; 100 MILLION USERS UNABLE TO ACCESS FUNDS

Tuesday @ 11:00AM

Support tickets were arriving every few seconds, and the app had very little to tell anyone. It did not run the wallets itself, it had no visibility into the provider’s systems, and it had no estimate of when service would return.

Sam’s card was declined at the supermarket, with rent due on Friday.

Users began posting screenshots from block explorers showing that their money was still there on-chain. Anyone could see it, but nobody could move it.

By lunchtime the app had fallen to one star in the app stores, merchant partners were switching the card off, and investors were rereading the provider contract, which set out that the provider ran the wallets but said nothing about how they would be restored.

Wednesday @ 16:30PM

The provider’s update arrived 31 hours after the first alert. An insider with privileged access had deleted the stored key material, along with the backups of those systems. Nothing had been stolen, because there was nothing an attacker could take, but the material needed to rebuild each key no longer existed. The wallets had not been frozen; they had been lost.

WALLET PROVIDER CONFIRMS KEY DATA UNRECOVERABLE; FUNDS IN 100 MILLION WALLETS PERMANENTLY INACCESSIBLE

The most effective safeguard against this type of failure had been available all along: an independent backup, with a copy of each key held outside the provider’s systems. The provider’s own recovery option had gone offline with everything else. The app had never enabled the independent one, and nobody had asked it to.

Sam’s £4,000 would remain on the blockchain indefinitely, behind a key that could no longer be rebuilt.

During the weeks that followed

The question of who pays had no easy answer. The provider’s losses far exceeded anything it could cover, and in this scenario there was no insurance behind the wallets, while the app had lost its only product. Whether anyone would be made whole became a matter for lawyers and regulators, and even users who were eventually compensated faced a long wait and a lasting loss of trust.

The apps could not migrate their users, because migration depended on the old provider still being operational, and they could not keep them either, as card programmes and banking partners withdrew within days.

40 FINTECHS BEGIN WIND-DOWN AFTER WALLET PROVIDER FAILURE 

The effect then spread across the market. Every fintech running on an embedded wallet received the same question from its board, asking whether this could happen to them, and many found that the honest answer was yes. Apps rushed to put full backups in place, some moved to custodial providers, and the question of what happens if a critical supplier fails, which had previously sat in a risk register, became a standing item on every board and audit agenda.

For the wider public, the nuance was lost. What they saw was a hundred million people unable to reach their money in the space of a week, and many potential new users concluded that crypto was not for them.

Why the reassuring answer falls short

The standard response to a scenario like this is that these providers are well funded, well run and regularly audited, and that it simply will not happen.

That is usually right, and it is still the wrong answer. A lockout does not require a badly run provider;in some circumstances a single significant operational failure may be enough. That could be an insider, a failed funding round, a regulatory intervention, or a configuration change like the one that took one of the internet’s largest infrastructure providers offline for nearly six hours on 18 November 2025, and a large part of the web with it. Even an outage that ends well shows how exposed the industry is, and there is no guarantee the next one will end well.

Back to 2026

None of this has happened: it is September 2026, and the login still works.

We do not know that any provider will fail, and we expect that most never will. The case for independent backup does not depend on that bet. Putting an independent backup in place for every user is inexpensive before an incident and, in most cases, may be significantly more difficult after an incident has occurred.

Most industries seem to need a disaster before they build in redundancy, and we do not think crypto has to follow that pattern. Embedded wallets have made crypto feel like any other app, which is precisely why their users do not think to ask where their keys are held. The industry should not leave people like Sam to find out the hard way, and protecting them is, in our view, how the industry protects itself.

Disclaimer: This article reflects CoinCover’s views on an industry-wide risk and is not a statement about the security, practices or obligations of any individual provider. The scenario is fictional and illustrative. This article is for general information only and does not constitute legal, regulatory or technical advice.