Business Layer · Money/Finance

Scope: production/commerce; invoices; refunds; AR/AP; payroll/contractors; treasury; reserves; liabilities

1. Hard invariants

This section defines the non-negotiable laws of the business money stack. If any of these are broken, the system may still run, but it is no longer this reccomended stack.

  1. BTC-only monetary base. Reserves are on-chain BTC under keys; rails (LN/etc.) are capped working capital.
  2. Self-custody default. Custody is tactical, capped, and time-bounded.
  3. Descriptor-native wallet policy + recovery. Descriptor wallets are default in Core 23.0+.
  4. PSBT-native spend coordination. PSBT is the multi-party interchange format (BIP174).
  5. Private descriptor material is seed-class. Anything that can emit private descriptors is treated as a crown-jewel leak surface.
  6. Avoid-reuse is governed (where feasible). Dirty/clean tracking is an explicit wallet posture (Core has an avoid_reuse mechanism).
  7. RBF/pinning economics assumed. Replacement rules imply absolute-fee pressure; multiparty workflows are pinning-vulnerable.
  8. Processor/workflow systems are hostile-by-default. Compromise of workflow does not imply treasury compromise.
  9. Accounting is an external-claim interface. Accounting determines what is owed/recognized; it must not become a custody driver. (Accounting standards references included in your spec.)

Business posture The business layer assumes constant adversarial pressure from counterparties, platforms, processors, staff churn, and deadline-driven mistakes. Treasury survives compromise by design.

2. Object model (what exists)

This defines the things the business stack acknowledges: where BTC can sit, what is owed, and how revenue is encumbered. Everything else (apps, UIs, spreadsheets) must map cleanly onto these objects.

2.1 Custody buckets (where BTC lives)

Buckets are treasury topology, not accounting categories. Each one has its own risk, dwell time, and access profile.

B0 Sales Intake Float
short dwell · sweep bucket
B1 Refund Buffer
refunds/returns · prevents reserve-touch
B2 Accounts Payable
vendors
B3 Payroll / Contractors
deadline-sensitive
B4 External Claims Set-Aside
tax + known fiat claims timing buffer
B5 Capital Reserve (runway)
rare moves
B6 Deep Reserve / Strategic
ultra-rare moves
B7 Transmission / Deployment Fund
propagation spend · capped · proof-based
B8 Sacrificial / Duress Buffer
credible loss layer · bounded · formula replenishment

2.2 Liability ledgers (what is owed)

Liability ledgers describe promises the business has made that may or may not touch custody today, but will constrain future moves.

L0 Refundable customer liabilities
L1 Unfulfilled deliverables
deposits/prepayments/subscriptions owed
L2 Third-party funds
marketplace custody adjacency; target = minimize to zero

2.3 Revenue pools (source encumbrance)

Same sats, different risk signatures. Revenue pools classify how “contaminated” an incoming flow is by surveillance, custody, or clawback power.

R-A Public / Legible
platform/KYC/obvious rails
R-B Operator-grade
direct BTC commerce; lower encumbrance
R-X Encumbered
identity gates · clawback/hold power · surveillance covenants · custody adjacency
Routing rule (encumbrance)
  • R-X cannot silently fund B6.
  • It must pass an explicit encumbrance / quarantine pathway before any deep-reserve interaction.

Design aim No bucket, liability, or revenue pool is an accident. Every BTC UTXO must be placeable into exactly one custody bucket and (where relevant) one revenue provenance class.

3. Registries (business-killer control plane)

Registries are the address books the business relies on for getting money in and out. If they are compromised, invoice substitution and payroll hijack follow. This layer turns them into signed, fail-closed artifacts.

RRReceive Registry
  • All inbound destinations.
  • On-chain: descriptors/xpubs; LN: offer endpoints; any reusable receive identifiers.
BRBeneficiary Registry
  • All outbound destinations (vendors, contractors, payroll endpoints).
Signed Registry State (fail-closed root of truth)
  • Registry state is published as a signed artifact by a signer threshold.
  • Any registry change is invalid until a new signed state exists and is verified out-of-band by signers.
  • Registry truth is not “whatever the server UI shows.”

Purpose: defeat invoice destination substitution + beneficiary swaps under server compromise.

Root-of-truth rule If an address or offer cannot be traced back to signed RR/BR state, it is treated as hostile—even if it appears in the “official” dashboard.

4. Roles & permissions (separation of duties mandatory)

