Bitcoin Recovery Examination

Recovery Procedure Testing and Documentation Review

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

Described Versus Demonstrated

A custody system includes documentation. The documentation describes how to recover access if something goes wrong. The seed phrase is in a certain location. The PIN is written down somewhere. Instructions exist for restoring a wallet. The recovery path is described.

A described path is not a demonstrated path. The description says recovery is possible. No one has tried it. No one knows if the steps work. No one knows if the credentials can be found. No one knows if the devices function. The path exists on paper. Whether it exists in practice remains unknown.

This memo describes what happens when a bitcoin recovery test is performed. It traces the difference between documented procedures and executable capability.

---

Described Versus Demonstrated

A described recovery path is a set of written steps. The documentation says: the seed phrase is in the safe deposit box, the PIN is in the password manager, the backup device is in the filing cabinet. The steps are recorded. The path is described.

A demonstrated recovery path is one that has been executed. The seed phrase was located, entered into a device, and used to access the wallet. The steps were performed. The path was demonstrated.

The difference between described and demonstrated is whether execution occurred. A described path is a claim. A demonstrated path is evidence. Described paths may work. They may not. Knowledge of recoverability exists only when a recovery path has been exercised under actual conditions.

---

What Documentation Contains

Recovery documentation typically contains locations and credentials. The seed phrase is here. The password is there. The backup device is in this drawer. The instructions say to do these things in this order.

Documentation captures what the holder knows. The holder set up the system. The holder knows where things are. The holder writes it down. The documentation reflects the holder's understanding at the time of writing.

Documentation does not capture what it does not know. The holder may have forgotten something. The holder may have assumed something obvious that is not obvious to others. The holder may have described a step without describing a dependency that step requires.

---

What Documentation Omits

Documentation often omits dependencies. A step says: "Open the Ledger Live app." The documentation does not say: the app requires installation, the app requires updates, the app requires the device to be connected, the device requires a charged battery. These dependencies are assumed. They are not written.

Documentation often omits timing. A step says: "Contact the exchange." The documentation does not say: the exchange takes three weeks to process death claims, the exchange requires specific documents, the exchange may have changed its policy since the documentation was written.

Documentation often omits knowledge. A step says: "Enter the seed phrase." The documentation does not say: seed phrases have a specific format, the words have a specific order, entering them incorrectly produces a different wallet or an error. The step assumes knowledge the executor may not have.

---

The Gap Between Paper and Practice

A gap exists between what documentation describes and what execution requires. The documentation provides a map. Execution requires navigating the territory. The map may be accurate. The map may be incomplete. The map may be outdated.

The gap is invisible until execution. Reading documentation feels like understanding the recovery path. The steps look clear. The locations are named. The credentials are listed. Everything appears to be in order.

Execution reveals whether the map matches the territory. The seed phrase is supposed to be in the safe deposit box. Is it there? The PIN is supposed to be in the password manager. Is the password manager accessible? The backup device is supposed to work. Does it power on?

Each step in the documentation becomes a question during execution. The gap is the space between what the documentation claims and what execution finds.

---

What a Bitcoin Recovery Test Reveals

A bitcoin recovery test exercises the documented path. Someone attempts to execute the steps. The test reveals whether the path works.

The test reveals whether credentials can be located. The documentation says where they are. The test determines whether they are actually there. Credentials move. Credentials get discarded. Credentials get stored differently than remembered. The test finds what exists, not what was described.

The test reveals whether devices function. The documentation references a hardware wallet. The test determines whether the wallet powers on, whether it accepts the PIN, whether the firmware is current. Devices age. Batteries drain. Components fail. The test exposes device state.

The test reveals whether steps can be completed. The documentation lists actions. The test determines whether the person executing can perform those actions. Steps require knowledge. Steps require capability. Steps require access to services and systems. The test exposes what is executable and what is blocked.

---

Execution Surfaces Dependencies

When someone attempts to test bitcoin recovery, dependencies surface. Dependencies are things the path requires that the documentation did not make explicit.

The recovery path requires software. The software requires installation. Installation requires internet access. Internet access requires a working device. Each requirement is a dependency. The documentation mentioned the software. It did not mention the chain of requirements leading to it.

The recovery path requires a person. The person requires availability. Availability requires the person to be reachable, willing, and capable. The documentation mentioned the person. It did not mention that the person might be traveling, might have changed phone numbers, or might have forgotten the arrangement.

Dependencies are invisible in documentation. They become visible during execution. The test surfaces them by encountering them.

---

Execution Exposes Assumptions

