Coordination & Dependency Surfaces in Bitcoin Custody

Where Bitcoin custody systems depend on things their operators do not see.

This reference is published by CustodyStress, an independent Bitcoin custody stress test that produces reference documents for individuals, families, and professionals.

A spouse tries to access Bitcoin after their partner dies. The seed phrase is in the safe. But recovery also requires a passphrase the spouse never knew about, a two-factor code sent to a phone number that's been disconnected, and a hardware wallet running firmware that hasn't been updated in three years. The seed phrase alone isn't enough. The system depends on things that were never written down — because the holder didn't think of them as part of the system.

This is what a hidden dependency looks like. The custody arrangement appeared simple. Underneath, it relied on email accounts, phone numbers, vendor support, specific software versions, and the continued availability of people who may not even know they're involved.

Common questions that surface include:

– "What does this setup actually depend on beyond the seed phrase?"

– "What happens if the hardware wallet company goes out of business?"

– "Would anyone else even know all the steps to recover this?"

This reference traces the dependency surfaces and coordination requirements that exist beneath the visible layer of a Bitcoin custody system. It examines what the system actually depends on, where those dependencies hide, how they degrade, and what happens when coordination between components or people fails under stress.

Includes (common dependency surfaces):

– Email, phone-number, and 2FA dependencies that outlive the holder

– Passphrases, derivation paths, and wallet settings not captured in backups

– Multisig coordination failure when cosigners disappear or die

– Vendor and firmware dependencies and tool discontinuation risk

– Untested recovery procedures and instruction trust failure

Hidden Dependencies Below the Visible Layer

Custody depends on more than keys and backups. The observations in hidden dependencies on email, phone, and accounts trace the infrastructure that custody relies on without explicit acknowledgment. An email account controls password resets. A phone number receives two-factor authentication codes. A cloud service stores an encrypted backup. A physical location holds a metal plate. Each of these is a dependency. The holder uses them so routinely that their existence as dependencies goes unnoticed. When one fails — an email account is locked, a phone number is ported, a cloud service shuts down — custody can fail even when the obvious components remain intact.

Wallet interfaces hide the configuration details recovery actually depends on. The patterns in hidden dependencies not shown in wallet interfaces show how the user-facing screen displays a balance and send/receive buttons while obscuring the derivation path, passphrase configuration, account structure, and specific technical settings that make the bitcoin accessible. The interface was designed for simplicity. The complexity it hides does not stop existing because it is not displayed. The wallet interfaces that mask custody risk extend this observation: green icons and status indicators suggest safety that may not match what is actually happening underneath. The dashboard displays what is true right now. It does not display what the system depends on or what will happen when a dependency fails.

Custody arrangements also depend on people whose involvement is required but whose interest in the outcome may be minimal. The dependencies on uninvested third parties memo traces this misalignment: the holder has everything at stake. The third party — a cosigner, a backup holder, a technical advisor — may have nothing at stake. No financial interest, no reputational risk, no consequence if things go wrong. The dependency exists regardless of whether the third party cares about it. The holder assumes ongoing cooperation because the arrangement was established cooperatively. Whether that cooperation persists years later, under different circumstances, with different incentives, is a separate question.

Single Points of Failure and Illusory Redundancy

A custody system can appear to have multiple recovery paths while depending on a single element. The observations in identifying single points of failure describe how systems with multiple wallets, multiple backups, and multiple people involved can still collapse to a single dependency under stress. The single point of failure may not be a key or a device. It may be a password, a location, a relationship, or a piece of knowledge that connects the other components. During normal operation, the redundancy appears real. Under stress, the paths converge.

The testing recovery paths beyond backup copies examines whether multiple recovery routes represent distinct paths or whether they collapse into the same dependencies. Two backups stored in different locations still depend on the same passphrase. Three hardware wallets that all require the same PIN are three devices with one point of failure. The question is whether recovery routes are genuinely separate or whether they share hidden common elements. That determines whether redundancy is real or only appears real.

