sov stack atlas
a working map of tools, protocols, and environments evaluated under one threat model
Last updated: March 2026
This page is the Atlas layer of Sov Stack Architecture.
It is a public, opinionated, forkable map of tools, protocols, ecosystems, and resource domains that currently clear a minimum sovereign bar under this practice’s threat model.
It is not a canonical standard. It is not neutral. It is not complete.
It is a working map built to be audited, argued with, copied, inverted, patched, and improved.
The purpose is simple: make the terrain visible enough that serious nodes can stop confusing scattered tools with coherent structure.
A wallet is not a stack. A privacy app is not a stack. A second passport is not a stack. A sovereign self-image is not a stack.
A stack is the set of tools, protocols, dependencies, and operating assumptions that determine whether you can still hold value, communicate, coordinate, hand off roles, and keep functioning when pressure arrives.
This page exists to map that terrain.
If this is your first encounter with the frame, start with the Primer.
The Atlas does three things at once.
- it names the domains that actually matter — not just money and wallets, but custody, communications, identity, hosting, legal and governance interfaces, health and care dependencies, land and physical systems, mobility, trade, and local continuity
- it records which tools, protocols, environments, and resource hubs currently look buildable under this model — including stronger, weaker, transitional, and bounded-trust layers
- it makes the present boundary of this practice visible enough to critique — what is included, what is excluded, what is unsettled, and where the weak points still are
That is the point of an atlas: not to eliminate judgment, but to discipline it.
Everything in Sov Stack Architecture runs on the same sequence:
Kernel → Atlas → Manuals → Deployments
- the Kernel defines the law-core, threat model, and standards
- the Atlas maps which tools, protocols, and environments currently clear a minimum sovereign bar under that model
- the Manuals turn that map into self-serve methods, audits, and field protocols
- the Deployments apply the same logic directly to a specific person, family, org, or local cell
Private work does not sit outside the public work. It pressure-tests it.
When a tool, vendor, category, or pattern fails in the field, the architecture gets patched and the public map changes with it. Old versions remain as historical records, not permanent law.
Inclusion does not mean perfection. It does not mean zero trust. It does not mean a tool is safe for every risk tier, every jurisdiction, or every competence level.
It means something narrower:
under this model, and with known tradeoffs, this tool or resource currently looks viable enough to build with.
Some tools increase local control but still leak metadata. Some preserve exit options but rely on bounded trust. Some are technically strong but operationally brittle. Some work well at one scale and become dangerous at another. Some are acceptable only as transitional layers, not as end states.
This page should help make those differences legible.
Omission does not always mean ignorance.
Usually it means one of four things:
- the tool or environment clearly fails the criteria
- it recreates dependency under a new brand
- it has not yet been evaluated seriously enough
- there is no current reason to build on it under this threat model
Absence is often signal.
A category that looks thin may indicate that good sovereign options do not yet exist there. A category that remains empty may be telling the truth about the current state of the terrain.
This Atlas favors tools, protocols, and environments that, where feasible:
- increase local control
- reduce dependence on single vendors, single jurisdictions, and single platforms
- preserve exit options for capital, identity, data, and coordination
- favor FOSS or inspectable code over black boxes
- reduce KYC, surveillance, and data exhaust
- allow graceful failure instead of total lock-in
- do not quietly recreate the same capture pattern they claim to solve
That does not mean every included item is “fully sovereign.”
The purpose of this page is not to reward ideological purity.
The purpose is to improve structural judgment.
In real life, a stack is often forced to use mixed layers. A family may be partly KYC’d. A small org may still touch hostile payment rails. A local cell may need bounded-trust arrangements before it can support cleaner structures. A high-vulnerability node may need more redundancy and support than a privacy purist would prefer.
That does not invalidate the work. It makes the tradeoffs real.
This Atlas should help people see the difference between a necessary compromise, a transitional layer, and a dependency being rationalized as sovereignty.
This Atlas assumes a world of rising pressure, not neutral conditions.
The default assumptions include:
- increasing financial surveillance and identity binding
- greater platform governance and de-platforming risk
- vendor and SaaS lock-in that quietly centralizes dependency
- communications and cloud layers that can censor, leak, or disappear
- jurisdictional tightening around money, movement, data, and speech
- fragile family and succession structures that collapse under stress
- a broader environment in which convenience repeatedly reintroduces capture
The practical target is not invulnerability.
The target is to reduce catastrophic dependence, preserve optionality, and make stacks harder to freeze, corner, or quietly absorb.
Different nodes face different risks.
- quiet users with modest but meaningful exposure
- public Bitcoiners or builders with visible footprints
- dissidents, organizers, land defenders, or people carrying asymmetrical downside
- families with children, elders, illness, inheritance complexity, or care burdens that make shallow solutions dangerous
This Atlas is biased toward moderate-to-high-risk users and communities. That means some recommendations may be overbuilt for casual users, and some will still be insufficient for heavily targeted users.
Competence matters too.
A tool that looks “more sovereign” on paper can make a stack less safe if deployed beyond actual capacity. Misconfiguration, unmanaged complexity, and ritualized overkill can create fragility just as easily as convenience can.
Use this page in four ways.
- as a terrain map — see which domains matter, where the stack is mature, and where it is still thin
- as a filtering layer — quickly rule out tools and environments that recreate obvious dependency patterns
- as a design aid — use category notes and classifications to think in systems rather than isolated gadgets
- as a patch surface — if the map is wrong, incomplete, or stale, that should become visible through use
The Atlas is useful only if it helps people build better judgment.
This is still a partial stack, not a complete one.
The strongest current coverage is around:
- Bitcoin, custody, Lightning, Cashu, Fedimint, Nostr, and adjacent infrastructure
- privacy, communications, identity, and self-hosting layers
- merchant and coordination tooling
- operating systems, servers, hosting, and network stack
- selected physical-world domains such as energy, water, food, health, land, mobility, and security resources
Some layers are stronger in the Manuals and Resources than they are here. Others are still immature enough that the Atlas can only mark the gap, not fill it.
That is normal. An honest map should show where the terrain is underdeveloped.
What follows is the current working category structure. Within each category live individual evaluations, indexes, and resource atlases.
- general sovereign infrastructure resources
- parallel civilization resources
- governance resources
- ancap resources
- agorism resources
- mutual aid resources
- legal, community & justice resources
- disaster resilience & emergency management resources
- physical security resources
- myth, ritual, & symbol resources
Repeated tool choices harden into standards.
Repeated standards harden into operating assumptions.
Repeated assumptions harden into law, whether anyone names it that way or not.
That is the deeper function of this page.
Not to pretend that tools alone create civilization. But to acknowledge that over time, the tools chosen, the vendors tolerated, the trust models accepted, the failure modes normalized, and the kinds of dependence excused all shape the kind of world a stack can actually support.
This is why the Atlas matters. Not because every row is sacred. Because repeated practical choices become structure.
A serious atlas cannot just list tools and say “good” or “bad.”
It has to make the weak points visible.
- bounded-trust systems — where a tool or protocol reintroduces social trust, federation trust, operator trust, or recovery trust
- metadata exposure surfaces — where identity, IP, communications patterns, payment flows, or social graph leakage still matter
- friendly centralization — where a tool is nominally open or sovereign-compatible but the real ecosystem is clustered around a few providers, maintainers, relays, pools, allocators, or defaults
- jurisdictional concentration — where a stack that looks distributed on the screen collapses into one legal or geographic choke point underneath
- competence requirements — where misuse, overcomplexity, or poor implementation creates more risk than convenience would have
- graceful-failure limits — what happens when the tool fails, the maintainer disappears, the quorum breaks, the relay goes dark, the provider changes terms, or the person who knows how it works is gone
The map becomes more truthful when it includes how things fail, not just what they promise.
This page is not trying to become the internet’s master list of tools.
It is not trying to be neutral.
It is not trying to replace first-hand testing, local judgment, or jurisdiction-specific research.
It is not promising that the tools listed here make someone sovereign by association.
And it is not pretending that technology alone resolves family fragility, governance failure, care burdens, death, burnout, or human conflict.
The Atlas is a working map. A map is useful precisely because it is not the territory.
The biggest gaps are not more wallet rows or extra software categories.
The biggest gaps are the glue layers that make a stack survivable, reproducible, and transferable.
This Atlas still under-specifies:
- law-core and continuity — how rules, agreements, norms, and shared stories are remembered, enforced, and updated without mutating into bureaucracy, cult, or vague custom
- succession, inheritance, and handoff — how stacks survive death, burnout, departure, conflict, and generational transfer without recreating capture or chaos
- repair and recovery between layers — how people move between tools, threat tiers, life stages, and jurisdictions without losing continuity or collapsing back into centralization
- institutional and ritual layers — how a stack becomes lived structure rather than only a set of diagrams, preferences, or branded beliefs
- deeper physical and bioregional coverage — food, water, energy, fabrication, shelter, and ecological systems tailored to actual terrain rather than abstract aspiration
- sharper terrain intelligence — more explicit mapping of adversaries, chokepoints, and synthetic defaults inside each category: where quiet capture is actually happening
This is where the Atlas must keep growing. Not just outward into more tools, but upward into more coherence.
Everything here should be treated as field code, not untouchable doctrine.
If a serious flaw, blind spot, misclassification, or stale assumption is found, the default stance is:
- patch the design
- note the change
- deprecate the older version where needed
- credit the critique
- and, where appropriate, tip sats
Adversarial review is part of the operating model, not an interruption of it.
A stack that cannot absorb critique becomes brittle. A map that cannot be patched becomes propaganda.
The Sov Stack will not be defined by this page.
It will be defined by the stacks people can actually live inside, defend under pressure, hand off to others, and keep functioning without immediate recapture.
This Atlas is one attempt to make that terrain visible enough to work on.
Use it as a map. Challenge it where it is weak. Patch it where it fails. Fork it where your threat model differs. Ignore it where it is wrong.
But do not confuse scattered tools with structure.
That confusion is one of the main ways people lose years.