Roles split who can see, build, and sign. This prevents one compromised human or machine from moving serious BTC without others noticing.

R-OPSWorkflow/Server Operator
  • Runs BTCPay/workflow tooling.
  • Cannot move meaningful buckets.
R-CONConstructor
  • Builds manifests + unsigned PSBTs from approved proposals.
R-SIGSigners
  • Threshold policy holders.
  • Sign PSBTs and registry state artifacts.
R-AUDAuditors
  • Watch-only verification + reconciliation.
  • Ledger integrity + drift detection.
R-FEEFee Authority
  • Scoped right to rebuild replacement PSBTs within ceilings and deadline classes.
Constraint
  • No person may be R-CON + R-SIG for the same spend.

Human firewall This separation-of-duties layout is the human analogue of multisig: no single role can both create and approve value-moving transactions.

5. Inbound revenue stack (invoicing + rails) with substitution resistance

This section draws the front door for money entering the business: invoices, rails, and the guarantees that invoice destinations haven’t been swapped.

5.1 Workflow layer (routing, not treasury)
  • BTCPay Server is the invoice/payout workflow surface.
  • Refunds are built on Pull Payments; payouts are tied into Pull Payments (refunds/salary/withdrawals).

Boundary rule: BTCPay may request payouts/refunds; treasury spending requires PSBT signing under bucket policy.

5.2 Rails — on-chain
  • Default for larger settlement.
5.2 Rails — Lightning
  • Throughput rail; capped working capital.
5.2 Rails — BOLT12 Offers
  • Upgrade slot for reusable LN payment requests.
  • Endpoints treated as public infrastructure.
5.3 Invoice destination integrity (inbound)
  • Every invoice destination must be derivable from the signed Receive Registry state.
  • Any deviation → invoice invalid (fail-closed).

Key idea The workflow server can be fully compromised without granting attackers the ability to redirect invoice funds, as long as RR and derivation rules are enforced.

6. Outbound spend pipeline (manifest → PSBT → sign → broadcast)

Outbound spend is always a four-step ritual: manifest, construction, signing, broadcast. The manifest is the truth; PSBTs must match it.

6.1 Canonical manifest (the signing truth)
  • Bucket (B0–B8) + revenue pool provenance (R-A/R-B/R-X where relevant)
  • Outputs (destination + amount)
  • Fee ceiling + deadline class (D0–D3)
  • Purpose code: AP / payroll / refund / sweep / reserve move / transmission / duress
  • Predicate flags (binary escalators)
6.2 Predicate-triggered escalation (no semantic classes)

Any true predicate auto-escalates signing threshold by a pre-set amount.

  • Touches RR/BR (registry state changes)
  • Touches B5/B6
  • Introduces custodian / identity gate / recurring obligation
  • Merges previously partitioned UTXO sets
  • Invokes RBF/fee bump authority
  • Pays from or replenishes B8
  • Any B7 payout to a repeat recipient beyond set cadence
6.3 PSBT construction and signing
  • Constructor builds PSBT strictly from manifest (BIP174).
  • Independent reconstruction: for high-risk predicates (RR/BR/B5/B6/B7/B8), a second constructor rebuilds; output set must match.
  • Signers verify outputs/fees against the manifest before signing.

Invariant No PSBT is ever signed because “it came from the system.” It is signed only because it matches a human-reviewed manifest.

7. Fee doctrine (pinning-aware) wired to business deadlines

Fee policy binds Bitcoin’s mempool reality to the business’s calendar reality. Deadlines are explicit; so are ceilings.

Pinning assumption
  • Replacement requires higher feerate and higher absolute fee; multiparty workflows face pinning pressure.
7.1 Deadline classes (encoded in every manifest)
  • D0 no deadline (wait acceptable)
  • D1 business SLA (fulfillment)
  • D2 payroll cutoff
  • D3 vendor shipment dependency / existential ops
7.2 Fee authority scope (R-FEE)
  • May rebuild replacement PSBTs only within bucket ceilings + deadline permissions.
  • Predicate constraints hold: urgency cannot “unlock B6.”
  • If fee ceiling exceeded: fail-closed into delay/renegotiate, not reserve-raiding.

Key boundary “We need this fast” never becomes a silent reason to drain strategic reserves. Deadlines move spends within buckets, not across them.

8. Refunds & payouts (operational reality without reserve bleed)

