Sovereign Stack — Individual Layer — Money/Finance

Layer: Individual Module: Money / Finance Base: Bitcoin-only Posture: adversarial-to-state/banks/surveillance

0. Scope & Frame

This page zooms into one box on the Sovereign Stack map: Layer = Individual, Module = Money & Finance. It describes how a single person can structure their Bitcoin life so that they actually own it under stress, not just in slogans.

The goal is not “learn Bitcoin from scratch” or “optimize yield”. The goal is to have a clear, teachable, survivable money topology: where your sats live, what they’re for, how they move, and what happens when things break.

Orientation Read this as a design template, not as financial advice. It assumes you’ve already decided to hold value in Bitcoin and want a sovereign, privacy-aware way to do it. You don’t have to implement everything at once; the Pedagogical Tiers section shows how to start simple and grow into the full topology.

1. Hard Invariants

These are the non-negotiable rules of this template. If you break them, you are no longer running this stack; you are running a different one. You can still choose to break them, but you should do it consciously.

  1. Bitcoin-only base. No altcoins/stables/yield/wrapped/synthetic BTC as reserves. Sovereign balance = on-chain UTXOs under your keys + explicitly bounded Lightning exposure.
  2. Self-custody default. Custodial services are tactical, capped, and never used as “savings”.
  3. Full validation. At least one full node under your control; wallet backends and explorers ultimately point to that, not to random servers.
  4. UTXO-level accountability. Coins are discrete histories, not just a number. Every UTXO belongs to a clear pool and identity mask.
  5. Complexity bound. The topology must be operable by tired future-you and by heirs. Core reserves fit on a one-page diagram with a runbook.
  6. No blind governance trust. Protocol changes and wallet updates are deliberate choices; you reject “blacklist”, confiscation, or discretionary admin powers at the individual layer.
  7. Forced-seller risk tracked. Fiat obligations (taxes, rent, debt, legal risk) are modeled as external claims that can force you to sell BTC at bad times. You watch them explicitly.

Mental model The invariants are the constitution of this stack. Everything else—masks, tiers, tools—is implementation detail.

2. Identity Masks

The same human can appear to the world in different ways. Here we formalize those faces as masks: distinct identity surfaces with different privacy, narrative, and risk. Every UTXO belongs to exactly one mask.

Why masks? Without masks, all your activity collapses into one graph: public, ghost, and deep reserves get tangled. Masks keep those worlds separate so a leak in one doesn’t automatically expose the others.

Mask APublic Sovereign

The “public you” that can survive headlines, audits, and normie conversation.

  • Sources: KYC (if used), public earnings, visible donations/tips.
  • Use: public spending, visible support, taxes (if chosen), obvious on-chain moves.
  • Privacy: low by design; this mask assumes it can be watched.
Mask BGhost Operator

The “parallel you” that operates off-radar as much as reasonably possible.

  • Sources: Bisq, RoboSats, P2P trades, sovereign work paid in BTC, cleaned flows.
  • Use: off-radar operations, parallel infrastructure, strategic moves.
  • Privacy: high; every move is intentional, minimal, and topology-aware.
Mask CSacred Reserve

The “do not touch” layer: multi-decade reserves and migration/inheritance funds.

  • Sources: carefully cleaned flows from Mask B → Mask C; never Mask A → C directly.
  • Use: never day-to-day; only structural moves, major crises, or inheritance.
  • Privacy: highest; very few UTXOs, very few spends.

Optional: “Deployment” is a flag on A or B UTXOs earmarked for seeding other sovereign nodes. It’s not a separate mask; it’s a purpose tag.

3. Wallet & Custody Tiers

Masks are about who a transaction belongs to. Tiers are about where the sats physically live and how exposed they are. Every combination is “Mask X in Tier Y”.

How to read this Tier 0/1 are reserves, Tier 2 is daily life, Tier 3/4 are high-velocity rails. You can start with fewer tiers (see Pedagogical Tiers) and grow into this.

Tier 0Deep Cold Vault (Mask C)

The “if everything else is compromised, this still survives” layer.

  • Offline signing (airgapped or hardened hardware).
  • PSBT-only flows; no direct hot signing.
  • Descriptor-based recovery documented and tested.
  • Boring, well-understood scripts (e.g., P2WSH multisig).
  • Backups: steel + offline encrypted digital + runbook.
  • Inheritance: multisig + timelocks (“me now” OR “heirs after T”).
