Merchant Sovereignty Blueprint

1. Scope

This Blueprint exists because the problem is not one terminal, one wallet, one device, or one vendor. The problem is the merchant stack itself: payment rails, reserve logic, service-ticket continuity, records, devices, authority, outage handling, and substitute-operator readiness need to fit together under one operating order.

2. Executive judgment

Proceed — but only as a phased merchant redesign under dual rails.

This business should move toward a more sovereign merchant stack. It should not attempt a total one-shot rebuild, and it should not confuse “accepting bitcoin” with having solved merchant dependence.

The correct first-order aim is not ideological purity. It is to preserve revenue, compress payment-rail tolls, separate reserve from daily checkout flow, make the shop legible to itself, keep the business operable under brief disruption, reduce founder-memory dependence, and improve recoverability without creating a new hidden admin class.

Final design judgment:

1. merchant legibility
2. records and authority spine
3. dual-rail acceptance redesign
4. reserve / float separation
5. operator hardening
6. only later, selective hosting and deeper dependency reduction

3. Merchant design objective

The target is not “a bitcoin-friendly bike shop.” The target is a merchant operating stack that is:

• dual-rail — incumbent demand preserved while cheaper and more controlled rails are added
• bounded — checkout, workshop, reserve, archive, and admin surfaces do not collapse into one another
• auditable — the merchant can tell what is owned, leased, delegated, or merely accessed
• recoverable — a dead terminal, absent owner, internet partition, or staff turnover does not erase shop memory
• operator-carryable — cashier, manager, and owner each carry bounded layers appropriate to their role
• anti-recapture — the business does not quietly slide back into hidden processor dependence, inbox sprawl, undocumented authority, or founder-only memory

For this merchant, that means composition across checkout and settlement, reserve and refund float, service tickets and parts records, invoices and archive, owner / manager / staff authority, operator authentication posture, outage fallback, supplier continuity, succession and substitute-operator readiness, and later, selective hosting and observability where justified.

4. Design laws

5. Target-state stack by function and layer

Layer A — Checkout and settlement

Target state: The shop runs a dual-rail checkout surface: cash and existing card rails remain available, a merchant-controlled bitcoin rail is added beside them, staff can process either path without improvisation, and daily closeout remains comprehensible even when two or more settlement paths exist.

Why this layer belongs: Retail rail cost is real, but customer behavior is also real. The merchant needs a lower-cost and more controlled rail without pretending customers will move all at once.

Dependency reduced: exclusive processor dependence, pure card-fee drag, inability to experiment with alternative settlement.

New burden introduced: cashier script, refund rule, reconciliation across more than one rail, merchant responsibility for a controlled acceptance flow.

Candidate aligned surfaces: BTCPay Server. BTC Map becomes relevant only after the flow is stable enough for public discovery. LNbits is not assumed; it is a bounded adjunct only if a later merchant workflow clearly requires it.

Refusal: No customer-facing “bitcoin accepted” promotion before staff can reliably process it.

Layer B — Reserve, operating cash, and refund float

Target state: The shop has three clearly distinct money layers: operating cash layer, refund and settlement float, and durable reserve layer.

Why this layer belongs: A merchant who merges checkout money, daily liquidity, and durable reserve creates avoidable fragility.

Dependency reduced: founder-intuition treasury management, accidental commingling, refund chaos, reserve exposure through the wrong device or wrong role.

New burden introduced: explicit treasury rules, owner / manager role separation, actual cash hierarchy.

Candidate aligned surfaces: Reserve coordination can later center on Sparrow with an appropriate signer class such as Passport, ColdCard, or SeedSigner, but exact selection belongs later. Small operational Lightning-facing use can later live on a bounded operator surface such as ZEUS, but never as a substitute for reserve custody.

Refusal: No reserve surface belongs on a cashier device, public terminal, or workshop tablet.

Layer C — Service-ticket and records spine

Target state: The business has one actual records spine for service tickets, deposits and pickups, supplier invoices, tax and bookkeeping exports, permits, insurance, lease, utility records, equipment manuals, incident notes, and continuity notes.

Why this layer belongs: This business sells labor, parts, trust, and memory. Lost ticket history, missing deposit notes, scattered supplier records, and inbox-only archives destroy continuity even if payments work.

Dependency reduced: founder memory, scattered inbox admin, paper scrap retrieval, platform-bound record access.

New burden introduced: document classification, archive intake discipline, restore testing.

Candidate aligned surfaces: Paperless-ngx, supported by disciplined sync and backup surfaces such as Syncthing and Restic. A collaboration layer such as Nextcloud is optional later, not assumed now.

Refusal: No “we can probably find it in email” archive model.

Layer D — Authority, roles, and operator posture

Target state: The merchant formally distinguishes four roles: Owner, Shop manager, Staff, and Outside specialist / later deployer.

Why this layer belongs: Most small business fragility hides in undocumented authority, not just bad tools.

Dependency reduced: founder-only control, invisible admin power, accidental staff overreach, inability to substitute under absence.

New burden introduced: explicit approval boundaries, written refund authority, named reconciliation owner, named continuity owner.

Candidate aligned surfaces: For operator-tier auth only, the direction is KeePassXC / KeePassDX and Aegis. Later, if hardware and burden justify it, owner and manager mobile posture may move toward GrapheneOS.

Refusal: No stack where all auth gravity collapses into the owner’s phone.

Layer E — Degraded-mode and outage continuity

Target state: The shop can continue in reduced but orderly form during internet interruption, terminal failure, brief power events, absent owner, customer rush under partial tech failure, and temporary processor or banking delay.

Why this layer belongs: A merchant stack is judged by what happens on a bad Tuesday, not during a calm demo.

