Household Money/Finance Stack — Sovereign (vSOV-H-2.0)

0. Precedence & Frame

This module zooms into one slice of the Sovereign Stack map: Layer = Household, Module = Money / Finance. It assumes there are one or more adults who share daily life, share expenses, and plan together over years—not just roommates splitting rent.

The Household layer sits between the Individual stacks and everything above (business, community, citadel). It must give the household real shared power without erasing the sovereignty of the individuals inside it.

Orientation Read this as a design template for how a household can structure its Bitcoin flows, reserves, and decision-making. It doesn’t tell you what to invest in; it tells you where sats live, who can move them, and what happens when people or tools fail.

• Layer: Household (tight trust, shared life, low churn).
• Segment: Money / Finance only.

Precedence rule Household architecture cannot override individual invariants. Household pools are explicit, policy-defined pools—not a sponge that slowly absorbs everyone’s personal reserves “because we’re family”.

1. Household Law-Core (Non-Negotiables)

These are the household’s hard rules. If they’re broken, you’re no longer running this stack; you’re running something else. You can still choose to break them, but it should be a conscious decision.

1. Bitcoin-only reserves at the core (on-chain UTXOs + explicitly bounded LN working balances).
2. Self-custody default; custodians (including LN custody/federations) are capped rails, never treasury.
3. Shared spending authority is explicit: who, what, limits, thresholds.
4. No silent layer-mixing: personal deep reserves never “blend” into household pools without a labeled, intentional move.
5. Descriptors + PSBT are the coordination fabric for all serious wallets.
6. Fee/pinning reality is encoded per tier (no magic thinking about “cheap forever”).
7. Any dual-control design includes an escape hatch (timelock recovery or modeled third key).
8. Complexity is bounded by the least-technical adult (design cannot exceed the weakest operator).
9. No household-core leverage/yield/rehypothecation without explicit multi-party consent and isolation into a separate risk bucket.
10. External obligations (fiat/legal) are modeled as adversarial claims that can force liquidation.

Mental model This section is the constitution for household money. The rest of the document (tiers, roles, tools) are the code that implements it.

2. Core Objects: Tiers, Masks, Roles

Before touching tools, you need the objects the household works with: capital tiers (what money is for), masks (how it appears to the outside), and roles (who actually does what).

Capital Tiers

Same idea as Individual cold/warm/hot, but now sized for the whole household.

Household Masks (appearance of flows)

Masks here are the household-level face to the outside world, mirroring the individual Public/Ghost/Sacred concept but applied to shared funds.

Functional Roles

These are functions, not personalities. One person can hold multiple roles, but the roles themselves are clearly defined.

Fractal rhyme At Individual layer you have Masks A/B/C. At Household layer you get H-Public/H-Ghost/H-Sacred overlaying H0/H1/H2. Same pattern, different scale.

3. Wallet & Key Topology

Tiers/masks/roles are the idea. Topology is the concrete map: which wallets exist, who can sign, and how failure is handled.

H0 — Hearth

Everything that needs to move often: groceries, transport, small emergencies. This is where most mistakes are allowed to happen by design.

H1 — Citadel Wall

The main household savings / buffer. Harder to move, harder to mess up.

H2 — Seed / Relic

Long-horizon reserve that assumes people will die, move, fall out, and change.

How to use this Draw this section as boxes and arrows for your own household. Every wallet you actually use should map cleanly to H0/H1/H2 and H-Public/H-Ghost/H-Sacred.

4. Fee & Mempool Doctrine

Fees and mempool behavior are not “nerd details”; they decide when you can move money and when you can’t. Each tier has different tolerance for being stuck.

Lightning boundary Lightning is working capital for H0/H1 only. H2 never lives in LN form.

5. Privacy & Telemetry

At the household level, privacy is less about “being invisible” and more about not creating a single obvious graph that mixes every family member, every income source, and every long-term reserve.

• Baseline: no address reuse; avoid unnecessary multi-input merges; never merge personal deep reserves into household pools.
• Advanced tools are gated: Payjoin/coinjoin/reusable identifiers are optional tactics, not structural dependencies.
• Camouflage doctrine: not every ritual event maps to an on-chain signature; H2 remains inert and boring.

Simple rule If you cannot explain why two UTXOs belong together, don’t spend them together.

6. Node & Network Posture

The household node is the shared truth appliance. It answers: “What is Bitcoin right now?” and “Did this payment actually exist?”

• Household full node is the truth source; significant balances are verified locally.
• Prefer privacy transports (Tor/I2P); track encrypted P2P transport when mature.
• Eclipse/peer manipulation is treated as a finance risk, not just a technical curiosity.

Fractal link Individual stacks can still run their own nodes. The household node is the shared layer they may plug into, not a single point of control.

7. Fiat, Credit, Law

Even in a Bitcoin-first household, there are still fiat-denominated demands: rent, taxes, debt, court orders, child support, medical bills. These act as external claims on future BTC.