Tier 1Warm Vault (Masks A & B)

Long-term savings and mid-term operations. Touched rarely but not sacred.

  • Hardware signer + desktop coordinator.
  • Full coin control; labels; segregation by mask and exposure.
  • Connect to own node via privacy-preserving link (Tor/I2P where possible).
  • PSBT usage; seeds never typed into online general-purpose devices.
Tier 2Hot Wallet (Masks A & B)

Daily spending layer; like the cash in your pocket or checking account.

  • Strict balance cap; amount you’re willing to lose without ruin.
  • Never merges with warm/cold UTXOs.
  • Labeled “hot” pool; treated as expendable working funds.
Tier 3Lightning (capped)

High-velocity, low-friction payments. Great UX, higher protocol and implementation risk.

  • Non-custodial if possible; custodial only for tiny balances.
  • Capped exposure by percentage and absolute BTC denominated limit.
  • Channels funded mostly from Mask B pools.
  • Privacy is probabilistic; use route blinding/BOLT12 where available.
Tier 4Optional Federated eCash (Fedimint-style)

Community “prepaid card” rails. Amazing UX, but you always assume seizure or collusion is possible.

  • Prepaid-card posture: cap exposure; accept that it can go to zero.
  • Use in local, high-trust, high-velocity contexts only.
  • Never treated as savings; purely expendable working capital.

4. UTXO Pools, Labels, Hygiene

In Bitcoin, your “balance” is actually a pile of discrete chunks called UTXOs (unspent transaction outputs). Each one has its own history. Hygiene here means: you know which chunk is which, and you don’t casually glue unrelated histories together.

Pools (by mask + source)
  • A-KYC: Mask A, KYC-origin.
  • A-nonKYC: Mask A, public but non-KYC origin.
  • B-P2P: Mask B, P2P/Bisq/RoboSats acquisition.
  • B-earned: Mask B, sovereign work payments.
  • C-sacred: Mask C, deep reserves.
Rules of hygiene
  • No cross-pool merges unless explicitly ritualized (e.g., promoting B → C).
  • Use wallets with full coin control and labels; treat labels as part of your accounting.
  • Quarantine dust; never co-spend unknown dust UTXOs with valuable ones.

Simple rule If you don’t know exactly why two UTXOs belong together, do not spend them together.

5. Privacy Stack

The aim here is plausible deniability and surface reduction, not Hollywood invisibility. You keep the obvious leaks closed and only reach for heavier tools where they actually buy you something.

Always-on baseline

Embedded upgrades

Collaborative / market privacy

Strategy First, stop obvious leaks (address reuse, dumb merges). Then, add collaborative tools where they actually help your graph, not as a ritual checkbox.

6. Network & Node Layer

This is the “who tells you what Bitcoin is” layer. If you don’t validate yourself, someone else decides the rules for you.

Simple baseline One node at home or on a small server, wallets pointed at it via Tor, and you already beat “trust a random API” by orders of magnitude.

7. Scripts, Seeds, Passphrases, Duress

Here you decide what the chain will enforce for you: who can unlock funds, when, and under what conditions. Complexity buys you nothing if future-you or heirs can’t operate it.

Scripts

Seed & passphrase policy

Duress / sacrificial layer

Principle Anything you can’t explain simply to your future self or to your heirs is not security, it’s a booby trap for you.

8. Fiat, Credit, Synthetic Interfaces

Even in a Bitcoin-only worldview, the world still throws fiat at you: rent, tax, debt, jurisdictional fines, and random “one-time fees”. These are claims on future BTC.

If you ignore them, they choose the liquidation timing for you.

View Fiat is treated as an external constraint, not as “savings”. The question is: how much of it do you need to carry to keep BTC sovereignty intact?

9. Modes

The topology doesn’t change every day, but your operating mode does. Modes are pre-decided patterns for how you behave under different levels of threat.

Mode 1 — Normal

Default state when nothing special is happening.

  • Public spending via Mask A.
  • Parallel operations via Mask B.
  • Deep accumulation via Mask C.
  • LN/eCash within predefined caps.
