Duress Wallet Features and Inheritance Survivability Behavior

Duress Wallets and Inheritance Confusion

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

What a Duress Wallet Feature Is

A Bitcoin holder sets up a duress wallet feature. The feature creates two access paths. One path leads to primary holdings. Another path leads to a decoy balance. The holder designed this for protection during coercion. The holder then dies.

This memo describes how bitcoin duress wallet inheritance scenarios behave when recovery is attempted by an executor or heir. It examines what happens when the feature's intent is unknown to the person attempting recovery. It treats the duress feature as a variable that changes inheritance outcomes.

The memo applies when a custody system includes a duress wallet feature and the owner becomes unavailable. It models behavior under executor conditions where the feature's meaning may not be understood. It remains descriptive of observed patterns without evaluating feature design.

---

What a Duress Wallet Feature Is

A duress wallet feature creates multiple wallet branches from a single seed phrase. Different passphrases or PINs access different wallets. One branch holds a small decoy balance. Another branch holds primary holdings. The holder chooses which branch to reveal based on circumstances.

The feature exists for coercion scenarios. If forced to provide access, the holder provides the decoy credentials. The attacker sees a wallet with some Bitcoin. The attacker may believe they have found everything. The primary holdings remain hidden behind a different passphrase.

The holder understands which passphrase leads where. The holder knows the decoy from the primary. This knowledge exists in the holder's mind. It may or may not exist in documentation. The feature depends on this knowledge being available to the right person at the right time.

---

Bitcoin Duress Wallet Inheritance: The Core Problem

Bitcoin duress wallet inheritance creates a specific problem. The executor finds a seed phrase. The executor finds a passphrase. The executor accesses a wallet. The wallet shows a balance. The executor believes recovery is complete. But which wallet did they access?

The feature was designed to deceive attackers. Under inheritance conditions, the feature may deceive executors. The executor is not an attacker. The executor has legal authority. But the feature does not know who is using it. The feature behaves the same way regardless of the user's legitimacy.

The executor may access the decoy branch and believe they have recovered the estate's Bitcoin. The executor does not know a primary branch exists. The executor closes the estate. The primary holdings remain undiscovered. The feature worked as designed but produced an inheritance failure.

---

Observed Pattern: Multiple Valid Access Paths

The system often presents multiple valid access paths that do not disclose whether full holdings are visible. The executor finds credentials. The credentials work. A wallet opens. Bitcoin appears. Everything looks normal. Nothing indicates that another wallet exists.

Both paths are technically valid. Both paths use the same seed phrase. Both paths produce working wallets. Both paths show balances. The decoy path does not announce itself as a decoy. The primary path does not announce itself as primary. The paths look the same from the outside.

The executor has no way to know which path they accessed unless documentation exists. The feature is designed to hide this distinction. The hiding works against attackers. The hiding also works against legitimate recovery attempts.

---

Decoy Wallet Inheritance Survivability: False Closure

Decoy wallet inheritance survivability depends on whether the executor recognizes the decoy for what it is. If not recognized, the executor reaches false closure. The executor believes recovery is complete. The executor distributes what was found. The estate closes.

False closure is a specific failure mode. The system did not fail technically. Access was achieved. Bitcoin was recovered. The failure is that access was achieved to the wrong wallet. The recovered Bitcoin was not the intended inheritance. The intended inheritance remains hidden.

The profile often shows recovery appearing successful while primary holdings remain undiscovered or unrecoverable. The executor experiences success. The heirs receive funds. Everyone believes the process worked. The primary holdings sit untouched because no one knew to look for them.

---

Duress Wallet Inheritance Implications: Access vs Intended Funds

Duress wallet inheritance implications include a shift in what recovery means. Normally, access equals recovery. Find the keys, access the wallet, recover the Bitcoin. With a duress feature, access may not equal recovery of intended funds.

Recovery in the scenario becomes sensitive to interpretation. The executor achieved access. The executor recovered Bitcoin. But did the executor recover what the holder intended to pass on? The answer depends on which branch was accessed. The branch accessed depends on which credentials were found and used.

This interpretation problem does not exist without the duress feature. A normal wallet has one branch. Access means access to everything. A duress wallet has multiple branches. Access means access to one branch. The distinction matters for inheritance completeness.

---

Duress Wallet Executor Confusion: Feature Meaning Not Self-Evident

Duress wallet executor confusion arises because the feature's meaning is not self-evident to third parties. The executor finds a passphrase written on paper. The executor uses it. The executor does not know this was the decoy passphrase. The paper did not say "decoy" or "primary."

Documentation and memory dependence increases because feature meaning cannot be inferred from the feature itself. A wallet does not display whether it is a duress branch. A balance does not indicate whether larger holdings exist elsewhere. The feature provides no internal indication of its role.

The executor must rely on external information. A note explaining the setup. A conversation the holder had with someone. A document describing which passphrase leads where. Without this external information, the executor operates blind to the feature's structure.

---

Bitcoin Duress Feature Estate Recovery: Executor Cognition Limits

Bitcoin duress feature estate recovery faces executor cognition limits. The executor is under stress. The executor may not be technical. The executor may not know what a duress feature is. The executor may not know to look for one.

