What Is a Bitcoin Custody Test

Access Reality vs. Documented Arrangement

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

The Question Custody Testing Actually Asks

People searching for information about bitcoin custody tests are often asking something more specific than it appears. The concern isn't whether a setup was designed well or whether the right wallet was chosen. It's whether the people who would need to access bitcoin — a spouse, an executor, a trustee — can actually do so when the original holder is no longer available. That gap, between how custody looks on paper and whether it functions for someone other than the person who built it, is what a custody test examines.

Most bitcoin custody discussions focus on choices made at setup: which hardware wallet, which backup method, whether to use a passphrase. A custody test starts after those choices and asks what happens next. Specifically, it asks whether the access those choices created survives handoff to someone who didn't build the system and can't ask the person who did.

---

How a Custody Test Differs from a Security Check

Security checks and custody tests direct attention at opposite sides of the same arrangement. A security check asks whether unauthorized people can get in — whether the seed phrase is exposed, whether the hardware wallet is physically accessible to strangers, whether online accounts use weak credentials. These are questions about resistance to intrusion.

Custody testing asks whether authorized people can get in when the original holder is gone. The subject shifts from attackers to heirs, and the threat shifts from theft to permanent inaccessibility. Both matter, but they produce different failure modes. A setup that passes a bitcoin security review can still fail a custody test. The same properties that make a wallet difficult to breach — strong passphrases, undocumented derivation paths, hardware-only signing — become obstacles when the heir holding the seed phrase cannot reconstruct what the original holder knew by memory.

This distinction matters because people conducting a bitcoin custody evaluation or custody check on their own arrangements often treat security improvements as custody improvements. They're not the same operation. Strengthening one dimension can weaken the other without any visible change in how the setup appears on paper.

---

What Custody Testing Examines

A custody test examines the access paths a setup creates and whether those paths remain functional for someone other than the person who created them. Four surfaces appear repeatedly.

The first is documentation completeness. Every layer of the custody arrangement — device, PIN, seed phrase, passphrase, derivation path, platform account — requires documentation for an heir to reconstruct access. Missing one layer can render the others irrelevant. A seed phrase without a passphrase notation, or with a passphrase notation but no record of which wallet software was used, creates an access path that exists on paper but doesn't function in practice.

The second surface is documentation accuracy over time. Documentation describes the arrangement as it existed when written. Hardware wallets get replaced. Platforms change interfaces or go offline. Passphrases get updated after the original documentation was created. The gap between what was written and what currently exists widens as time passes and neither the documentation nor the heir can know how wide it has become.

The third is knowledge held only by the original holder. Some custody arrangements depend on the holder's memory for a layer the documentation doesn't capture. A passphrase derived from a personal formula. A PIN based on a date with a specific offset the holder applied instinctively. These mental dependencies are invisible to anyone reviewing the documentation because they don't appear in it.

Fourth is platform-specific behavior. Wallet software, hardware device firmware, and exchange account recovery procedures change. An heir following documented steps from 2021 on a platform that updated its interface in 2024 encounters a different process than the one described. The documentation is accurate to when it was written; what it describes no longer matches what the system presents.

---

Why Setup Correctness Does Not Predict Access Outcomes

A custody arrangement can be correctly designed and still fail to transfer access. This is one of the less obvious properties of bitcoin custody, and it explains why evaluating setups for correctness doesn't answer the question a custody test asks.

Design correctness reflects decisions made at a point in time. Whether those decisions produce working access depends on what happens afterward — whether the documentation stays current, whether the devices remain functional, whether the platforms involved remain accessible, whether the heir can interpret what they've been given without any guidance from the person who built it. None of these factors are part of the original design decision.

An executor discovers that a deceased holder's hardware wallet is present, the seed phrase backup is in the estate documents, and a note describes a passphrase. The documentation looks complete. The seed phrase restoration attempt produces an empty wallet because the passphrase in the note was an early version the holder later changed and never updated. The design was correct. The documentation was accurate when written. The access outcome reveals a gap that no review of the original setup would have exposed.

---

The Role of the Person Performing the Test

