FAMILY SOVEREIGN INHERITANCE KIT SOVEREIGN STACK EDITION – v1.0

Cover Page

Kit Name: Family Sovereign Inheritance Kit – Sovereign Stack Edition

Kit Version: v____.__

Date Activated: ____ / ____ / ______

Owner:

Statement of Intent (fill in):

Owner Signature: Date: ____ / ____ / ______

Kit Version & Funeral Log

Current Active Version: v____.__ (this kit)

Quickstart for Heirs (Read This First)

If you are reading this because I am dead or incapacitated:

1. Stop. Do not type or photograph any secret.
   • Do not type seed phrases into websites or apps.
   • Do not upload anything to cloud services.
2. Confirm my status.
   • Confirm that I am truly deceased or permanently unable to manage my affairs (per local law / medical confirmation).
3. Contact the Technical Helpers.
   • Go to the Role Map (Section 3).
   • Contact at least two Technical Helpers.
   • Do not proceed alone or with a single outsider.
4. Locate the Binder and Packets.
   • Use the Inventory (Section 4) to find sealed packets (envelopes, metal plates, devices).
   • Do not open any sealed packet until at least 2 helpers are present.
5. Follow the Runbook for the Selected Module(s).
   • The Architecture Declaration (Section 5) tells you which Module(s) are active:
     • A – Singlesig
     • B – 2-of-3 Multisig
     • C – Timelocked Recovery
   • Use the matching Runbook in Section 12.

Role Map

3.1 Primary Roles

Owner (Me):
Name:
Primary Contact (while alive):

Executor / Coordinator (after death/incapacity):
Name:
Contact info:

Legal Heirs / Beneficiaries (names only):

3.2 Technical Helpers

Inventory (No Secrets)

Packet Type Legend:

• S – Seed / recovery phrase / Shamir share
• P – Passphrase (if any)
• D – Wallet config / descriptors / xpubs
• K – Device (hardware wallet, signing tool, node disk)

Packets may be stored in different locations (home safe, offsite vault, trusted relative’s safe, buried capsule, etc.). No single location should hold everything needed to steal the funds.

Architecture Declaration (Modules)

5.1 Module Selection

Module A – Singlesig, No Passphrase
Usage:
Small / day-to-day stash
Teaching / starter wallet
Other:

Module B – 2-of-3 Multisig (Core Sovereign Vault)
Usage: Used as primary vault for main holdings

Module C – Timelocked Recovery / Miniscript (Advanced, Optional)
Usage:
Heir-only delayed recovery path
Backup “I disappear” failsafe
Other:

5.2 Buckets (Optional)

Collusion & Authority Matrix

Design this so that while you are alive, no combination of heirs alone can move the main vault unless you explicitly want that. After your death, the combination you choose can move the funds by following this kit.

Incapacity Clause

Option A – Treat Incapacity Like Death
If I am medically/legally incapacitated and cannot manage my affairs, my heirs may use this kit as if I had died, to access and use my funds for my care and/or their inheritance.

Option B – Separate Care Vault
I will maintain a smaller separate wallet (“Care Vault”) for medical/care expenses with a simpler policy. The main Sovereign Vault (Module B) remains locked until my actual death.

Notes / Clarifications:

Node Inheritance Page

Node Type / Hardware:

Location:

Node Software / Stack:

How to Start the Node:

1. Power on:
2. OS / login details (store securely or in another sealed packet if sensitive):
   OS:
   User:
3. Node startup command / procedure:
   
   

How to Connect Wallets:
Local network (IP or hostname):
Tor / onion address (if applicable):

If This Node Is Destroyed:

• You can still recover funds using the wallet descriptors + seeds in the packets.
• After recovery and sweeping to a new wallet, rebuild a new node using standard Bitcoin full node software.
• Connect new wallets to the new node.

Packets & Labeling Protocol

9.1 Packet Types

• Packet S – Seeds / Shamir Shares
  • BIP39 phrases, SLIP-39 shares, or equivalent.
• Packet P – Passphrases
  • Only if passphrases are explicitly used.
• Packet D – Wallet Configuration / Descriptors
  • Output descriptors, xpubs, derivation paths, scripts, key fingerprints.
• Packet K – Devices
  • Hardware wallets, signing devices, node disks.