Refunds and payouts are the two high-frequency outbound classes. This section keeps them operationally smooth without letting them eat reserves.

Refunds
  • Refunds are implemented as an application on Pull Payments.
  • Refunds draw from B1 only unless explicit escalation.
  • Refund destination changes are governed by BR (cooling-off + signed registry state).
Payroll / contractors
  • Payouts are tied into Pull Payments and can be used for salary payouts.
  • Payroll/contractor payouts draw from B3.
  • Batch via manifests; signer-reviewed as a class.

Refund safety L0 and B1 are tightly paired: customer-facing promises are honored from a dedicated buffer, not from B5/B6.

9. BTCPay internal wallet caps (anti-drift)

BTCPay’s internal wallet is a hot zone. This section pins it down to being a thin membrane, not a shadow treasury.

BTCPay can batch payouts from its internal wallet context. Treat that surface as hot working capital only.

  • Amount cap: strict ceiling for internal wallet exposure.
  • Time cap: max dwell time for B0 float before sweep.
  • Missed sweep triggers Mode A (Attention) automatically.

10. Artifact hygiene (finance perimeter)

Artifacts are the files and metadata around money: descriptors, PSBTs, manifests, labels. This section defines what must never leave the enclave, and what can.

10.1 Crown jewels
  • Private descriptors are seed-class: never exported, never shared.
  • PSBT drafts: canonical store, strict versioning, retention limits.
  • Registry signed state: integrity-critical; immutable archive.
  • Labels/metadata: internal-only; never public reporting.
10.2 Sanitized reporting bundle (only allowed export)
  • Watch-only balances (public descriptors only)
  • Txids + manifests
  • Bucket reconciliation summaries
  • Liability ledger rollups (L0/L1/L2)

Absolute prohibition: private descriptors, PSBT drafts, and internal labels leave enclave.

Perimeter rule Auditors, regulators, and partners can see the sanitized bundle, never the crown jewels. Custody key material stays entirely inside the business.

11. Pricing reference doctrine (quotes + refunds) — mandatory

Pricing doctrine binds invoices and refunds to deterministic rules so customers cannot game volatility and L0 stays bounded.

Every invoice embeds explicit rules so L0 is bounded and B1 cannot be socially exploited.

  • Quote basis: sats-native vs fiat-indexed-at-invoice-time
  • Expiry / lock window
  • Refund basis: sats-returned vs fiat-equivalent + timestamp rule

12. Modes (triggered, deterministic)

Modes are global behavioral switches for the finance stack. They are triggered by events and change what is allowed without needing ad-hoc decisions.

Mode NNormal
  • Routine sweeps; standard approvals.
Mode AAttention
  • Triggered by missed sweep, registry change, anomaly.
  • Shrink caps; freeze high-risk changes.
Mode EEmergency
  • Compromise suspected.
  • Rotate descriptors/signers; invalidate old registries; operate minimal buckets only.
Mode CContinuity
  • Key-person loss.
  • Execute pre-written re-key + registry re-sign.

Descriptor-era benefit Descriptor-default policy in Core 23.0+ makes migrations and runbooks explicit objects with clean exports/imports instead of folklore.

13. Telos overlay (kept mechanical)

Telos buckets are the intentional spend zones that encode mission: propagation (B7) and duress / sacrifice (B8). They remain numeric and mechanical here; story lives elsewhere.

B7 Transmission
  • Capped and proof-based.
  • Dual-proof + repeat-recipient escalators.
B8 Duress
  • Credible-but-bounded.
  • Formula replenishment.
  • Depletion triggers Mode A/E.
Signal ledger (numeric-only)
  • Dependency deltas
  • Optionality/runway deltas
  • Disclosure-surface deltas
  • No narrative fields.

Separation Telos is acknowledged as a driver, but here it is constrained to numbers and thresholds, not stories. That keeps the business stack auditable.

Business-Money module kernel (one line)

BTC-only bucketed custody + explicit liability ledgers + signed receive/beneficiary registry state (fail-closed under server compromise) + invoice destination integrity + manifest→PSBT doctrine with independent reconstruction + pinning-aware fee authority tied to deadline classes + BTCPay as workflow bounded by hard/time caps + seed-class descriptor hygiene + sanitized reporting bundle + mechanical telos funds (B7/B8) with anti-capture constraints.

Business-layer toolchain mapped cleanly onto the stack

This section maps minimal, specific tools onto the abstract objects above. Tools are replaceable; the stack design is not.