Mode 2 — Stealth / Attention

“Eyes are on you” or “rules just changed” mode.

  • Trigger: surveillance signals, legal changes, targeted inquiry.
  • Freeze KYC-heavy and centralized CoinJoin activity.
  • Shift new activity to Mask B flows; reduce hot-wallet dwell time.
  • Use best privacy options available without looking abnormal.
Mode 3 — Emergency / Exit

“We might have to leave or be raided” mode.

  • Trigger: physical threat, imminent seizure, urgent relocation.
  • Prepare or activate minimal exit stack (small, sufficient BTC, highly accessible).
  • Prioritize mobility + ability to reconstitute later over squeezing every sat.
  • Offer sacrificial tiers to protect core reserves.
Mode 4 — Posthumous / Incapacitation

You can’t act, but your topology still has to resolve.

  • Timelocks/multisig enable heir access after T or other conditions.
  • Non-secret runbook explains what exists, which masks, and safe consolidation paths.

Why predefine modes? When something breaks, you won’t invent a plan from scratch. You will do whatever is easiest and most obvious. Modes make the easiest option the least destructive one.

10. Rituals, Audits, Collapse/Reset

Rituals are scheduled moments where you force yourself to look: check assumptions, test backups, and decide whether to refactor.

Monthly
  • UTXO pools still segregated by mask?
  • Hot/LN/Fedimint within caps?
  • Node healthy? Disk, bandwidth, peers okay?
Quarterly
  • Cold restore test (sandbox): can you reconstruct from backups?
  • PSBT round-trip: construct, sign, verify, broadcast (or dry run).
  • Update fee/mempool/pinning understanding + scan tool threat environment.
Yearly
  • Review cosigners, heirs, jurisdictions, life changes.
  • Do scripts still match your actual intent?
  • Retire or merge masks if they’re no longer needed.
Collapse / Reset Protocol

A pre-decided plan for “if X happens, we pull this lever and move”.

  • Define triggers: cosigner compromise, legal action, major 0-day, relationship breakdown, etc.
  • On trigger: migrate to new descriptors/keys; decommission old identities/masks.
  • Document new topology; destroy obsolete maps/runbooks.

11. Pedagogical Tiers

Not everyone needs the full topology on day one. This section shows how to teach and adopt this stack in stages.

Tier 1 — Minimal

“Get off zero exchange risk and not blow yourself up.”

  • Single mask (no public/ghost split yet).
  • Cold/hot split (basic reserves vs daily spending).
  • Basic UTXO discipline (no address reuse, basic labels).
  • Start earning directly in BTC where possible.
Tier 2 — Intermediate

“You’re a serious user, not a tourist.”

  • Masks A/B (public vs ghost split).
  • Regular P2P acquisition/exit rails.
  • Basic privacy primitives in use (coin control, some Payjoin/CoinJoin).
  • Lightning with explicit cap.
Tier 3 — Advanced (this document)

“Full sovereign topology with teaching/transmission baked in.”

  • Masks A/B/C fully used.
  • Scripts-as-law for inheritance and governance.
  • Duress layer with sacrificial wallets.
  • Explicit fiat-claim modeling.
  • Defined modes + rituals + collapse/reset protocol.

Onboarding tactic When teaching others, aim for Tier 1 in one session, Tier 2 over months, and treat Tier 3 as an apprenticeship.

12. Summary

At the Individual layer, “Money & Finance” in the Sovereign Stack is not just “have a wallet”. It is a full topology:

Relation to the civOS map On the Sovereign Stack map, this page is: Layer = Individual, Module = Money & Finance. The same module will look different at Household, Business, Community, and Citadel—but it will rhyme with this.

Appendix — Tool/Hardware Mapping (Pinned baseline: Jan 2026)

Everything above is conceptual topology. This appendix maps those concepts to concrete open-source tools and hardware as of a specific snapshot in time. You don’t need every item on this list; treat it as a menu of known-good building blocks.

Snapshot Versions and projects evolve. This appendix is a pinned baseline for one moment in time, not a live update feed.

ConsensusValidation backbone
  • Bitcoin Core v30.2 (bitcoincore.org)
  • Tor transport (Core tor.md: GitHub)
  • Note: avoid wallet migrations on 30.0/30.1 (wallet migration deletion bug context).
