This section defines the starting assumptions for any community that shares a treasury. It explains what is always true at this layer, regardless of how aligned or “values-driven” the group feels right now.
Translation: design for people moving, burning out, or disappearing. The money system must survive that, not freeze because someone is “busy.”
Translation: politics, vibes, and good intentions cannot save a treasury that is structurally easy to hijack or accidentally leak.
Mental model Think of this layer as the shared cash register plus long-term vault for a group that will always have disagreements and turnover. The design assumes that reality, instead of hoping everyone stays aligned forever.
These are hard rules. If a community violates them, the system may still function, but it is no longer vSOV-COMM-M3.2. Everything else builds on top of these invariants.
Anything that can be frozen, printed, or rug-pulled is a rail, not a reserve.
Every UTXO “belongs” to a specific purpose bucket. The label is the memory of why the sats exist, so you don’t accidentally repurpose them later.
Descriptors describe how funds can be spent. PSBT keeps construction and signing separated, so one compromised machine cannot steal everything.
If a single person going offline can lock the treasury, the design is wrong, no matter how trusted they feel.
Emergency powers are pre-defined scripts and thresholds, not ad-hoc “trust me, it’s urgent” stories.
There is a transparency ledger (high level) and a settlement ledger (UTXOs). You don’t expose people’s exact addresses just to look virtuous.
Leaked policy files, PSBTs, and descriptor exports are how attackers reconstruct who controls what. They are treated like keys.
Any address open to the public will eventually receive weird or malicious coins. Those go to quarantine, not into the main treasury.
The mempool can be used as an attack surface. Pinning is treated as a risk to be designed around, not “wallet UX weirdness.”
Lightning and federated systems move value; they don’t hold deep community savings. They are hot paths, not vaults.
Hostile environment assumption This layer treats “finance ops” as a hostile environment: external attackers, internal social capture, donor pressure, and accidental artifact leakage are all expected, not exceptional.
The community treasury is expressed as named buckets. Each bucket is a distinct pot of BTC with its own purpose, risk profile, and unwind rules. Buckets keep intent and constraints visible when making decisions.
Buckets are like separate mini-treasuries. Mixing them in a single spend is an exception with a paper trail, never a casual convenience.
This is the working cash drawer: small, hot, and expendable.
This is where mutual aid and vulnerable recipients are served. Privacy beats “maximum visible transparency.”
Funds locked to a specific project with clear completion or refund rules.
The long-term survival pool. Movement is slow, multi-reviewed, and logged.
Temporary funds for a specific event. Reconciled and closed immediately afterwards.
Used to pay for skills, hardware, and setups that increase future autonomy (e.g. nodes, multisig, ops training).
Reserved for clean splits when the community needs to fork peacefully.
Practice check If you can’t answer “which bucket is this UTXO in?” the treasury is already drifting. Labels and bucket rules pull it back into clarity.
Money handling is split into three roles. No single person or device should construct, approve, and audit the same spend.
They turn the agreed manifest into a PSBT. They are not trusted to move funds.
They hold key material. Their job is to check that the PSBT matches the manifest, then sign.
They reconcile UTXOs, ledgers, and public reports. They never sign spends they themselves audit.
Tools lower risk, but the last line of defense is humans checking what they are about to sign. That step is non-optional.
Every community spend follows the same five-step pipeline. This stops “special case” chaos and keeps both signers and members clear on what happened and why.
The proposal is what, from where, and at what level of risk — kept as numbers and classes, not narratives.
Any checked item auto-escalates signing threshold by +1 tier (+2 for severe).
Checklist is filled by auditors (R3). Auditors cannot also be the signing humans for that spend.
The manifest is the source of truth for signers. The PSBT must match it exactly.
No signer signs “because the system made it.” They sign because they personally checked the PSBT against the manifest.
Members see that a spend happened, from which bucket, and at what scale, without exposing exact addresses by default.
Pipeline invariant No spend skips steps. “We were in a hurry” is not a valid reason to bypass the manifest or dependency checklist.
This section defines multisig policies for each bucket. The goal is to survive people leaving, while still making theft and capture hard.
Avoid 2-of-2 for communities: it fails under routine churn.
If this gets drained, it should hurt but not kill the community.
Focus on preventing collusion and coercion for vulnerable recipients.
Enough friction to avoid misuse, but not so much that the project stalls when one person moves.
Treated like the community’s spine: slow to move, hard to capture.
Designed for lots of small, frequent outputs to build capacity.
Must remain neutral and robust enough to support clean exit paths.
Rotation and disappearance are treated as normal events. This section makes the response automatic, not emotional.
People stepping off signer duty is expected and pre-planned, not a sign of failure.
Disappearance is handled like a routine maintenance script, not a crisis.
Descriptor-defined wallets make policy explicit and portable across operator turnover. Recovery does not depend on someone remembering “how it used to work.”
Not all incoming sats are equal. This section defines three paths that every inflow must be sorted into.
Typical member donations and direct receipts that match policy.
Funds given “for X only” are technically and procedurally bound to X.
Anything suspicious or unrequested lives in a separate quarantine zone, never mixed into core reserves.
Consolidating random dust into your main UTXOs is treated as a security bug, not a tidy-up.
The real perimeter is not just keys; it is also files and metadata. This section defines how to keep those from becoming a map for attackers.
Treat these as you would seeds or hardware wallets. They are not “just configuration.”
The community should always be able to answer “where is the real manifest/descriptor kept, and how is it rotated?”
Community compromise often happens through files, not keys: descriptor leakage, PSBT sprawl, and metadata exports are treated as primary attack surfaces.
Fee policy connects mempool behavior with community risk tolerance. It avoids “winging it” when a transaction is stuck.
If something jams here, just cancel and re-route; the risk is bounded by design.
Aid payouts should not be at the mercy of fee pinning games.
For core reserves and fork funds, overpaying once is cheaper than trying to coordinate fee bumps under attack.
“Fee authority” is about executing pre-agreed rules, not inventing new ones in the moment.
Rails are how value moves, not what the reserve is. Each rail has a clearly defined role and limit.
The base reality for community money. Everything else is built on top.
LN is for fast, small flows, not for storing the community’s future.
Privacy upgrade when the team can actually operate it, not a default that breaks base workflows.
Treated like a community checking account with clear exit drills, never as a core savings layer without explicit decision.
Money is power. This section measures and constrains that power so that big donors cannot silently steer the entire treasury.
Economic realism This treats donor power as a capture vector (economic), not a moral debate. If a single donor becomes too dominant, the finance rules tighten automatically.
Cell-splitting is how a community can cleanly fork when stress or disagreement gets too high. It is triggered by numbers, not arguments.
When these metrics trip, a split is considered structurally justified, no matter who is “right” in a debate.
The routing is defined in advance, so no one can weaponize split design when tensions are highest.
Splits happen via predetermined finance metrics + predetermined routing rules, to prevent narrative capture and endless political fights over who “owns” the treasury.
C1 is designed for mercy without permanent dependency. Aid is classified into three modes with different expectations and controls.
Short-term help to get someone through an acute situation.
Whenever possible, help is expressed as training, tools, or setups that increase future independence.
Long-term support is possible but must be intentionally renewed and clearly budgeted, not quietly expanded.
The aim is mercy that respects both recipients and the long-term survival of the treasury.
The community’s finance system should not become a detailed dossier on members’ lives. This section sets hard boundaries.
The less personal data is stored, the less there is to leak, subpoena, or weaponize later.
Every bucket must have clear exit rules, so the community can shut down projects or even the entire treasury without improvisation.
Short-lived funds resolve quickly; any leftover sats are routed by pre-written rules.
Even if the community ends, the last moves from reserves and duress funds are structured and visible at an aggregate level.
BTC-only purpose-partitioned buckets + churn-safe multisig + PSBT manifests + signer review doctrine + crown-jewel artifact hygiene + two-ledger accountability + dust/taint quarantine + pinning-aware fee authority + rails-scoped LN/Fedimint + formulaic donor/cell-split triggers + aid structured to reduce dependency.
This section ties the abstract rules above to concrete software and hardware. Tools can change over time, but any replacement must preserve these behaviors.
The community’s node is the only source of truth for balances and history, not random websites.
This keeps address lookups, balances, and labels inside the community’s infrastructure, not sprayed across public infrastructure.
At least one coordinator is used as the “control room” for the treasury.
The fewer custom integrations, the fewer surprises during a crisis.
Diversity in signers is as important as threshold choice: different vendors, different physical locations, different people.
BTCPay is the public-facing front door: donations, event tickets, dues, and simple payouts all come through here.
When the community is ready, Payjoin hides simple “A pays B” patterns on-chain for better privacy.
LN is treated as expendable working capital. If something catastrophic happens, channels are safely closed and funds return on-chain.
The accounting file is the high-level mirror of the UTXO reality, not an independent source of truth.
Transparency is about verifiable claims, not about exposing everyone’s exact financial footprint.
When fiat is involved, it stays on the edge of the system, not in the middle of the community reserve design.
Losing one element (device, passphrase, backup) should not destroy the treasury; attackers should need more than one element to steal it.
Without the policy (descriptors and script details), seeds alone may be useless. Policy backups are treated as critical infrastructure.
This toolchain section is intentionally aligned to the earlier invariants: purpose partitions (C0–C6), churn-safe thresholds, PSBT manifest discipline, and crown-jewel artifact hygiene.
These are the reference anchors you embedded in your spec. Keep them as the “normative spine” for the stack’s claims.