0) Non-negotiable base (validation + wallet primitives)

Bitcoin Core (self-hosted full node + wallet backend)
  • Maps to: descriptors-as-policy + UTXO accounting posture.
  • Descriptor wallets default since Core 23.0.
  • Operational hooks referenced in your toolchain section:
    • avoid_reuse / wallet flag posture
    • listdescriptors(private=true) is hazardous and seed-class
Indexer spine (privacy + performance)
  • Purpose: avoid leaking wallet queries; speed ops; keep metadata local.
  • Pick exactly one:
    • Fulcrum (primary for business ops)
    • electrs (acceptable alternate)
  • Sparrow can talk to private Electrum servers or directly to Core.

1) Treasury workstation (coin control + PSBT + labeling)

Sparrow Wallet (desktop treasury console)
  • Coin control + fee control + labels + PSBT-first workflow.
  • Designed to run against your node/indexer spine.
  • License posture: Apache 2.0 (as noted in your toolchain section).
Multisig coordinator UI (role separation)
  • Specter Desktop as a dedicated multisig ops console (Core-centric, PSBT/HWI oriented).
  • Sparrow can coordinate multisig; Specter is the specialized control plane.

2) Signing hardware (airgapped PSBT, low-trust workflow)

Signer A — SeedSigner
  • DIY, airgapped, QR PSBT signing.
  • Stateless posture; designed for multisig workflows with Sparrow/Specter.
Signer B — BitBox02
  • Reproducible firmware build discipline is documented (per your cited docs).
Signer C — Passport
  • Airgapped appliance class; repo notes licensing posture (GPL inclusion noted in your spec).

Signer diversity Signer selection goal: orthogonal failure modes (vendor + firmware lineage + transport + physical location).

3) Merchant rail (invoicing, AR/AP, refunds, payouts, integrations)

BTCPay Server (self-hosted merchant processor)
  • Invoice surface + settlement tracking + payouts/refunds workflows.
  • Refunds: Pull Payments.
  • Payouts tied to Pull Payments: refunds + salary payouts + withdrawals.
  • Supports PSBT external signing; separation-of-duties via BTCPay→Sparrow PSBT workflow.
  • Integration surface: Greenfield API + BitPay-compatible API.
Privacy upgrade slots (merchant side)
  • Payjoin (BIP78) via BTCPay Payjoin (receiver enablement).
  • Optional: JoinMarket module exists in BTCPay docs; treated as specialized, not default merchant flow.

4) Lightning rail (small-balance commerce + partitioning)

Lightning node implementation
  • Primary: Core Lightning (CLN) for ops-friendly, plugin-native posture.
  • Alternate: LND (different ecosystem tradeoffs).
  • Rule alignment: LN is capped working capital (never reserve).
LN partitioning + scoped keys
  • LNbits as accounts system (unique API keys per wallet; blast-radius control).
  • Nostr Wallet Connect (NIP-47) as a capability interface for tightly scoped remote permissions (not reserve interface).

5) Accounting (local-first, auditable)

hledger (plaintext double-entry)
  • Maps to: privacy + auditability + version control + long-lived operability.
  • Accounting is used to model external claims and liabilities; it never drives custody decisions by itself.

Optimized minimal set (your forced-pick list)

  • Core chain + backend: Bitcoin Core + Fulcrum (or electrs).
  • Treasury workstation: Sparrow (daily) + Specter (multisig ops).
  • Signers: SeedSigner + BitBox02 + Passport.
  • Merchant: BTCPay Server (+ Payjoin where compatible); Pull Payments/Payouts for refunds + payroll; BTCPay→Sparrow PSBT for separation-of-duties.
  • Lightning: CLN + LNbits (+ optional NIP-47/NWC where scoped remote perms are required).
  • Accounting: hledger.

Swap safety Any candidate replacement tool must be evaluated on how well it preserves: descriptors, PSBT workflows, labels, and the registry/manifest discipline— not just UX.

Hard exclusions (do not map to the stack)

  • Any “Bitcoin IOU” instruments as reserve base (wrapped BTC, paper BTC, yield products).
  • Any merchant processor requiring custodial settlement as the default operating mode (breaks self-host invariant BTCPay satisfies).
  • Any wallet workflow that cannot do PSBT + explicit coin control/labeling (breaks UTXO-level accountability).

Red line These exclusions are not preferences; they are structural. Using them collapses the business back into counterparty money.