9.2 Labeling Rules

• Each packet must show externally:
  • Packet ID: e.g., Packet-XX (S-B1, D-B, S-A1, etc.)
  • Type: S / P / D / K
  • Seal date
  • Owner’s signature across the seal
• Never write seed words, passphrases, or exact balances on the outside.

9.3 Example Packet Assignment

For Module B (2-of-3 Multisig):

• S-B1: Seed for Signer #1 + printed copy of Packet D-B
• S-B2: Seed for Signer #2 + printed copy of Packet D-B
• S-B3: Seed for Signer #3 + printed copy of Packet D-B
• D-B: Master policy descriptor(s) and all signer xpubs/fingerprints

For Module C (Timelock):

• S-C1: Primary key seed
• S-C2: Recovery key seed
• D-C: Policy descriptor(s) with miniscript / timelock rules

Wallet Policy Record (Global)

Wallet Name / Label:

Module: A / B / C

Network: mainnet

Address Type: (e.g., p2wpkh, p2wsh, p2tr)

Coordinator / Wallet Software:

Version (when created):

Descriptor(s) / Policy Text:

Change Descriptor (if different):

Quorum (e.g., 2-of-3):

This Policy Record and Packet D may reveal balances and transaction history. Treat them as sensitive even though they cannot spend coins by themselves.

Signer Records (One Per Key)

Signer Label: (Key 1 / Key 2 / Key 3 / Primary / Recovery)

Device Model:

Master Fingerprint:

XPUB (or equivalent):