Who attempts access changes what a custody test reveals. A holder testing their own setup brings knowledge the documentation doesn't contain — they remember the passphrase, know the wallet software, can interpret an ambiguous notation in their own handwriting. That implicit knowledge fills gaps the documentation leaves open without either party noticing the gap exists.

When someone other than the holder attempts access, those gaps become failures. The heir reads the same documentation and encounters the same notations, but without the holder's memory to fill in what the documentation omits. A custody test conducted by the holder tends to confirm the setup works. The same test conducted by someone who would actually need it — a spouse, an attorney, an executor — exposes what the holder's knowledge was quietly supplying.

This is why custody testing is fundamentally a perspective problem. The relevant question isn't whether the holder can access their own bitcoin. It's whether someone without the holder's knowledge can.

---

Where the Gap Between Documentation and Access Appears

Documentation gaps and access failures don't always correlate the way they appear. Some arrangements with sparse documentation work because the pieces present are sufficient. Others with extensive documentation fail because one undocumented dependency — a passphrase, a PIN, a platform-specific recovery step — blocks everything else.

The gap most frequently surfaces at the intersection of what the holder knew by memory and what the documentation assumes an heir will also know. Holders with technical familiarity often write documentation for an audience with similar familiarity. The heir who receives it may be a spouse with no bitcoin experience, an attorney encountering hardware wallets for the first time, or an adult child who has heard about bitcoin but never held a hardware device. The documentation's assumptions about prior knowledge become invisible barriers.

A second gap location is temporal distance between documentation and access attempt. The longer between when documentation was written and when an heir needs it, the more the world around the documentation has changed. Platforms evolve. Wallet software updates. Hardware devices reach end-of-life and lose manufacturer support. The documentation describes a system that existed; the heir encounters a system that has since changed.

---

What Custody Testing Exposes That Reviews Do Not

Document reviews examine what exists — whether a seed phrase was written down, whether instructions are present, whether account details are recorded. That review can be thorough and still miss the failures a custody test surfaces, because reviews assess presence rather than function.

Custody testing asks whether what exists actually works for someone attempting access without the holder's assistance. A seed phrase is present: does it restore the correct wallet with the software the heir is likely to use? Instructions are recorded: do they describe a process that still matches what the platform currently presents? Account credentials exist: does two-factor authentication require a device or phone number the heir doesn't have? The documentation passes a review in each case. The access attempt fails.

This is the specific failure surface custody testing exposes — not missing documentation, but documentation that exists and doesn't function. The gap is between recorded information and operational access, and it's invisible until someone who isn't the holder actually tries.

---

Custody Testing as a Category

Custody testing names a specific question: can the people who would need access actually get it? That question is distinct from security review, which asks whether unauthorized access is blocked. It's distinct from documentation review, which asks whether information exists. It's distinct from setup evaluation, which asks whether design decisions were sound.

Each of those evaluations addresses something real. None of them answers the custody test question, because none of them ask whether the arrangement functions for someone other than the holder under conditions the holder won't be there to clarify. Custody testing occupies that specific position — after setup, after documentation, after security review — and asks whether what was built actually transfers.

The failure mechanics it reveals are consistent across arrangement types: hardware wallets, exchange accounts, multisignature setups, and paper wallets all surface the same basic pattern. The holder's knowledge, present at setup and invisible to everyone else, quietly fills the gaps that documentation leaves open. When the holder is gone, those gaps become the story.

---

Summary

A bitcoin custody test asks whether the people who would need to access bitcoin can actually do so when the original holder is unavailable. That question is distinct from security evaluation, documentation review, and setup assessment. Each of those addresses something real; none of them answers the custody test question.

The failure surface custody testing exposes is the gap between what documentation records and what actually works for someone attempting access without the holder's knowledge. That gap appears at the layers the holder's memory was quietly supplying — passphrases not captured, platform behavior that changed, notation readable only to the person who wrote it. Documentation reviews don't surface these gaps because they assess presence, not function.

Custody testing occupies the position after all setup and documentation work is done and asks whether the arrangement transfers. The holder's knowledge, invisible at every prior stage, becomes visible at exactly that moment — as the thing an heir discovers they needed and don't have.

System Context

Bitcoin Custody Degrades Over Time

Bitcoin Depends on Someone Who Doesn't Care

Assumption Surfaces Register

← Return to CustodyStress