Under stress, third parties may not detect that a duress path was triggered or is being used. The executor focuses on completing the task. The executor finds credentials, uses them, sees Bitcoin, and moves forward. The executor does not stop to question whether more exists. The executor does not know that questioning is necessary.

Cognition limits apply even to sophisticated executors. A sophisticated executor who does not know the feature exists cannot account for it. Knowledge that the feature exists is a prerequisite to recognizing its implications. Without that knowledge, even careful executors may miss the primary holdings.

---

Failure Dynamics: Authority Does Not Resolve Ambiguity

Legal authority does not resolve which wallet branch represents the intended estate assets. A court can confirm the executor's authority. A will can name beneficiaries. These legal instruments address who has rights. They do not address which Bitcoin is the estate Bitcoin.

Authority and access separate in a specific way here. The executor has authority over the estate. The executor has access to a wallet. The executor cannot determine through authority whether that wallet is the correct one. Authority is a legal concept. The wallet branches are a technical fact.

No court can order the correct wallet to reveal itself. No legal process can distinguish decoy from primary holdings. The distinction exists only in the holder's design and documentation. If that information is missing, authority alone cannot fill the gap.

---

Failure Dynamics: Time and Coordination Constraints

Recovery timelines can expire while uncertainty persists about completeness. Estates have deadlines. Tax filings have deadlines. Distributions have expectations. The executor faces pressure to complete the process.

Time pressure works against thorough investigation. The executor may suspect more Bitcoin exists but lack time to investigate fully. The executor may proceed with what was found because the timeline demands closure. Incompleteness becomes permanent because the window for investigation closed.

Coordination constraints also apply. If multiple parties hold information about the duress setup, gathering that information takes time. One party may know the feature exists. Another party may know which passphrase is primary. Bringing this knowledge together requires coordination that time pressure may not allow.

---

Failure Dynamics: Knowledge Concentration

Knowledge of the duress design may exist only in the owner's memory or in fragile documentation. The holder understood the setup. The holder knew which passphrase led to primary holdings. The holder may not have written this down. The holder may not have told anyone.

When the holder dies, this knowledge may die with them. The feature continues to exist. The wallets continue to be accessible. But the map that explains which wallet is which disappears. The executor navigates without knowing the terrain.

Fragile documentation creates partial knowledge problems. The holder may have documented the seed phrase but not the passphrase distinction. The holder may have documented one passphrase but not explained its role. Partial documentation can lead the executor to the wrong branch with false confidence.

---

Observed Pattern: Feature Design vs Inheritance Design

The duress feature was designed for a different scenario than inheritance. It was designed to deceive attackers during the holder's lifetime. It was designed for a situation where the holder remains present and can later access the primary holdings.

Inheritance is a different scenario. The holder is absent. The holder cannot clarify. The holder cannot reveal the primary branch later. The feature's protection mechanism becomes a barrier to legitimate recovery.

A feature that helps during one scenario may harm during another. The duress feature helps if the holder faces coercion and survives. The duress feature harms if the holder dies without transferring the knowledge needed to navigate it. The same feature produces opposite effects depending on circumstances.

---

What the Feature Does Not Change

The feature does not change how Bitcoin works technically. Both wallet branches are valid Bitcoin wallets. Both can hold and transfer Bitcoin. Both respond to correct credentials. The blockchain treats them identically.

The feature does not change legal inheritance rules. The estate includes whatever Bitcoin the holder owned. The executor has authority over estate assets. The beneficiaries have rights to distributions. The legal framework applies regardless of the feature.

The feature changes what can be discovered and accessed. It introduces ambiguity that the legal and technical systems do not resolve. The feature sits between the holder's intent and the executor's access, potentially blocking the connection.

---

What Does Not Change

This memo does not evaluate duress features. Different holders face different threats. Different circumstances warrant different designs. This analysis covers behavior without assessing whether the feature is appropriate.

This memo does not provide guidance on documentation. It does not describe what holders might do to address the patterns identified. Such guidance would be prescriptive and outside the memo's scope.

This memo does not promise outcomes from any documentation approach. Even well-documented duress features may produce inheritance complications. The memo describes patterns without guaranteeing that awareness of them prevents failures.

This memo does not address feature selection or design. It takes the feature as given and describes behavior when inheritance is attempted. Design choices are outside the memo's descriptive boundary.

---

Summary

This document addresses how bitcoin duress wallet inheritance scenarios behave when recovery is attempted by executors or heirs. The duress feature creates multiple access paths that do not disclose which path leads to primary holdings.

Decoy wallet inheritance survivability faces the risk of false closure. The executor may access the decoy branch, believe recovery is complete, and close the estate while primary holdings remain undiscovered. Duress wallet executor confusion arises because the feature's meaning is not self-evident.

Bitcoin duress feature estate recovery faces cognition limits, time constraints, and knowledge concentration. Duress wallet inheritance implications include the separation between achieving access and recovering intended funds. Legal authority does not resolve which branch represents estate assets.

This memo looks at modeled behavior under duress-feature and inheritance conditions. It remains scenario-bounded and descriptive without evaluating feature design or providing guidance on documentation approaches.

---

System Context

Examining Bitcoin Custody Under Stress

Whether Heirs Can Access Bitcoin

Is My Bitcoin Lost If I Die: Modeled Custody Behavior at Death

← Return to CustodyStress