Dependency reduced: perfect-connectivity assumption, owner-presence assumption, memory-based closeout, improv-only fallback.

New burden introduced: written fallback procedure, printed quick-reference materials, light continuity inventory, periodic drills.

Candidate aligned surfaces: This layer is mostly procedural, but later may include Uptime Kuma where hosted services become material, plus small backup-power and printed continuity materials.

Refusal: No merchant-critical flow that only works under perfect internet and perfect owner presence.

Layer F — Selective hosting and dependency reduction

Target state: Only selected services move onto a more controlled hosting surface, and only after the merchant proves it can carry them.

Why this layer belongs: Dependency reduction matters, but self-hosting is not first. The shop must first gain legibility, bounded roles, archive continuity, and rail discipline.

Dependency reduced: third-party hosting dependence for chosen services, platform fragility on selected internal surfaces.

New burden introduced: restore duty, patching awareness, service health discipline, substitute-operator requirements.

Candidate aligned surfaces: If later justified, the aligned small-business hosting direction is StartOS / Start9 with the smallest viable service footprint first.

Refusal: No merchant-critical self-hosting before restore, power, and substitute-operator conditions are demonstrated.

6. Sequence map

This is design order, not install order.

Phase 0 — Merchant legibility

• map current payment mix
• measure actual acceptance-cost burden
• name owner and manager as real separate roles
• name refund authority
• name reconciliation authority
• expose record disorder and ticket fragility
• determine what fails if the owner disappears for 48 hours

Phase 1 — Records and authority spine

• one records spine
• one role / approval map
• one refund rule
• one reconciliation rule
• one continuity binder
• one degraded-mode first-moves sheet

Phase 2 — Dual-rail acceptance redesign

• merchant-controlled bitcoin rail beside existing rails
• written cashier flow
• written refund handling
• written closeout logic
• gradual customer steering only after staff reliability is real

Phase 3 — Treasury separation

• operating cash boundary
• float / refund boundary
• reserve boundary
• owner / manager treasury responsibilities

Phase 4 — Operator hardening

• operator auth discipline hardens
• owner / manager device posture improves
• archive and backup discipline becomes routine
• substitute-operator logic becomes real

Phase 5 — Conditional hosting reduction

• selected services move to more controlled hosting
• service visibility improves
• restore is tested before any expansion

7. Role and ownership map

Owner

Owns: reserve policy, strategic approval, succession decisions, acceptance of stack burden.

Must not: remain the only recoverer of the business.

Shop manager

Owns: closeout and reconciliation continuity, records spine hygiene, day-to-day stack continuity, staff-facing fallback execution.

Must not: become silent hidden admin.

Staff

Own: bounded checkout actions, service-ticket intake, bounded front-of-house and workshop actions.

Must not: hold reserve secrets, alter merchant payment configuration, improvise refund policy, or touch archive or auth layers beyond their role.

Later outside specialist / deployer

Owns: one tightly bounded later technical step at a time.

Must not: retain standing access, receive seed phrases or private keys, or become the merchant’s invisible operator.

8. Gates and prerequisites

The redesign does not proceed cleanly unless these are true.

• Gate 1 — Dual-rail commitment: incumbent rails stay live while the replacement rail is built.
• Gate 2 — Cashier flow can be bounded: staff can learn one additional payment path without improvisation.
• Gate 3 — Refund owner is named: one person owns refund authority and method.
• Gate 4 — Reconciliation owner is named: one person owns end-of-day truth.
• Gate 5 — Owner and manager are both real operators: not equal, real.
• Gate 6 — Records spine is politically possible: the shop is willing to stop living in inbox fragments and paper sprawl.
• Gate 7 — Reserve and checkout are conceptually separated: the shop understands that acceptance is not custody.
• Gate 8 — If later hosting reduction is attempted, restore conditions are real: no critical self-hosting without restore path, backup discipline, power plan, and substitute-operator path.

If these gates are false, later execution should wait.

9. Maintenance model

Daily

• checkout sanity
• ticket continuity
• refund sanity
• anomaly awareness

Weekly

• document intake
• invoice and supplier organization
• auth hygiene review where needed
• continuity binder refresh if something changed

Monthly

• backup check
• acceptance-cost review
• reserve / float boundary review
• owner / manager substitution review

Quarterly

• degraded-mode drill
• archive retrieval test
• refund and closeout review
• hosted-service review, if any later hosted surface exists
• operator overload check

Failure plan

If owner absent: manager carries bounded continuity, checkout continues, reserve stays gated, refunds follow prewritten rule, archive remains usable, and anything beyond written fallback becomes later separate scope.

If manager lost: the business halts stack expansion, retrenches to the last safe carried state, and the owner resumes the simplest workable flow until a real second operator exists.

10. What this Blueprint explicitly refuses

• dropping cards in the name of ideological purity
• founder-only sovereignty
• customer-facing bitcoin branding before cashier competence
• reserve custody on checkout devices
• archive disorder deferred under “we’ll fix it later”
• self-hosting as status rather than burden-bearing capacity
• adding every aligned tool just because it exists

This is a merchant design, not a scene performance.

11. Decision standard

Proceed

• Phase 0 merchant legibility
• Phase 1 records and authority spine
• Phase 2 dual-rail redesign
• Phase 3 treasury separation

Wait

• deeper hosting sovereignty
• more complex custody architecture
• broader public discovery pushes
• any infrastructure layer current operators cannot restore

Do not proceed

• rail purity theater
• founder-only stack
• checkout / reserve commingling
• public acceptance flow before staff readiness
• self-hosting critical merchant surfaces before restore readiness

Without those refusals, the design collapses into theater.

12. Compressed summary

Formatted from the provided sample blueprint text. fileciteturn7file0