Documentation embeds assumptions. The holder wrote the documentation. The holder made assumptions about what the reader would know, what the reader could do, and what conditions would exist at recovery time.

Assumption: The reader knows what a seed phrase is. Reality: The executor may never have heard the term. The documentation says "enter the seed phrase." The executor does not know what that means.

Assumption: The password manager is accessible. Reality: The password manager requires the master password. The master password is not documented. The documentation assumed the reader would have it.

Assumption: The exchange still operates the same way. Reality: The exchange changed its policies. The process described no longer matches the current process. The documentation assumed stable conditions.

Each assumption is a potential failure point. The test exposes assumptions by encountering situations where they do not hold.

---

Partial Execution

A bitcoin recovery test may partially succeed. Some steps work. Others do not. The path proceeds to a point and then stops.

The seed phrase is located. The device is found. The PIN works. The wallet opens. The test proceeds. Then a transfer requires two-factor authentication. The authentication code goes to a phone number that no longer exists. The path stops.

Partial execution reveals where paths break. A path may be mostly executable with a single blocking dependency. The test identifies the block. Without the test, the block remains unknown.

A path that is 90% executable is not an executable path. Access resolves to whether movement is possible or blocked under the conditions encountered. Partial execution reveals how close a path comes to working and where it fails.

---

Who Performs the Test

The person performing a bitcoin recovery test affects what the test reveals. Different people have different knowledge, different capabilities, and different access.

If the holder performs the test, the holder brings knowledge the documentation omits. The holder knows which drawer the filing cabinet refers to. The holder knows the password manager master password. The holder can complete steps that depend on implicit knowledge. The test reveals less than it would for someone else.

When someone other than the holder performs the test, different gaps become visible. The executor does not have the holder's implicit knowledge. The executor encounters gaps that the holder would skip over. The test exposes what the documentation actually provides versus what the holder's presence provides.

Tests performed by different actors reveal different aspects of the recovery path depending on knowledge, access, and available context.

---

Timing and Decay

A bitcoin recovery test produces results that are time-bound. The test reveals the state of the recovery path at the moment of testing. That state changes.

Devices degrade. A device that works today may not work in three years. Batteries die. Storage fails. Firmware becomes incompatible. A path that is executable now may not be executable later.

People change. A key holder who is available today may be unavailable in five years. Relationships change. People move. People die. A dependency that is met now may not be met later.

Services change. An exchange that exists today may not exist tomorrow. Policies update. Processes change. Software becomes deprecated. A step that works now may not work when recovery is actually needed.

A test captures a moment. The moment passes. The path continues to change after the test. A demonstrated path at one time is not permanently demonstrated.

---

Testing Does Not Create Paths

A bitcoin recovery test reveals whether a path exists. It does not create a path. If the test finds that recovery is blocked, the test has surfaced information. The block existed before the test. The test made it visible.

Testing is diagnostic. It exposes the current state of the recovery system. It shows what works and what does not. It identifies gaps, missing credentials, failed devices, and unavailable people.

The test does not fix what it finds. A blocked path remains blocked after the test. A missing credential remains missing. The test provides information. What happens with that information is separate from the test itself.

---

Untested Paths Remain Assumptions

A recovery path that has not been tested remains an assumption. The documentation claims the path works. No evidence supports the claim. The path may work. It may not. The assumption is untested.

Assumptions feel like knowledge. The holder wrote the documentation. The holder knows the system. The holder believes the path works. This belief is an assumption until tested. The holder's confidence does not equal demonstrated capability.

An assumption of recoverability differs from demonstrated recoverability. Demonstrated recoverability means someone executed the path and it worked. Assumed recoverability means someone believes it would work but has not tried.

The distinction matters when recovery is actually needed. At that moment, assumptions encounter reality. Demonstrated paths have evidence of working. Assumed paths face their first real test under the worst possible conditions—after the holder is gone and cannot help.

---

Assessment

A described recovery path is a set of documented steps. A demonstrated recovery path is one that has been executed. The difference is whether someone has attempted to test bitcoin recovery and observed the results.

Documentation captures what the holder intended to convey. It often omits dependencies, timing constraints, and assumed knowledge. These gaps remain invisible until execution surfaces them.

A bitcoin recovery test reveals whether a path is executable. It exposes missing credentials, failed devices, unavailable people, and blocked steps. The test is diagnostic—it surfaces information about the current state of the recovery system. Untested paths remain assumptions rather than demonstrated capabilities.

---

System Context

Examining Bitcoin Custody Under Stress

Bitcoin Recovery Plan Examination

Writing a Bitcoin Recovery Plan

← Return to CustodyStress