Geographic distribution creates its own dependency patterns. The observations in geographic backup distribution and access planning trace what happens when backups are spread across physical locations. Distance creates resistance to theft by making single-location compromise insufficient. Distance also creates access friction — the holder or their heirs need to reach multiple locations, sometimes under time pressure, sometimes across jurisdictions. The same distribution that improves one property of the system degrades another.

Complexity, Assumptions, and Blind Spots

Additional complexity does not always add security. The patterns in when added complexity reduces security describe how the relationship between complexity and protection is not linear. At some point, additional steps, additional keys, or additional components introduce failure modes that exceed the protection they provide. The holder who adds a passphrase, a multisig arrangement, a time-locked recovery path, and geographic distribution has built a system with many defenses. They have also built a system with many surfaces where something can go wrong. The point at which complexity begins to reduce rather than increase actual protection is not always visible to the person building the system.

Every custody arrangement rests on assumptions. Some are explicit — this backup is stored here, this person knows that information. Others are implicit — the backup is still readable, that person can still be reached, the hardware wallet manufacturer still exists. The hidden assumptions in custody arrangements memo traces what happens when assumptions that were true at setup time become false over months or years. A backup that was verified at creation is assumed to remain intact. A person who agreed to hold a key is assumed to remain available. The assumptions go untested because the holder does not think of them as assumptions. They think of them as facts.

Blind spots differ from known gaps. The observations in common blind spots in self-managed custody describe risks the holder cannot evaluate because they do not know those risks exist. A known gap is something the holder is aware of but has not addressed. A blind spot is something the holder has no awareness of. The self-reliance that defines self-custody creates a structural problem: the person evaluating the system is the same person who built it. They cannot see what they do not know to look for. External review might surface these blind spots. Self-custody arrangements typically lack external review. The holder builds, operates, and evaluates the system — and the evaluation inherits every limitation the builder had when making the original decisions.

Degradation, Entropy, and Time

Custody arrangements do not remain static. The how custody arrangements degrade without maintenance memo traces the natural processes that erode custody integrity over time. Hardware ages. Firmware becomes unsupported. Software is discontinued. Written instructions reference products that no longer exist. Relationships change. People move. People die. The arrangement that represented the holder's best thinking at one moment in time encounters conditions that did not exist at that moment.

The entropy and system degradation over time describes this tendency toward disorder. Without continuous maintenance — re-verifying backups, updating documentation, confirming that people and locations remain accessible — organized custody structures drift toward inaccessibility. The drift is not caused by a specific event. It is caused by the accumulation of small changes, each individually insignificant, that collectively transform a functional system into a brittle one. This happens silently, gradually, and without warning.

The maintenance problem is compounded by the absence of external signals. A bank account that requires attention generates notices. A brokerage account produces statements. A hardware wallet sitting in a safe produces nothing. The holder receives no reminder that the firmware is three versions behind, that the backup location has changed ownership, or that the person who was supposed to know the passphrase has moved and changed their phone number. The system degrades in silence. The holder discovers the degradation only when they attempt to use the system under conditions it was not built for.

Coordination Across People and Components

Technical setup can be complete while human coordination remains incomplete. The coordination gaps between technical and human layers memo describes what happens when all the cryptographic components exist but the people who need to work together cannot — because they do not know each other, cannot reach each other, or do not know what they need to do together. The keys work. The humans do not. Coordination involves knowledge distribution: who knows what exists, who knows where to find it, who knows how to use it, and whether those people can reach each other when access is needed.

Multisignature arrangements create explicit coordination requirements. When a cosigner becomes unavailable, the arrangement may lose the cooperation it depends on. The observations in cosigner disappearance in multisig arrangements describe what happens when a required participant leaves, loses interest, or becomes unreachable. The keys still exist somewhere. The person who holds them does not respond. The arrangement that distributed control for security now distributes risk across people who may not cooperate.

The cascading version of this problem appears in cascading failure when a cosigner dies: a holder dies, leaving assets in a multisig arrangement that requires cooperation from other keyholders. Before the estate can act, one of those required cosigners also dies. The arrangement now faces two simultaneous absences. The coordination problem has compounded. Each delay increases the probability of further degradation in the coordination network the system depends on. Time is not neutral in coordination-dependent systems. The longer a system waits for human action, the more likely the humans it depends on will become unavailable through their own life events.