Derivation Path: (e.g., m/84'/0'/0' or m/48'/0'/0'/2')

Seed Backup Packet ID(s):

Passphrase Used for This Key? Yes / No
If Yes: Passphrase Packet ID:

Last Successfully Tested Signature (Date): ____ / ____ / ______

Module Runbooks

12.1 Module A – Singlesig, No Passphrase

Goal: Recover funds from a simple single-key wallet.

Required:

• Packet S-A1 (seed) (and S-A2 as backup)
• A clean, offline-capable device
• A FOSS wallet that supports BIP39 restore
• (Preferred) Your own node, or a trusted node

1. Confirm legal/medical condition (death or incapacity as per Section 7).
2. Gather at least 2 Technical Helpers.
3. Retrieve Packet S-A1; inspect seal and signature.
4. Prepare an offline environment (airgapped laptop / bootable OS).
5. Open Packet S-A1 and enter the seed only into the offline wallet.
6. Reconstruct the wallet, then connect it to a node (preferably your node) as a watch-only or full wallet.
7. Fee & Privacy:
   • Start with a small test send to a new address controlled by heirs.
   • Avoid merging all UTXOs into a single address unless necessary.
8. After test succeeds, sweep remaining UTXOs to a new heir-controlled wallet.
9. Record in Rehearsal / Actions log (no secrets).

12.2 Module B – 2-of-3 Multisig Vault (Core)

Goal: Recover and spend from the primary multisig vault.

Minimum required:

• Packet D-B (wallet policy / descriptors)
• Any two of S-B1 / S-B2 / S-B3 (seeds + policy copies)
• Two hardware devices (if devices were used) or new devices to restore onto
• A FOSS multisig-capable coordinator (Sparrow, Specter, etc.)
• A node (preferably yours; if none, see Emergency Path)

1. Confirm legal/medical condition.
2. Gather at least 2 Technical Helpers.
3. Retrieve Packet D-B and two S-Bx packets. Check seals.
4. In a controlled environment (preferably offline node-connected machine):
   • Import the descriptor(s) / policy from D-B into the coordinator.
   • Restore signer #1 from S-Bx and signer #2 from S-Bx using hardware devices or secure restore.
5. Connect coordinator to your node if available.
6. Verify that:
   • Known addresses match printed examples (if provided).
   • Balance / UTXOs look plausible.
7. Fee & Privacy:
   • Construct a small test transaction requiring 2 signatures, sending a small amount to a new heir-controlled wallet.
   • Broadcast it, verify confirmation.
8. Once confident, sweep remaining UTXOs to heir-controlled vault(s) or distribution addresses.
   • Use coin control where possible to avoid unnecessary UTXO merging.
9. Record the process and final disposition in the Actions log (no seed words).

12.3 Module C – Timelocked Recovery (Advanced / Optional)

WARNING: This is advanced and wallet-specific. The primary multisig vault must still be recoverable without relying on this module.

Goal: Let heirs recover funds via an on-chain timelocked path if the primary path is never used again.

Required:

• Packet D-C (miniscript / descriptor policy)
• Packet S-C2 (Recovery key seed)
• Compatible wallet software (e.g., Liana or equivalent)
• Node access (preferably yours)

1. Confirm legal condition and ensure timelock conditions are satisfied (block height / elapsed blocks since last spend).
2. Gather at least 2 Technical Helpers.
3. Retrieve Packet D-C and S-C2; inspect seals.
4. Import descriptor(s)/policy from D-C into the compatible wallet.
5. Restore the Recovery key from S-C2 on a signing device or secure environment.
6. Verify that the wallet sees the relevant UTXOs via watch-only.
7. Once the timelock has actually matured, construct recovery transactions from the timelocked path.
8. Broadcast, wait for confirmation, then sweep to heir-controlled vault(s).
9. Record the entire process in the Actions log.

Rehearsal & Health Check Protocol

13.1 Checklist

• Inventory Check: All packets exist at listed locations (Section 4).
• Seal Check: No signs of tampering, water damage, fire damage.
• Paper Check: No fading, mold, or illegible text.
• Metal Check: All characters legible; no ambiguous markings.
• Policy Check: Wallet policy (descriptors, script type) in Section 10 still matches active wallet setup.
• Signer Check: Each signer can still produce a valid test signature or tiny test transaction.
• Node Check: Node starts, syncs, and is reachable.
• Heir Education: At least one heir has had basic concepts explained and knows this kit exists.

13.2 Rehearsal Log

Fork Coins & Phishing Warning

1. Heirs should assume all “claim your fork coins safely” services are hostile by default.
2. Any attempt to extract value from forks must happen only after:
   • Main BTC has been swept to a new wallet with a new seed, and
   • An experienced Bitcoiner is physically present.
3. If in doubt, ignore fork coins; losing the main BTC to a phishing tool is far worse than missing questionable fork value.

Helper Authentication

Define at least one method per helper (shared phrase, in-person verification, etc.).

Helper 1:
Verification method:

Helper 2:
Verification method:

Helper 3:
Verification method:

Do not trust inbound emails, calls, or messages claiming to be a Helper without using the verification method. If unsure, pause and get a second opinion from another helper / relative.

Emergency Path: No Node, No Hardware

1. If your node and devices are destroyed, use descriptors + seeds from Packet D and Packet S to reconstruct wallets on new hardware devices and a FOSS wallet on a clean machine.
2. Verify addresses against any printed known addresses you included (optional but recommended).
3. Temporarily connect to a reputable public server only if absolutely necessary, and only to sweep funds to a new, safer setup. Then migrate to a self-hosted node as soon as possible.
4. Rebuild a node and restore a more sovereign environment once the emergency is over.

Sovereign Property Clause (To Attach to Will / Estate)

I hold certain digital bearer assets (including Bitcoin) in self-custody, not via any bank or custodian. These assets are controlled by cryptographic keys that are not stored with, and cannot be recovered from, any financial institution.

My heirs are entitled to the value and control of these assets as defined in my will and this kit. Access to the keys themselves is governed by the Family Sovereign Inheritance Kit – Sovereign Stack Edition, which exists as a separate, private document outside institutional custody.

Signature (if included in estate docs): Date: ____ / ____ / ______

Sovereign Testament (To Be Written by You)

Suggested structure:

1. What Bitcoin Is (in your ontology)
   • Not just “money,” but what you know it to be.
2. Why This Kit Exists
   • Why you chose self-custody.
   • Why no custodial inheritance service.
3. The Sovereign Stack vs Synthetic Stack
   • A short explanation your heirs can understand.
4. Minimal Heir Guidance
   • If they choose to sell: how to do it carefully, without being fleeced.
   • If they choose to hold/build: how to align with the Sovereign Stack.

Write your Testament here (or attach as separate pages):

Owner Signature: Date: ____ / ____ / ______

Place this Testament in a clearly labeled, sealed section at the front of the binder with the instruction: “Read this Testament once before touching any operational step.”