layout: true <img src="cetevan-logo-dark-rev.svg" class="logo-small" alt="Cetevan Logo"> --- class: center, middle # Bitcoin Inheritance ## Technical Architectures for Generational Wealth **[Event Name] — [Date]** ??? Welcome. Today we're talking about the technical problem of passing private keys across time. Before we dive in, I want to be clear: this is not a talk about estate law, trusts, or probate. It's about the mechanics of getting bitcoin from you to the next generation without losing it or giving it away too early. We're going to assume your heir is non-technical, possibly grieving, and operating under stress. --- # Why Self-Custody for Inheritance? - **Custodial "inheritance" is a support ticket.** - Exchanges freeze accounts, change terms, or fail - Heirs inherit a customer service queue, not a private key - **Self-custody shifts the burden to you...** - ...but it also removes counterparty risk from your generational wealth - **The goal:** a plan that works even if companies disappear ??? I want to address the elephant in the room. Some of you might be thinking, "This sounds complicated. I'll just keep my bitcoin on Coinbase and let my heirs deal with support." Here's the problem: custodial inheritance is not inheritance; it's a customer service request. We've watched exchanges freeze accounts, go bankrupt, and get hacked. Your heirs might wait months or years for probate while a company decides if they can access the funds. Self-custody is harder up front, but it means your heirs deal with cryptographic truth, not a terms-of-service agreement. --- # The 48-Hour Heir - Grieving, stressed, possibly non-technical - Has a steel plate, an email, and a deadline - Technical perfection means nothing if execution fails ??? Start with the human reality. Alice dies. Her daughter finds a steel seed plate in the safe and an email mentioning a wallet. She doesn't know what a derivation path is. She doesn't know about gap limits. She doesn't know if the steel plate is the real seed or a decoy. This is the actual inheritance event. Your stack is only as good as the worst day of your heir's life. --- # The Sovereignty Paradox - **Security today:** Keys must be hard to access - **Accessibility tomorrow:** Keys must be easy to access - **Bitcoin eliminates trusted third parties...** - ...but inheritance often reintroduces them ??? Bitcoin gives us digital sovereignty. Not your keys, not your coins. But inheritance forces us to delegate that sovereignty across time. If you give keys to your heir now, you risk theft. Hide them too well, and they vanish. Use a company, and you've reintroduced counterparty risk. Every solution we examine is a different answer to this paradox. --- # Building Blocks: Keys & Seeds - A **private key** is a secret that controls bitcoin - Usually written as 12 or 24 words: the **seed phrase** - **Whoever has the words can spend** - This is the atomic unit of every inheritance plan ??? Before we compare services, let's level-set on the building blocks. A private key is just a very large secret number. We usually represent it as 12 or 24 words because humans are bad at writing down long numbers. This seed phrase is the master secret. If your heir has these words and nothing else, they might be able to move funds—but they might also miss funds if they don't know where to look. --- # Building Blocks: Backups & Maps - **Backups:** Steel survives fire; paper is cheap but fragile - **The Map:** A wallet descriptor or config file shows where funds live - Without the map, heirs may miss funds even with the keys - **Rule:** keys get you in; the map tells you where to look ??? Backups are straightforward: steel plates survive house fires, paper degrades. But there's another piece called the wallet descriptor, or config file. This is the map to your addresses. If your heir restores a wallet using just a seed phrase, they might use the wrong settings and fail to see all your funds. The map is what tells the software exactly which addresses belong to you. Unchained calls this the treasure map. It's not a key, but without it, recovery is guesswork. --- # Building Blocks: Time - **Timelocks:** Script rules that say "not until 2030" - **Dead man's switches:** "If I don't check in, auto-send" - These sound elegant but add fragility - Fees change, software breaks, passwords get forgotten ??? Some plans try to add time: you can lock bitcoin until a certain date, or set up a dead man's switch that triggers if you don't check in. These are technically possible, but they are fragile. Bitcoin fees in five years might be wildly different. Software you used to set up the switch might not exist. And if your heir has to decrypt a file, import a descriptor, and wait for a timelock all while grieving, the plan is likely to fail. --- # Tool Chest: Multisig - **One-liner:** A wallet requiring M-of-N keys to spend, distributing trust across devices or people. - **Features:** Theft/loss tolerance; no single point of failure; policy enforced by the network; standard descriptors. - **Tradeoffs:** Setup coordination; on-chain footprint; slightly higher fees; cosigner availability required. - **Complexity:** High initial setup (~1–2 hours, multiple devices, descriptor export). Ongoing coordination for spends and recovery. ??? Multisig is the foundation of most professional inheritance setups. Instead of one seed phrase that can be lost or stolen, you create a quorum. The most common for inheritance is 2-of-3 or 3-of-5. The tradeoff is that your heir now needs multiple keys and coordination. If one key is held by a company, your heir needs that company to respond. If held by a buddy, your heir needs that buddy to respond. --- # Tool Chest: Shamir Secret Sharing - **One-liner:** Splits one seed into multiple shards that must be combined to reconstruct the secret. - **Features:** Geographic distribution; no single capture point; works with existing single-sig wallets. - **Tradeoffs:** Reconstructs a single key—policy collapses after recovery. Vendor lock-in between tools. Malware exposure during reconstruction. - **Complexity:** Medium setup (~30 min). Recovery: high. Heirs must find compatible software, collect shards, and reconstruct on a clean device. ??? Shamir is seductive because it feels like multisig but uses single-sig infrastructure. But remember: once your heir reconstructs the seed, they have a single private key in memory. The policy is gone. And if you used Tool A to create shards, your heirs need Tool A—or compatible software—to reconstruct years later. That's vendor lock-in for your descendants. --- # Tool Chest: Dead Man's Switch - **One-liner:** A trigger—technical or social—that executes or notifies if the owner fails to check in. - **Features:** Can bypass probate delays; automated execution; works without heir initiation. - **Tradeoffs:** Pre-signed txs invalidate when UTXOs change; fee volatility; false positives risk premature alerts or family panic. - **Complexity:** Technical (pre-signed txs): high (~2–3 hours setup, requires periodic re-signing). Social (quarterly check-ins): low (~15 min per quarter). ??? The dead man's switch is the most discussed and least robust DIY tool. If you pre-sign a transaction today, it references specific coins. Spend or receive once, and the transaction is broken. Social versions—like a quarterly check-in with trusted peers—are actually more reliable because they rely on human judgment rather than brittle transaction construction. --- # Tool Chest: Backup Media - **One-liner:** Physical storage of seed phrases or keys on durable materials. - **Features:** Steel survives fire and water; paper is cheap and easily replicated; tamper-evident options available. - **Tradeoffs:** Steel is expensive and creates a single capture point; paper degrades; every copy increases confidentiality risk. - **Complexity:** Steel: ~15 min to stamp + secure storage. Paper: ~5 min to write + distribute. Ongoing: periodic integrity checks. ??? This is the most basic tool and everyone uses some form of it. Steel plates are great against fire but if someone finds the plate, they have the key. Paper allows cheap redundancy—five copies in five locations—but paper can rot, burn, or be read by anyone who finds it. There is no perfect medium; only tradeoffs. --- # Tool Chest: Descriptors & Config Files - **One-liner:** A machine-readable "map" containing all parameters needed to recreate a wallet and find its addresses. - **Features:** Ensures heirs find all funds regardless of derivation path; reveals balance without spending ability; standard format. - **Tradeoffs:** File management burden; if lost, heirs may miss funds; digital storage introduces hack surface; physical storage adds another item to secure. - **Complexity:** Low setup (~5 min to export). Recovery: low if heir knows what it is; high if they don't. Must be stored alongside seeds. ??? I cannot overstate this. Your heir can have every seed phrase and still miss funds if they don't know the derivation path or gap limit. The descriptor is the map. Unchained calls it the treasure map. Store it with every key backup. Do not encrypt it unless you are prepared to manage the encryption key's inheritance path too. --- # Tool Chest: Passphrases, Seed XOR, & Encryption - **One-liner:** Additional layers that hide or protect the seed behind a secret word, XOR combination, or encrypted container. - **Features:** Plausible deniability (passphrase); distributed secrets (XOR); digital protection (encryption). - **Tradeoffs:** Passphrase lost equals funds lost. XOR adds reconstruction complexity. Encryption requires software compatibility and password transmission. Heirs must know these layers exist. - **Complexity:** Passphrase: low ongoing (~1 extra field, catastrophic if forgotten). Seed XOR: medium-high setup and recovery. Encryption: medium (software dependencies, password management). ??? These tools are attractive because they add security. But each one is another secret your heir must manage. If you use a passphrase and don't tell your heir, the money is gone. If you use encryption and your heir doesn't know the software, the money is gone. If you use Seed XOR, your heir must locate multiple seeds and XOR them correctly. These improve security at the direct cost of heir accessibility. --- class: table-slide # Tool Chest: Services & Protocols | | **Casa** | **Unchained** | **Nunchuk** | **Badger Legacy** | |---|---|---|---|---| | **Trigger** | 6-mo claim; owner can veto | Legal docs + 1 key | Miniscript timelock | Missed quarterly check-in | | **Heir UX** | App-guided; health checks | Physical kit + legal | Guided or autonomous | Peer-coordinated | | **Privacy** | Conditional KYC | KYC required | Zero KYC | Peer-dependent | | **Cost** | ~\$250/yr | ~\$750/yr | ~\$480/yr | Free | | **Complexity** | Low | Medium | Medium | High (social) | ??? This table summarizes the four main assisted paths. Casa is the most hand-holding but requires ongoing trust and subscription. Unchained integrates deeply with legal estates but places burden on the executor. Nunchuk offers the strongest autonomy guarantee with its on-chain protocol. Badger Legacy is the most private and free but demands the highest social coordination. None are perfect; each optimizes for different properties. --- # Combining Tools: Helpful or Harmful? - **Good stack:** Multisig + durable backups + clear heir instructions - **Bad stack:** SSS shards inside encrypted containers with passphrases split via social media and a dead man's switch requiring 3 hardware wallets - **Each tool adds a failure mode** - **Test:** Can a smart, non-technical, grieving person execute this? ??? This is the most important slide. You can combine tools, and sometimes that helps. A simple multisig wallet plus steel backups plus written instructions is robust. But there is a temptation to over-engineer: Shamir shards inside encrypted containers with passphrases hidden in Nostr posts, plus a timelocked pre-signed transaction, plus a dead man's switch. Every layer adds complexity. Every layer is a new way for your heir to fail. The test is simple: can a smart but non-technical person execute this plan while grieving? If not, you didn't build an inheritance plan; you built a puzzle. --- # Privacy & Decay - **Privacy timeline:** Who knows what, and when? - Casa: recipient knows vault exists early; balance hidden until claim - Unchained: config file reveals balance; TOD keeps it out of probate - Nunchuk: zero KYC, but config maps to addresses - Badger Legacy: privacy depends entirely on your peers - **Decay vectors:** Hardware dies, companies fail, buddies move away - **The 20-year test:** Will this work in 2045? ??? Privacy and decay are inseparable. With Casa, your recipient knows the vault exists before you die. With Unchained, the config file reveals your balance to anyone who holds it. With Badger Legacy, your privacy is only as strong as your least careful fellow. Decay is equally brutal: hardware wallets may not boot in twenty years. Companies may not exist. Your buddy might change his phone number. If your plan requires any single company, device, or person to remain unchanged for decades, it is brittle. --- class: center, middle # Interactive: Steel-Man Circuit **Casa | Unchained | Nunchuk | Badger Legacy | DIY Sovereign** Identify the strongest critique of your model, then patch it. 90-second pitch of your hardened setup. ??? We're moving into the interactive portion. Each team gets one of these five models. Your job is to steel-man it: identify the most devastating technical critique against your assigned model, then propose a concrete mitigation. You have five minutes to prepare, then ninety seconds to pitch. The goal is to understand that every architecture is a choice between two good things, not a choice between good and evil. --- class: center, middle # The Unavoidable Tradeoff **Confidentiality | Availability | Durability | Simplicity** Pick two. ??? I'll leave you with this. You cannot optimize for confidentiality, availability, durability, and simplicity simultaneously. A simple plan is available but might not be durable. A confidential plan is complex. Every inheritance architecture is a deliberate choice about which properties you value most. Choose knowingly. Thank you.