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 does not. Until something breaks.

The provider as access point

In many deployments, the provider does not 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. It enables sophisticated access controls, detailed audit trails, and the policy enforcement that regulated institutions require. But it also creates a single point of dependency that most custody agreements do not 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, 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.

What downtime actually looks like

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 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 cannot 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.

Institutions that have genuinely addressed this risk maintain one of two capabilities: they hold their own signing keys directly, so 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, and wait for the provider to restore normal service. For many routine outages that instinct is correct. The problem is that this instinct also shapes how recovery is planned in advance, reactively, with the assumption that the provider will always be the one to restore access. 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.

The institutions that navigate these events without material disruption share a common characteristic: 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. 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.