What Happens When Your Wallet Provider Goes Down?

Institutional custody has a dependency problem that most operators never see coming, until they find themselves inside an outage with no clear path to resolution.

During normal operations, the risk stays completely invisible. Transactions clear on schedule, approvals route correctly, dashboards load without issue, and the underlying architecture goes unexamined precisely because everything appears to be working. There is no forcing function to ask harder questions about what happens when it doesn't — until something breaks.

That changes the moment the provider goes offline.

The Provider as Access Point

To understand the real exposure here, it helps to understand how most institutional wallet arrangements are actually structured under the surface.

In many deployments, the provider doesn't simply store keys on behalf of the institution — it actively mediates every operation that requires them. Signing a transaction, approving a transfer, querying a balance: all of it routes through provider infrastructure before anything happens. The institution interacts with an interface that feels like direct control, while the provider operates the underlying execution layer that makes that control possible.

This architecture is not inherently flawed, and there are legitimate reasons it exists. It enables sophisticated access controls, detailed audit trails, and the kind of policy enforcement that regulated institutions require. But it also creates a single point of dependency that most custody agreements don't address in any meaningful way.

When the provider's infrastructure becomes unavailable for any reason, access pauses with it — not because assets have moved or been compromised in any way, but because the keys required to reach them are not under the institution's direct control. The assets are still there, sitting on-chain exactly where they should be. The institution simply has no way to touch them.

This is the operational risk that standard custody arrangements consistently obscure.

What Downtime Actually Looks Like

Provider unavailability doesn't always arrive the same way, and each form carries a meaningfully different risk profile that institutions should understand before they encounter it.

Planned maintenance presents the lowest immediate risk on its face, scheduled downtime comes with advance notice, giving institutions time to pre-position and adjust. But low risk is not no risk. If planned maintenance happens to coincide with a market event requiring immediate execution, the inability to transact during even a brief window can produce consequences that are anything but brief.

Unplanned outages are the harder and more common scenario. Infrastructure failures, distributed denial-of-service attacks, and internal incidents arrive without warning and carry no guaranteed recovery window. The institution's ability to respond to market conditions, honor counterparty obligations, or act on internal risk thresholds is simply suspended for an indeterminate period — with no reliable estimate of when normal operations will resume.

Business discontinuity is the scenario that receives the least planning attention and carries the most structural risk over time. When a provider is acquired by a larger entity, enters insolvency proceedings, or shuts down operations entirely, the institution's assets remain on-chain and are not at risk of disappearing — but access pathways can become legally or technically frozen while proceedings unfold. Recovery in this scenario is not primarily a technical problem. It becomes a legal and operational one, and resolution can take months longer than any institution would want to wait.

Despite their differences in cause and likelihood, each scenario produces the same immediate operational result: the institution cannot transact.

The Question That Exposes the Gap

There is a straightforward way to assess your actual exposure before you ever need to act on it. Ask your wallet provider this question directly:

If your platform becomes unavailable for 72 hours, how does our team access our assets independently?

The answer — and the confidence with which it's delivered — will clarify the real nature of your access arrangement more than any contract language will.

If the response requires provider involvement to execute, if recovery depends on their systems coming back online, their team intervening on your behalf, or a process they control and you can't replicate independently, then the institution does not have sovereign access to its own assets. It has delegated access, contingent on a third party's continued availability, operational health, and willingness to assist.

That distinction is easy to overlook during normal operations, but it matters most precisely when it is hardest to act on — during an incident, under time pressure, with limited information about when the situation will resolve.

Institutions that have genuinely addressed this risk maintain one of two capabilities: they hold their own signing keys directly, so that no external party needs to be involved in executing a transaction, or they maintain documented access paths — technical and legal — that function independent of provider status. Either approach requires deliberate architecture decisions made well in advance. Neither happens by default, and neither can be improvised after an outage has already begun.

Continuity Is an Architecture Decision

The instinct during an outage is to treat the situation as a support problem — open a ticket, escalate through the right channels, and wait for the provider to restore normal service. For many routine outages, that instinct is correct and the situation resolves itself within a manageable timeframe.

The problem is that this instinct also shapes how recovery is planned in advance — reactively, and with the assumption that the provider will always be the one to restore access when something goes wrong. For some outage scenarios, that assumption holds. For others, it fails entirely at the moment the institution needs it most.

Recovery from a wallet provider outage that the provider cannot or will not resolve is not a support escalation. It is a fundamental infrastructure capability — one that has to be designed, documented, and tested before a failure occurs, not assembled from scratch in response to one.

The institutions that navigate these events without material disruption to their operations share a common characteristic: they made one foundational architecture decision in advance. They separated key custody from operational access, ensuring that their ability to sign and execute transactions does not depend on any single provider remaining available. They can operate independently when they need to, because they built that capability into their infrastructure deliberately and tested it before they needed it.

The question is not whether your provider will experience downtime, every provider will, at some point and in some form. The question is whether your access model is built to survive it when they do.