# Monero inheritance — a self-custody plan that doesn't dox your heirs > Self-custody fails dead silent: when you die, the XMR doesn't transfer, it just stops existing. The patterns that solve this without forcing your heirs to publish their identity to the chain — or yours — covered honestly. Markdown twin of https://xmr.club/guides/monero-inheritance-plan. CC-BY-4.0. Attribute "xmr.club". ## At a glance - Canonical: https://xmr.club/guides/monero-inheritance-plan - Slug: monero-inheritance-plan - Title: Monero inheritance — a self-custody plan that doesn't dox your heirs - Description: Self-custody fails dead silent: when you die, the XMR doesn't transfer, it just stops existing. The patterns that solve this without forcing your heirs to publish their identity to the chain — or yours — covered honestly. - Available locales: en, zh, es, ru - zh: https://xmr.club/zh/guides/monero-inheritance-plan - es: https://xmr.club/es/guides/monero-inheritance-plan - ru: https://xmr.club/ru/guides/monero-inheritance-plan ## Intro Self-custody is the best privacy posture and the worst inheritance posture. When you die, the XMR doesn't go anywhere — it just stops existing, because nobody has the seed. "Give my brother the seed when I die" is the obvious answer and it's a bad one: it dox-es your brother (now there's a wallet with your XMR controlled by an identifiable person), and it assumes the brother is alive, reachable, and uncompromised at the moment you become unable to act. Below: the patterns that actually work, and the ones that quietly fail families a decade later when the holder dies unexpectedly. ## Body ## Why this is harder than non-Monero inheritance - **No registry, no court can recover.** Unlike bank accounts or even doxxed wallets, there is no entity a probate judge can subpoena to release funds. If the seed is lost or unreachable, the XMR is lost. Period. There is no fallback. - **Transparency-coin estate planning doesn't transfer.** BTC inheritance advice (sealed envelope at lawyer, executor knows the address) often leaks holdings to family long before death because the chain is public. Monero hides the balance, so families often don't even know how much is there — which is the opposite problem: they may not realize it's worth recovering. - **Heir privacy matters too.** Whoever inherits an XMR stash becomes a target — for scammers, for tax authorities, for $5-wrench attacks. A plan that hands them the seed and a forwarded email is a plan that gets them robbed. - **Holder may become incapacitated, not dead.** Dementia, coma, kidnapping. Inheritance planning has to cover "can't act" as well as "dead", and the recoverability triggers are different. ## The inheritance trilemma You're optimizing for three things that pull against each other: - **Secure now** — nobody can drain the wallet while you're alive. - **Recoverable later** — the right people CAN drain it when they need to, even years from now. - **Doesn't dox the heirs** — recovery doesn't require heirs to publish their identity, location, or relationship to you on any chain or to any custodian. Any two are easy. All three takes structure. Most "inheritance plans" pick the first two and accept that heirs become targets the moment they spend the inherited XMR. The patterns below are the ones that don't. ## Pattern A: Sealed envelope + dead-man check-in Seed on metal in a sealed envelope at a lawyer or in a safety-deposit box. You set up a recurring check-in (monthly email, quarterly form). Missed check-ins for N periods → lawyer releases the envelope to the named recipient. - **Pro:** Simple. No technical demands on heirs. - **Con:** Lawyer/bank is a single point of failure (subpoena, bankruptcy, mistake). Heir gets the full seed, which means heir becomes the new sole-custody party with zero training. No protection against compromise of the lawyer. - **When it fits:** Small stash (<5 XMR), trusted single heir, low-adversary jurisdiction. ## Pattern B: Two-party split (you + executor) Seed split into two halves using a simple XOR or Shamir 2-of-2. You hold one half, an executor (lawyer / family / pseudonymous trusted party) holds the other. Neither half alone reveals the seed; both together reconstruct it. On death, executor releases their half to the named heir, who combines with the holder's half (left at home, in a safe, etc.). - **Pro:** No single party can drain the wallet. Heir gets training / walkthrough via the executor. - **Con:** Loss of either half = loss of wallet. Holder's half still has the same physical-security problem as any seed backup. - **When it fits:** Mid stash (5–50 XMR), executor relationship is robust, you trust the executor's operational security as much as your own. ## Pattern C: 2-of-3 Monero multisig Monero supports native multisig (multiple cosigners required to spend). 2-of-3 setup: you hold one key, an executor holds one, a long-term backup (different jurisdiction, vault, or trusted third party) holds one. While alive, you and one cosigner sign. On death, the other two sign. - **Pro:** Loss of any single key is recoverable. No single party can drain. Heirs don't need the full seed — they need cooperation from the surviving cosigners, which is its own gating mechanism. - **Con:** Setup complexity is real — practice spending and recovery before you depend on it. Monero multisig UX has improved (Feather, Monero GUI) but it's still less polished than BTC multisig. - **When it fits:** Serious stash (50+ XMR), willing to invest 4–8 hours in setup + practice runs, have three trustworthy key-holders. ## Pattern D: Shamir-sharded seed (SLIP-39 style) Seed split into N shares, M required to reconstruct. Common: 3-of-5 or 2-of-3. Shares distributed across jurisdictions / trusted parties / hidden locations. Differs from multisig: this is splitting a single seed, not multiple independent keys. Reconstruction = full custody for whoever does it. - **Pro:** Flexible: choose N and M, choose share-holders independently. Survives losing any (N−M) shares. - **Con:** Once reconstructed, it's a single seed again — the assembler holds everything. Less safe than multisig (no continuing distribution after recovery). Native Monero tooling for SLIP-39 is limited; usually implemented manually or via off-the-shelf scripts. - **When it fits:** Holder wants distributed risk without the multisig UX burden. Often layered: SLIP-39 each multisig key, so even compromising one share doesn't expose a full cosigner key. ## Pattern E: Dead-man's-switch primitives Automated trigger: if you don't perform an action by deadline T, an encrypted file gets released / a multisig key gets transferred / a notification gets sent. Implementations range from cron-on-VPS to commercial services (deadmansswitch.net) to self-hosted Tails + timer. - **Pro:** Removes the human-executor link. Triggers automatically; no executor can leak or stall. - **Con:** Single-point-of-failure on the trigger system. False positives (sick, travelling without internet) drain the wallet. The trigger system itself becomes a high-value target. - **When it fits:** Layered with one of A–D — never the sole mechanism. Best as "if all human executors fail to act, this releases backup instructions" — not as the primary release. ## Pattern F: Hidden wallet + plausible deniability Monero wallets support a passphrase that creates a separate hidden wallet alongside the primary. The primary holds a decoy balance you're willing to lose if coerced; the hidden one holds the real stash. Inheritance variant: heirs are told about the primary, and a secondary instruction (sealed, delayed) about the hidden one. - **Pro:** Protects holder against forced disclosure under duress. Adversaries who extract the primary seed walk away thinking they got everything. - **Con:** Adds complexity to inheritance — if you die before the secondary instruction is found, the hidden balance is genuinely lost. Documenting the existence of a hidden wallet defeats its purpose. - **When it fits:** State-adversary or high-coercion threat model. Layered with Pattern C or D. Heirs must be technically competent to understand the layering. ## Documenting the plan without leaking it The plan itself has to survive — and stay secret to the right parties — for potentially decades. The document is the second-most-sensitive artifact after the seed. - **Two-tier documentation.** Tier 1: "There is a plan. Contact these people if I die." Goes to anyone — family, lawyer, in your will. Tier 2: the actual recovery instructions. Lives somewhere only the heir-or-executor reads after a triggering event. - **No filenames that scream.** "monero-inheritance.txt" on your laptop = forensic-grade discovery during any unrelated incident. Use boring filenames in boring locations. - **Version the plan and review yearly.** Tools die, executors die, jurisdictions change. A 5-year-old plan referencing a wallet that no longer compiles is worse than no plan. - **Test the recovery path while alive.** At least once. Have the executor + heir walk through a dry run with a tiny test wallet. The plan exists to be executed once under stress — practice it under no-stress. - **Plain language wins over CLI.** Heirs aren't necessarily technical. Write the recovery as numbered steps: "open this app, click this button, scan this QR." Not "import the keychain via CLI." ## Common ways inheritance plans quietly fail - **The lawyer retires / firm closes / bank closes the safety-deposit business.** Multi-decade plans need redundancy. A single lawyer is a single point of failure. - **The wallet software dies.** Monero GUI in 2026 will not be the same binary in 2046. Inheritance docs that say "open Feather and import the seed" need to also say "OR import the 25-word seed into any Monero-compatible wallet." - **The executor predeceases the holder.** Always name backup executors. Two minimum, three for serious stash. - **The check-in cadence is unrealistic.** "Monthly email" sounds fine until you travel for three months without internet. False positives drain wallets. Build in grace periods, override channels, and human review before automated release. - **Heir doesn't know the stash exists.** Monero hides the balance from chain analysis, which means it also hides it from family. If everyone you trust dies unaware the XMR exists, it's lost regardless of how good your multisig setup is. Tier-1 documentation (the "there is a plan" notice) addresses this. - **The plan leaks to people it shouldn't.** Heir gets the seed under duress before the trigger fires, lawyer's office gets breached, the executor's spouse opens the wrong drawer. Compartmentalize aggressively: nobody but the holder should ever know the complete picture while the holder is alive. - **Heir spends it the day they get it and gets clustered.** Without warning, the heir withdraws to a doxxed exchange and gets onboarded by an over-eager support agent. Tier-2 documentation should include a brief "what to do with this XMR safely" section — basically a pointer to xmr.club/guides — not just the recovery instructions. ## Picks - [Monero GUI](https://xmr.club/wallets/monero-gui) — Native multisig support, view-only mode for the cold companion, reproducible build. The reference implementation for Pattern C. - [Feather](https://xmr.club/wallets/feather) — Best multisig UX in the Monero ecosystem. Hardware-wallet integration. Good for the executor-side workstation. - [Trezor (Monero)](https://xmr.club/wallets/trezor-xmr) — Hardware-wallet option for one of the multisig keys. Survives software-stack changes over decades. - [Ledger (Monero)](https://xmr.club/wallets/ledger-xmr) — Alternate hardware-wallet pick for a different-jurisdiction multisig key, reducing single-vendor risk. ## How to cite Source: xmr.club, "Monero inheritance — a self-custody plan that doesn't dox your heirs". https://xmr.club/guides/monero-inheritance-plan (CC-BY-4.0). ## Related - https://xmr.club/guides — full guides index (42 guides) - https://xmr.club/methodology — how the directory grades providers referenced in this guide - https://xmr.club/transparency — funding model + editorial firewall - https://xmr.club/data.json — full provider dataset (CC-BY-4.0) ## License CC-BY-4.0. Attribute "xmr.club".