Vendor Dependencies and the Supply Chain

Custody tools come from vendors. Hardware wallets come from manufacturers. Software comes from developers. Backup solutions come from service providers. The holder's setup inherits whatever instability exists in the vendors they depend upon, as documented in vendor dependency and hardware or software failure. The holder controls their keys. They do not control the companies that make the tools for managing those keys. A manufacturer that discontinues a product, a developer who abandons a project, or a company that goes bankrupt can leave the holder with tools that no longer receive updates, support, or compatibility fixes.

Firmware represents a specific form of vendor trust. The patterns in hardware wallet firmware and supply chain risk trace the dependency on code that runs inside a device the holder physically possesses but cannot independently verify. The firmware handles key generation, transaction signing, and display of transaction details. The security model requires that this firmware operates as the manufacturer claims. The holder trusts the firmware because they trust the manufacturer. That trust is a dependency. It does not appear in any backup plan or recovery document, but it underlies every operation the device performs.

Outsourcing custody to a third-party provider changes the dependency surface rather than eliminating it. The observations in outsourcing custody and counterparty risk describe how moving Bitcoin to a custodial provider substitutes one set of risks for another. The holder no longer faces the operational burden of key management. They now face counterparty risk — the possibility that the provider fails, restricts access, is compromised, or changes terms. The risks are different in character. They are not necessarily smaller in magnitude. The exchange collapses, the custodian freezes withdrawals, the platform changes its terms of service — each of these transfers control from the holder to circumstances the holder cannot influence. Self-custody risk is operational. Custodial risk is institutional. The dependency surface shifts. It does not shrink.

How This Shows Up in Real Recovery Attempts

Observed questions that surface during actual recovery scenarios include:

– "We have the seed phrase. Why won't it restore the wallet?"

– "Where is the passphrase documented?"

– "Which app or device did they use to create this wallet?"

– "Who is the cosigner and how do we reach them?"

– "Do we need an old firmware version to sign?"

Testing, Verification, and the Socio-Technical Gap

Recovery procedures that have not been tested carry unknown failure modes. The dry run testing before recovery is needed memo describes the gap between believing a recovery process works and verifying that it works. Testing under controlled conditions reveals mismatches between documentation and reality, between assumption and fact, between the holder's memory and the system's actual configuration. Untested procedures may function correctly. They may also contain errors that only become visible during actual recovery — when the stakes are highest and the conditions are worst.

Instructions that exist can still fail to produce action. The patterns in when valid instructions are treated with suspicion describe what happens when custody instructions are present, readable, and apparently complete — but the person encountering them hesitates to act. The hesitation is not caused by confusion about what the instructions say. It is caused by doubt about whether the instructions can be relied upon. The instructions may be outdated. They may reference a wallet that has been migrated. They may have been written by someone who is now dead and cannot confirm their validity. The failure is not informational. It is trust-based.

Custody is not a purely technical system. The observations in human factors in custody system failures trace the gap between technical correctness and operational outcomes. A system can be cryptographically sound, properly configured, and fully backed up — and still fail when the people who need to interact with it cannot interpret it, coordinate around it, or act on it under stress. The technical layer and the human layer operate according to different rules. The technical layer is predictable: the same inputs always produce the same outputs. The human layer is not. Fear, grief, confusion, mistrust, and fatigue all affect how people interact with custody systems, and none of these show up in any technical specification.

Index of Memos in This Category

The following memos document individual dependency patterns, coordination requirements, degradation vectors, and verification gaps across custody systems. Each memo examines one surface where system behavior differs from what the holder expected. Some memo titles are phrased as questions for search discoverability; the documents remain descriptive.

← Return to CustodyStress

For anyone who holds Bitcoin — on an exchange, in a wallet, through a service, or in self-custody — and wants to know what happens to it if something happens to them.

Start Bitcoin Custody Stress Test

$179 · 12-month access · Unlimited assessments

A structured, scenario-based diagnostic that produces reference documents for your spouse, executor, or attorney — no accounts connected, no keys shared.

Sample what the assessment produces