DesktopPrimary coordinator (“desktop brain”)
BackendsPrivate wallet backends (self-hosted)
ExplorerPrivate block explorer
Invariant mappingHard invariants → implementing components
  • Bitcoin-only base: Bitcoin Core + Sparrow/Electrum + BTC-only firmware options (e.g., BitBox02 BTC-only).
  • Self-custody default: PSBT signing flows via Sparrow/Specter + offline signers.
  • Full validation: Bitcoin Core full node under your control.
  • UTXO accountability: Sparrow labels + coin control as your main operating surface.
  • Complexity bound: standard scripts + standard PSBT; minimize unnecessary coordinator diversity.

Mask enforcement (wallet topology)

Clean mapping
  • Separate wallets (separate seeds/descriptors) per mask inside Sparrow.
  • Optional watch-only exports to mobile for visibility without key exposure.
  • Mask C signer quorum never used by any hot spend path.
Tools
  • Sparrow: separation + labels + coin control, good for multi-mask operation.
  • Electrum: multiple wallet files + labels (alternative coordinator).

Tier mapping (example tool/hardware sets)

Tier 0Deep Cold Vault (Mask C)
  • Coordinator: Sparrow multisig.
  • Signers (FOSS-max): Passport (GitHub), Jade (GitHub), SeedSigner (GitHub).
  • Alt signer: BitBox02 BTC-only (GitHub).
  • Optional (source-available license posture): COLDCARD (license).
Tier 1Warm Vault (Masks A/B reserves)
  • Sparrow + hardware signer (single-sig or multisig).
  • Wallet queries via electrs/Fulcrum backend (privacy boundary).
  • Hardware: pick one signer family from Tier 0 to reduce complexity.
Tier 2Hot Wallet (daily, capped)
  • On-chain mobile: BlueWallet (GitHub).
  • LN mobile: Blixt (GitHub).
  • Pattern: BlueWallet (on-chain) + Blixt (LN) = decoupled surfaces for on-chain vs Lightning.
Tier 3Lightning node (capped)
  • Server: Core Lightning (CLN) — Offers/BOLT12 path (docs).
  • Remote ops: ZEUS + Nostr Wallet Connect (NIP-47: spec).
Tier 4Federated eCash (optional)

Privacy primitives (feature → implementation)

Payjoin
  • BIP78 (bips.dev)
  • Receiver: BTCPay Server Payjoin (docs)
  • Power user: JoinMarket Payjoin (docs)
  • Async Payjoin v2: BIP77 (bips.dev), payjoin.org (site), rust-payjoin (GitHub).
Silent Payments / CoinJoin
  • BIP352 (spec)
  • Adoption uneven; treat as optional until fully supported end-to-end.
  • JoinMarket (CoinJoin suite: GitHub)

Network/node “known recipes” (optional)

Node distro patterns
Duress / inheritance-grade tooling
  • Liana (timelocks/recovery: GitHub)
  • Duress PIN/wallet features exist across multiple signers; keep sacrificial layer separate by topology, not just UI.

Fiat obligations modeling (local-first)

hledger
ledger-cli
Beancount

Mode triggers (tool emphasis)

Normal
  • Sparrow + own backend + routine LN via CLN/ZEUS.
  • Payjoin where counterparties support it.
Stealth
  • Shift acquisition rails: Bisq (GitHub), RoboSats (GitHub).
  • Privacy primitives: BTCPay Payjoin + JoinMarket mixes.
One-line BOMDefault picks (example “perfected stack” snapshot)
  • Node: Bitcoin Core v30.2 + Tor + electrs + mempool.
  • Desktop brain: Sparrow v2.3.1.
  • Cold (Mask C): Sparrow multisig + Passport + Jade + SeedSigner.
  • Warm (A/B reserves): Sparrow + single hardware signer + own backend.
  • Hot: BlueWallet (on-chain) + Blixt (LN).
  • LN node: Core Lightning + ZEUS + NIP-47.
  • Payjoin: BTCPay Server (receive) + JoinMarket (power user).
  • Accounting: hledger (or ledger-cli).
  • Timelock inheritance: Liana.
  • Optional eCash: Fedimint + Cashu protocols.