• Recurring obligations (rent, support, care, tax, debt) are modeled as forced-seller triggers.
• H1 sizing explicitly covers these claims to prevent panic liquidation.
• Legal attack classes are mitigated by slow, documented treasury formation and pre-written separation-mode rules.

Design goal The household should rarely be in a position where a court letter or landlord text forces you to dump BTC at the worst possible time.

8. Human Adversaries

The hardest problems are not protocols; they’re people. Household design has to assume that moods change, addictions appear, and secrets leak.

Assumption Trust is a starting state, not a permanent guarantee. The stack should survive even if cooperation temporarily collapses.

9. Extended Family Support

Many households support parents, siblings, or others. This needs to be budgeted and bounded, not an endless drain.

• Small help: H0 (ad-hoc gifts, one-off support).
• Recurring help: defined H1 sub-pool with caps and review cadence.
• H2 is not a bailout reservoir for extended family.

10. Heirs & Succession

“What happens if we’re gone?” is not a philosophical question here; it’s a design requirement encoded in scripts and documents.

• Distribution is not strictly equal-by-blood; weight competence, alignment, and risk tolerance.
• Heirs receive intent + reconstruction instructions; they are expected to migrate to their own stacks.

Outcome The household doesn’t become a permanent holding company. It’s a staging ground for future individual and citadel stacks.

11. Modes

Modes are predefined “how we behave now” states. When the situation changes, you don’t invent a plan from scratch; you switch mode.

Practice Modes are only real if everyone in the household knows what they mean and can describe their own behavior in each mode.

12. Node-Factory

The Household is not just a consumer of Bitcoin. It’s a node-factory for sovereign individuals.

1. Capped small wallet (BTC/LN) + backups for each emerging node.
2. Run a small node together; learn “we verify our own money.”
3. Minor signer in a training multisig; PSBT practice with low stakes.
4. Spin out an individual stack integrated with, not subordinate to, the household.

Goal The household should export sovereign adults, not produce permanent dependents.

13. Migration Phases

Most households already have messy fiat systems. Migration is not “flip a switch”, it’s a sequence.

1. Map existing flows (observe first; write down what already happens).
2. Parallelize small H0 categories in BTC while legacy fiat continues.
3. Build H1 buffer in BTC; begin making decisions from a BTC-denominated mental frame.
4. Encode H2 deep cold + scripts + inheritance + roles/modes/rituals.

Reality It’s normal for fiat and BTC to coexist for a while. The key is that BTC structure is designed on purpose instead of emerging by accident.

14. Rituals & Audits

Rituals are scheduled “we stop and look” moments. They keep the stack from drifting into mythology.

Minimum viable ritual If nobody in the household can remember the last time you ran a drill, the stack is running on hope, not design.

Addendum A — Household Implementation Layer

This addendum connects the law-core and objects to concrete, day-to-day “which wallet does what” decisions, without yet naming specific apps.

Balance-sheet topology (separate buckets)

Think of this as the household’s internal balance sheet: three main BTC buckets with different rules.

Governance: authorities, permissions, failure routing

Here we map roles to keys so that responsibility is not just verbal, but cryptographically enforced.

Addendum B — Portability Standards (No Tool Lock-in)

This section defines the standards that keep you free to change tools without redoing your entire architecture.

Portability rule If you can’t migrate the treasury with descriptors + PSBT + labels, it isn’t sovereign—it's a vendor lease.

Addendum C — Storage & Signing Architecture

This is the hardware/software side of “who holds keys” and how they’re used. The goal is diversity without chaos.

Addendum D — Node Backbone & License Reality

Node distributions and UIs are often packaged and licensed in different ways. This section treats them as shells around a core, not the core itself.

Addendum E — Lightning Layer (Household Rules + App Risk)

Lightning is where UX is great and risk is higher. Household policy must treat LN as working capital only.

Addendum F — Acquisition Rails (P2P + Hygiene Pipeline)

“How does BTC enter the household?” is as important as where it sits. This section covers rails and the hygiene pipeline between “just bought” and “deeply stored”.

Addendum G — Privacy Pipeline (Tool-Plural + Enforcement Climate)

This extends the earlier privacy section by assuming that specific tools can disappear or be criminalized. The household’s privacy posture should survive that.

Doctrine Privacy tools may disappear or be attacked; household privacy must still function when any single tool is removed.

Addendum H — Accounting / Budget / Shared Expenses

This is the money meaning layer: how the household decides what each sat is “for”, and how that meaning survives wallet/tool changes.

Addendum I — Operational Playbooks (Drills)

Drills turn the stack from a diagram into something that can actually survive bad days. Each drill is a small, repeatable scenario.

Addendum J — Stack Killers (Failure Points)

This is the adversarial checklist: ways the household stack can silently degrade into “we trust an app and hope”.

Appendix — One-to-One Tool Map (Household)

Stack survival The household stack survives tool churn because the standards (descriptors / PSBT / labels) and the topology are the real substrate.