Older Gitea links were shared pointing at docs/<slug>.md; the content has
since moved to docs/rfcs/<slug>.md (the rfc-app 'docs' collection). Gitea has
no per-file HTTP redirect, so replace each old file with a short stub linking
to the new repo path and the rendered RFC-app URL, so previously-shared links
still land somewhere useful.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-15 19:03:32 -07:00
2 changed files with 12 additions and 1599 deletions
# Maker Platform — Strategy & Architecture has moved
A working memo distilling the thinking so far. It serves makers in general, but launches into one dense community first (the*beachhead*, §2/§5). The aim is to keep two doors open — a paid consultancy that's real today, and an option on a larger network play — without over-committing to the second before the evidence justifies it.
This document now lives at**[`docs/rfcs/maker-platform-strategy.md`](./rfcs/maker-platform-strategy.md)**.
> **Grounded in the Open Human Model.** Every principle in this memo — *trust, consent, reputation, harm, recourse, value, agency, dignity* — is meant to rest on the shared definitions in the [**Open Human Model (OHM)**](https://rfc.wiggleverse.org/p/ohm/c/default/), Wiggleverse's version-controlled dictionary for the words that systems acting on behalf of humans turn on. Where this memo and an OHM RFC disagree, **the RFC is canonical**; where a load-bearing concept here isn't yet defined in OHM, defining it is itself OHM work (not license to coin a local meaning). The reputation/trust model below is the first place this bites — see §10.
_This stub is kept only so older links to `docs/maker-platform-strategy.md` still
resolve — please update bookmarks to one of the locations above._
## 1. The lens: stock moats vs. flow moats
The organizing idea behind everything below.
- **Stock moat** = accumulated build, features, or content — a one-time lead. As production cost collapses (cloud did this to infrastructure; LLMs are now doing it to software production), stock moats trend toward zero, and any *new* stock advantage is matched in weeks.
- **Flow moat** = data, network, switching cost, regulation, embedded workflow. It compounds with every customer and every day of use, and cheap production can't shortcut its accumulation.
The diagnostic for any product: *if a competent small team could reproduce the functionality in a week with LLM assistance, what does the customer still pay for?* Whatever survives is the real moat; if nothing survives, build-cost was the whole moat — the exposed position.
Cheap production lowers cost **symmetrically** — for every entrant at once — so it never picks winners. It commoditizes the build layer and pushes competition *up* to the moats it can't erode. Don't pick a fight where build-cost was going to be your only moat.
---
## 2. The thesis
Build for **independent makers** — positioned as "the curated maker marketplace before resellers polluted it," but executed so the durable value is flow, not stock.
**The core primitive: commitment commerce.** The entire "gnarly 20%" that generic tools serve badly is one mechanism wearing many costumes. Pre-order, raffle, drop, monthly club, made-to-order commission, deposit-and-waitlist — every one is *collect committed demand before production, then make against it.* That's the inverse of Shopify's *stock-then-sell* (make it, shelve it, someone buys it), which is exactly why Shopify and generic tools serve makers badly: **many** makers run on *commit-then-make*. The category you're building is **commitment commerce**, not storefront commerce — the drop/pre-order/club/commission cadence is the engine, and the storefront is just its surface. (The platform still handles ordinary *stock-then-sell* too — it is a full storefront — so a maker can run their whole catalog on it; the positioning is *commit-then-make, not **just** stock-then-sell* — both modes, with commit-then-make the differentiator and the gnarly part nobody else serves, never the platform's only mode.)
Two halves, treated differently:
- **Commitment-commerce engine (the real product).** The maker-native cadence layer Shopify lacks: scheduled drops, pre-orders and deposits, raffle/queue allocation, made-to-order workflows, recurring clubs/memberships, digital-file delivery + licensing where relevant, and variant/bundle handling. This *is* the gnarly 20% and the reason vertical infrastructure here is defensible — emphatically *not* "the same as Shopify." The defensibility isn't that the cadence is *hard* to build — it's that **no continuous (non-campaign) platform treats it as a first-class citizen**, so the table-stakes go uncovered everywhere outside the Kickstarter-likes (Appendix B); being its first-class home is also the on-ramp to integrating emerging generative/LLM maker tools (e.g. **cuttle.xyz**) that campaign platforms and stock storefronts have no reason to touch. (The white-label storefront is the commodity surface, subsumed here: build the least of it you can, rent the rest.)
- **Cross-maker demand network (the moat).** The flow asset, accruing as a *byproduct* of the engine. Every drop/pre-order captures a buyer who *follows* a maker and commits early; a base of drop-followers across many makers is the embryonic cross-merchant identity network — the niche-scoped Shop Pay equivalent. Stock commerce gives you people who bought once; commitment commerce gives you people who *wait for* makers and commit ahead — a far stronger flow asset. Reputation-staked cross-maker curation turns that into *earned* demand, not just relocated demand.
The reframe: commitment commerce is not a feature of the storefront — it *is* the platform, and the mechanism that builds the flow moat, rather than something engineered separately alongside it.
**The beachhead principle.** "Makers in general" is the eventual market, but a network cold-start needs *density* — so launch in one craft community tight enough that word-of-mouth substitutes for a marketing budget, and where you show up as a *member, not a vendor*. Expand to adjacent communities only after the first compounds. The vertical-selection method and a worked candidate (miniatures → dice → broad tabletop) are in Appendix A.
**Business model (detail in §7):** the **network is the product and the value capture** (referral take + network subscription, charged identically whether a maker is on your storefront or Shopify); the **storefront is an optional, SaaS-priced convenience — never GMV-fee'd, never sold as hosting.** You are a *vertical commitment-commerce product*, not a hosting company; a partner/consultant network onboards the high-touch tail.
**Why now — the Wiggleverse thesis, applied to maker commerce.** The timing argument here isn't particular to makers; it is the org-level [Wiggleverse thesis](https://wiggleverse.org/about/) — *"the era of infinite alternatives"* — specialized to one vertical. Every era commoditizes something: the internet commoditized knowledge, the cloud commoditized IT infrastructure and then small SaaS, and **LLMs are now commoditizing the platforms themselves.** As they do, the three moats incumbents were built on each turn into *anchors* — and that is precisely the opening:
- **Build-cost / scale → anchor.** The manpower and capital to run software at platform scale was the first moat; LLMs deflate it (the §1 stock-moat lens), which is exactly what makes a volunteer/non-profit build viable here (§7, §12) — the entity and the opportunity are the same bet. (Headless commerce maturing — *build the 20%, rent the 80%*, §6 — is the same force at the storefront layer.)
- **Vendor lock-in → dissolving.** Commoditized custom software makes migrating off a platform cheap and fast; you no longer wait for a vendor's export tools. The memo's federation, data portability, and ESP-as-source-of-truth (§7) ride this directly.
- **Network effect → fragmenting — and this is the one that matters most here.** The memo's *own* moat is a network (§2), so the obvious objection is that incumbents' network effects make them unassailable — the §4 graveyard. The Wiggleverse answer: incumbents got **greedy and extractive and eroded their own network stickiness**, so a values-aligned alternative can now contest a network moat that used to be untouchable. (No contradiction with §1, where flow moats compound: a flow moat compounds only while it is *stewarded* — the incumbents spent theirs.) Etsy's authenticity reckoning *is* that erosion made concrete — its active-seller base fell from ~9M to ~5.6M as it purged for quality (§12 sizing) while AI-generated and recast fakes flood the marketplaces, so verified provenance is at once scarcer, more valuable, and surrounded by freshly-disaffected, recruitable supply (§3).
Two maker-commerce-specific accelerants sit on top of the org thesis: **AI shopping agents are standing up** and need structured, trustworthy, real-time supply they cannot scrape — the narrow window to be the verified maker-supply rails agents route through opens now (§3, §7); and the same **non-extraction ethic** the org is built on (give value, don't extract — an OHM principle) is precisely what the out-of-the-money-flow, never-GMV-fee, usage-rights-ownership stance (§7) *is*, in maker-commerce form. Miss the window and the provenance grievance normalizes, the agent rails get built by someone *in* the flow, and the build-cost advantage commoditizes for everyone at once (§1).
**Why this product is the Wiggleverse's beachhead.** Two nested beachheads are in play and shouldn't be confused: within *this* product, the launch *community* is miniatures (§5, Appendix A); but the product *itself* is the **beachhead for the whole [Wiggleverse](https://wiggleverse.org/) portfolio** — its first product, the proving ground for the org-level mission of ethical, non-extractive alternatives to extractive platforms. It earns that role on four counts:
- **The fastest honest path to standing on its own feet.** Running a non-profit and the infrastructure under a platform takes money; commerce is where money moves most, so building close to commerce is the quickest route to a sustainable economic position ([Wiggleverse — why ecomm first](https://wiggleverse.org/ecomm/)). A self-sustaining beachhead is also what funds the rest of the portfolio (the *apps* and *learn* products to come) — the §12 economics read at org scale.
- **The hardest, most complete test of the thesis.** This product exercises *every* load-bearing Wiggleverse bet at once: **non-extraction** (the out-of-flow, never-GMV-fee stance, §7/§11, *is* the org's "take only what it takes to run"), the **flow/network moat** against eroding incumbents (the §2/§4 thesis and the three moats above), **OHM ethics made concrete** (consent, agency, dignity, value, recourse show up as verification, provenance, and usage-rights — §7/§10/§11), and the **open-core partner ecosystem** (§7 partner network). Prove it here and the rest of the portfolio is de-risked.
- **The most tangible "give value, not extract" demonstration.** Commerce makes the ethic legible in dollars — *our fee + your processor ≈ 4–7% vs Etsy's ~20%* (§7) — so the mission is a number on every sale, not a slogan ("what is enough? — enough to keep the lights on, and no more").
- **"Small businesses are really just people."** Serving independent makers directly *is* the OHM mission — *treat humans as humans* — applied to the place commerce had most thoroughly turned them into accounts and line items.
---
## 3. Positioning: what's yours vs. what's commodity
The cross-merchant inclusion mechanism already exists and is commoditized — Shopify Collective, Carro, and Shopify's Product Network all let merchants sell each other's products. Feasibility is de-risked, but it means **you cannot win on the plumbing.** If the product is "Collective for makers," Shopify extends Collective and you're gone.
Your differentiation is the layer the commission-optimized networks structurally can't have:
- **Verified provenance.** "Actually handmade/made by this person" is the trust signal buyers and AI agents can't get elsewhere, and it *appreciates* as AI-generated and drop-shipped fakes proliferate (Etsy is being flooded now). This is flow; the aggregation tech is stock.
- **Reputation-staked curation, not pay-for-placement.** The central danger: commission-driven inclusion drifts curation from "what's genuinely good" to "what converts and pays," rebuilding Etsy's pollution from inside, laundered through trusted faces. Inclusion must be an editorial/social act with the curating maker's standing on the line.
- **Community standing.** The demand problem is a community problem, and community is founded, not acquired.
Longer term, the verified-supply graph becomes **agent-ready rails** — the trustworthy, structured, real-time-inventory supply layer AI shopping agents need and can't manufacture by scraping. That repositions the moat from "win consumer eyeballs" (unwinnable for a newcomer) to "be the verified maker-supply layer agents route through."
---
## 4. Honest risks and hard truths
- **The graveyard is real.** Goimagine, Artisans Cooperative, Folksy, Storenvy, Amazon Handmade — "Etsy but actually handmade" has been built many times and stays small. The reason: **curation fights liquidity**, and curation is a *seller-side* value proposition. These platforms recruit angry makers (supply) and die for lack of buyers (demand). Etsy's drift into mass-produced goods wasn't betrayal — it was the gravity of GMV growth.
- **No demand advantage yet — the binding constraint.** Demand at marketplace scale must be *earned*, not bought; paid acquisition against Etsy, Amazon, and agents is the losing game the graveyard played. Early on the network *pools existing maker audiences* (reshuffle), it doesn't create net-new buyers — the correct cold-start move, but don't mistake it for solving acquisition.
- **Buyer-ownership tension.** Some makers guard their customer lists and will resist shared cross-merchant identity. If they want the cross-promotion demand but not the shared identity, the network's conversion advantage is capped. Surface early (and see the opt-in design in §7).
- **n = 2 is learning, not validation.** The engineer's trap is over-abstracting for two clients when the right abstraction only reveals itself around ten.
- **Commitment commerce carries financial/delivery liability.** Taking money before delivery inherits structural delivery risk — chargebacks, non-delivery, makers who collect pre-orders and don't ship. This is *why* the 20% is gnarly (financial risk, not just UX). The design answer (§7): stay out of the money flow so the maker, as merchant of record, carries it.
- **Raffle/lottery legality.** The raffle drop mechanic can be regulated as a lottery/gambling depending on jurisdiction — the one primitive with real compliance exposure. Understand it *before* building it as a headline feature.
- **Campaign vs. cadence is a product fork — pick cadence.** Episodic, project-scale crowdfunding is owned by entrenched incumbents (Kickstarter, Gamefound, BackerKit — Appendix B). The unserved gap is the *continuous* drop cadence (the biweekly drop, the monthly club). Don't drift into competing with Gamefound; own the continuous-relationship layer they don't serve. (One continuous-cadence slice *does* have an incumbent — the monthly club, owned by **Patreon**; the next bullet faces it.)
- **Your beachhead lives on a walled garden you're recruiting them off of.** In miniatures, the de-facto club infrastructure is **Patreon** — the *membership-side* walled garden (Appendix D) and the commitment-commerce incumbent for the recurring-club primitive (Appendix B). It is a *sharper* competitor than Shopify for that slice — a club is already commit-then-make, not Shopify's stock-then-sell — and unavoidable, because your first community is already on it. The posture it forces — **recruit-out + replace-the-club (native, out-of-flow, maker-MoR) + lift-the-patron-list** — is therefore materially more load-bearing than the memo's posture toward Etsy, which is otherwise the lead walled-garden example.
- **Volunteer-core sustainability is the single point of failure** (given the non-profit/volunteer model, §7). LLMs make a smaller core go further but don't fix volunteer attrition or bus-factor. The parts touching money, catalog data, and verification need *reliability*, not best-effort — so the critical core (network service, ledger, verification) must not be bus-factor-one. The historical killer of volunteer orgs is *sustaining*, not building; transfer the rigor you'd spend on fundraising onto this.
---
## 5. Sequencing: earn into the marketplace, don't launch one
Four acts, each viable on its own, each earning the right to the next. No stage depends on demand you can't yet generate.
1.**Tool.** The verified-maker commitment-commerce engine with a white-label storefront as its surface — genuinely the best home for a real maker. Useful at zero liquidity. Accrues supply, a structured provenance-stamped catalog, *and* a base of drop-followers. *A real business even if the network never lights.*
2.**Community.** Narrow to one craft scene tight enough that word-of-mouth substitutes for a marketing budget (the beachhead). Add cross-maker discovery with an editorial point of view — the demand-generating feature you build rather than buy.
3.**Marketplace.** Light the curated cross-inclusion network once supply density and community exist — it *emerges* from accumulated follows (§7), rather than launching cold into the graveyard.
4.**Infrastructure.** Expose the verified-supply graph to agents; become the rails.
**Selection criterion that decides everything:** pick the community where you show up as a *member, not a vendor* — where you already have, or can authentically build, real standing.
---
## 6. The immediate engagement (the first makers)
A good investment **if** you build the right common infra. The wasted version is a generic storefront engine ("the same as Shopify") — the stock layer, valueless in every branch.
The reusable assets worth owning, none of which is a storefront builder:
1.**A clean, portable, verified catalog data model that you own.** Cheap to do well now, expensive to retrofit later.
2.**The commitment-commerce primitives (the engine)** — scheduled drops, pre-orders/deposits, raffle/queue allocation, recurring clubs/memberships, made-to-order workflows, digital delivery + licensing, variant/bundle handling. The portable, vertical-spanning core; the storefront is just its surface.
3.**Standing in the beachhead community** and the first reference relationships.
**Operating rule: build the maker-shaped 20%; rent the 80%.** Use a template, headless setup, or even Shopify itself for the commodity storefront parts. Let this be paid consultancy whose real return is knowledge, references, and a portable data asset — a cheap option on the bigger play.
---
## 7. Architecture
The money-flow stance and the first network feature turn out to be the same decision viewed twice; the rest of the section builds out from there.
### Money flow: stay out of it (the "no")
The white-label model enforces this: each storefront is the maker's brand on the maker's own payment processor, so **the maker is merchant of record by construction.** The money never touches you — you sell software, they run commerce. This is *cleaner than Kickstarter*, which is itself in the money flow (processes pledges, takes a cut, pays out) and only disclaims *delivery* liability; here you avoid both the flow and the delivery liability structurally.
**Why staying out is right:** no money-transmitter/escrow licensing (holding customer funds triggers state-by-state MTL in the US); no chargeback exposure (it hits the maker's processor, not you); no delivery-risk balance-sheet exposure; clean SaaS margins and a faster launch; and it's maker-aligned (their brand, processor, payouts, customer, data). The cost is forgoing payment take-rate — but that's exactly the slice that carries the risk you're declining, a fair, deliberate trade. The cross-maker identity moat doesn't need checkout anyway: **the asset lives at the *follow*** ("who follows which makers and commits early"), captured at the account / "notify me" / club layer you own regardless of whose processor runs the charge.
If you ever want transaction economics without the MTL burden, **Stripe Connect** is the middle path — but it is a *dial, not a single choice*, and only one setting preserves the stance above. Two independent knobs decide who is merchant of record and who eats the risk:
- **Charge type.** *Direct charges* keep the **maker** as MoR — disputes and chargebacks hit the maker's balance, the maker pays the processing fees. *Destination charges* and *separate-charges-and-transfers* make the **platform** MoR — your balance is auto-debited for disputes, and you are now indirectly collecting and transmitting the buyer's payment, i.e. a **marketplace facilitator** for sales-tax purposes (§11).
- **Account type.** *Standard* accounts leave negative-balance and dispute liability with the maker. *Express/Custom* push it onto the **platform**, with Stripe holding reserves against *you* for connected-account shortfalls.
The stance holds **only at Standard accounts + direct charges + `application_fee`**: the maker stays MoR, disputes stay on the maker's balance, you skim a fee without entering the flow. The trap is that Stripe's own marketplace tutorials default to *destination* charges (the canonical "marketplace" pattern), which silently flips every one of those properties — the payments-layer cousin of the "buy through their store" creep this memo warns about elsewhere. So **the Connect configuration is a legal-posture constraint, not an implementation detail.** The default money model remains the out-of-flow ACH/invoice fee below; Connect is reserved for the deliberate later crossings (cashable wallets, kit/taste-maker payouts), and even there uses the arm's-length setting. *(Verify per account type and per state with a payments/SALT attorney before architecting. Not legal advice.)*
### Unified phasing
One phasing governs the whole build; everything below references these stages.
- **Phase 1 — tool + stateless referrals (out of money flow).** White-label storefront on the maker's own processor; Curated-By via stateless signed tokens; non-cashable fee-offset wallet. No shared identity, no consent complexity, no money movement. A real consultancy/tool business on its own.
- **Phase 2 — shared identity + the cashable-payout rail.** Shared auth + follow relationships + the consent-gated cross-maker graph (the durable network effects: follows, cross-session credit, niche-scoped recognition/conversion lift). Phase 2 also lands **one** cashable payout rail (Connect / mass-pay) that simultaneously unlocks cashable maker wallets, kit pure-supplier payouts (Appendix C), and the verified taste-maker tier — three consumers of a single scoped crossing. Optional Connect `application_fee` for transaction economics here too.
- **Phase 2+ — buyer-facing feed.** The consumer surface where the marketplace *emerges* from accumulated follows (below).
- **Phase 3 (much later, optional, opt-in) — shared checkout.** The only point the money-flow question returns — chosen by makers because it converts better, never forced.
### "Curated By This Maker" — the first network feature
Each maker's storefront carries a **"Curated By This Maker"** section featuring other *verified* makers' products they genuinely admire. It's the demand network as a concrete, shippable surface — and it works at **n = 2**, the holy grail for a network feature.
**What this is — and the name matters: a verified merchant referral network, *not* retail media.** The two look similar (a curated set of products with outbound links and attribution) but encode *opposite governance*: retail media is **paid placement** (highest payer wins the slot), while a verified merchant referral network is **reputation-staked vouching** (placement is earned; the curating maker's standing is on the line). The name is a structural guardrail — a thing called a *verified merchant referral network* can't quietly start selling slots without becoming a self-evident lie. Never frame or price it as retail media; that framing's gravity is toward selling placement, rebuilding Etsy's pollution through trusted faces.
**Targets are verified makers on controllable storefronts ONLY — never walled-garden listings.** The network never points its curation, buyer feed, or agent feed *outward* at an Etsy/Amazon/eBay listing. This is a **value-system rule, not a technical limit**: every such link would lend the community's trust and a maker's audience to the captive-commerce model this enterprise is an alternative to. A walled-garden-only maker is an **invitation target, not a curation/destination target** — "I'd feature your work the moment you own your commerce" is the pitch, and the *absence* of a link is the recruiting signal. (It also sharpens the moat: when every target is a verified controllable-storefront member, the "sincere vouch vs. paid slot" gray zone disappears.) Full participation matrix in Appendix D.
**The fork — what "buy" means:**
- **(A) Referral / handoff — build this.** Checkout hands off to maker B's own store and processor. A vouches, B fulfills and is paid, A optionally earns a referral credit. Money stays siloed; A is never merchant of record for B's goods. Out of the money flow.
- **(B) Consignment / resale — avoid.** The buyer checks out on A's store for B's product; A becomes MoR for B's goods and owes B a payout — recreating the delivery-and-payout liability you designed out (mechanically what Shopify Collective is, and why it needs Shopify Payments in the middle).
Model A is reputation-staked human curation (the anti-pollution, can't-be-gamed kind that *is* the moat), it rides each maker's existing traffic, and it's structurally aligned (A only features B if A rates B's work). Watch the phrase **"buy through their store"** in any spec — it's where (B) creeps back via a unified-cart "convenience" that drags you to merchant-of-record. Hold the line at handoff until a shared *opt-in* checkout is a deliberate Phase-3 decision.
**Guardrails:**
- **Attribution is stateless — no identity layer required.** A signed referral token (origin maker + item + expiry + nonce) rides the A→B handoff into B's order; you read it to bill B and credit A. It tracks the *referral path*, not the buyer, so it works in Phase 1 for guests and sovereign makers. Persistent identity is only for the *durable* effects (follows, cross-session credit).
- **Commission-corruption trap.** When Curated-By pays well, curation drifts to "feature whoever converts/pays most." Keep it reputation-staked: **B must approve being curated by A** (per-relationship opt-in — placement is consented on both sides, distinct from the default-on *catalog presence* switch below), cap how much any maker can feature, make it visibly personal (name + face), prefer "A owns/uses this," and never sell slots. The sincere vouch is the whole value.
- **Ranking neutrality — structural, not a promise.** Among the items a maker curates, the *platform* chooses which to surface to a given buyer, and it **will** use algorithms (personalization, popularity) to lift conversions — that's the platform's job. The guarantee is that **referral economics are never an input to that ranking**, and it holds *by construction*: the platform's spread is the **same percentage no matter which referred item sells** ("Referral economics" below), so the platform has no incentive to favor a higher-paying referral. Structural indifference is a *stronger* guarantee than a flat uniform rate — it survives makers negotiating their own rewards.
- **Complementary, not substitute.** Nudge toward complementary makers (a maker surfaces an adjacent craft, not a direct rival) — complementary curation is generative; substitute curation is cannibalistic and makers won't do it.
### How the platform gets paid
Out of the money flow, your fee is a **platform fee billed in arrears via ACH/invoice**, explicitly separate from processing (the comparable is Checkout Page: $29/mo, 0% on top of the maker's own Stripe).
- **Tiered "graduate" pricing.** Starter: $0/low monthly + a modest **percentage** (≈2–4%) on captured orders (cold-start-friendly). Pro: flat **$29–49/mo + 0%** (predictable, easy to collect, at scale). Auto-graduate by GMV so makers don't overpay. Use a **percentage, not a per-order flat fee**, on low-AOV makers (a flat $0.50 over-taxes a $12 item).
- **Charge on captured/fulfilled orders, not pledges** — don't bill money that never cleared.
- **Market the all-in transparently:** "our fee + your own processor ≈ X% vs Etsy's ~20%." Not bundling processing is the wedge — say it in numbers. Illustratively (shape, not validated rates): a Starter maker at ~$1,200/mo runs ~2–4% platform + ~3% processor ≈ **5–7%** all-in; a Pro maker at ~$6,000/mo runs $39/mo + ~3% processor ≈ **~3.6%** all-in — versus Etsy's ~20% either way, i.e. the maker keeps roughly **13–16 percentage points more of every sale.**
**Referral economics.** On a referred order, two layers stack. **The platform's spread is fixed and never negotiated** — ≈3–5% of the order (it may scale with the sale and carry a $ cap), the network's one piece of referral revenue, and *the same percentage regardless of which referred item sells* — which is what makes the ranking-neutrality guarantee structural rather than a promise ("Curated By This Maker" above). **Maker A's reward sits above the spread and is the makers' to set:** A and B negotiate it through platform tooling — a flat %, a tiered rate ("x% over $y"), a max-$ cap — and may **renegotiate** as the relationship evolves, with one floor, the spread. So B always pays *at least* the spread; set A's reward to zero and no referral money changes hands while the platform still earns its spread. (This negotiability is **scoped to maker↔maker** referrals; the pure non-maker taste-maker tier keeps **uniform, non-biddable** rates — it lacks the peer-respect counterweight — see "Non-maker referrers" below.) Keep the legs as **two separate events** — B→Platform (a fee on B's invoice) and Platform→A (a credit you extend) — so you're **principal on both sides, never a conduit** moving money B→A. That independence keeps it out of money-transmission territory, and holds *only* while A's credit is non-cashable.
- The referred order's total **subsumes** the standard fee (one clean "this is the referred rate"), rather than stacking toward Etsy-like ~19%.
- **The fixed spread is the network's referral revenue line** (≈3–5%, $-capped) — not negotiable, and the *same percentage whatever is referred*; A's negotiated reward is the layer on top, non-cashable (below). One of the few places the network itself generates revenue.
- **Non-cashable fee-offset wallet.** A's credit draws down *future platform fees first* — driving the curation flywheel ("curate → wipe out your fees"), lowering collection risk, and cleaner on tax (a fee discount, not income). **Cashing out re-opens the money-flow door** (rent BaaS — Connect/Treasury/Dwolla); a deliberate Phase-2 crossing, not a toggle.
- **Pending → cleared settlement.** Credit A as *pending* (not spendable) and hold B's fee pending; settle **both legs together** after B's refund window (≈14–30 days) closes, so in-window refunds void both atomically with zero clawback. Negative balances are a debit on a continuing account: reverse pending, then available, then push any shortfall to the next ACH invoice; keep the ACH mandate active through offboarding; a rolling reserve only if a few high-volume curators make it material.
### Identity, sovereignty & the opt-in network
**Separate authentication (infrastructure) from identity ownership (policy).** Run **one shared platform auth** under every white-label store; express sovereignty as a *data-visibility policy* on top — never by splitting auth per store.
- **Sovereign maker:** full accounts/logins (on your shared auth), customer data private to them, zero network exposure. Sovereignty means *your buyers are private to you* — **not** "run your own login" and **not** guest-only (guest-only is *less* ownership, not more).
- **Collective maker:** opted-in buyers participate in the cross-maker graph.
- **Centralize auth always** — it's commodity infrastructure *and* the network's foundation. If auth fragments per store, even opted-in makers have no shared substrate to network across. The maker's choice is a flag on one system, flippable later without re-platforming.
- **Two consent layers:** the *maker* decides whether their store participates; the *buyer* decides whether they're recognized across the network (GDPR/CCPA). Build both from the start.
**What "own the customer" means — usage-rights is the headline** (validated, §8). Makers mean **usage rights**: the buyer relationship is *theirs to market to, on any channel, including off the network*. This is the precise inversion of the walled-garden restriction (Etsy/Amazon forbid direct off-platform marketing because the captive buyer is *their* asset), so it's the sharpest anti-walled-garden promise — **and you can grant it unconditionally**, because you don't monetize the captive relationship. It also *subsumes portability*. So: **usage-rights ownership is the headline; network-graph *privacy* (buyers hidden from the cross-maker graph) is a separate, optional opt-out** for the fortress-minded subset — not the core meaning. Operational machinery in the consent subsection below.
**Opt-in network model — carrot, not stick.** It self-selects the commons-minded makers the network works for. The benefit must be **concentrated and visibly fast** or opt-in becomes a ghost town. Keep the asymmetry **additive** (joiners get referral income, placement, cross-promotion, fee offset, feed surfacing) — never **punitive** (don't cripple the standalone storefront to force joining). Design for **granular** participation, **reciprocity** (surfacing proportional to participation), and a **social-proof opt-in moment** ("makers you respect sent each other 200 buyers last month — want in?").
**Don't bundle "on our storefront ⇒ on the network."** Forcing full network participation on storefront makers is the coercion the opt-in model rules out, and it weakens the storefront's standalone (n=1) value. Split two switches: **catalog presence** (your products *can* be discovered/curated/fed) is reasonable to **default-on (opt-out)** for storefront makers (low-friction, low-sensitivity) — though being *featured in a specific maker's Curated-By* (a vouch carrying referral economics) is a **per-relationship opt-in** the featured maker approves (§7, "Curated By This Maker"); **buyer-identity participation** (your *buyers* are recognized cross-maker) stays a **separate, consent-gated opt-in** (sovereignty-sensitive, and it's the buyer's data). Take the convenience (auto-catalog-sync); never the coercion (forced identity sharing).
**Why this is the defensible core.** Shopify *won't* build cross-merchant shared identity — its customers (sovereignty-seeking DTC merchants) would experience it as the platform claiming their buyers, betraying the exact promise Shopify sells. Shopify does the *resell* network (share *products*) but not the *referral* network (share *buyers* with attribution). Your bet: community-embedded makers relate to shared identity as *belonging*, not theft. The moat isn't the storefront, the commitment-commerce mechanics, or the resell network (Shopify has that) — it's the **cross-maker identity-and-attribution layer**, the one asset an island-based incumbent is fenced out of by its own positioning.
### Customer ownership, consent & martech
"Own the customer" creates an obligation: consent has to be managed somewhere, and *where the source of truth lives* decides whether the promise is real or a disguised lock-in. The governing test: **if this maker left tomorrow, could they fully and lawfully market to their consented customers without ever touching the network again?**
**Source of truth: the maker's own ESP — not the network.** For a maker's *own* marketing, the maker's ESP (Mailchimp, Klaviyo, …) is authoritative and the network is a thin integration layer. This is *more* sovereign and *simpler* than a network ledger, passes the leave-tomorrow test tautologically, and dissolves the orphaned-opt-out-link problem: the unsubscribe link resolves to the ESP's native hosted unsubscribe, which the maker keeps after departure.
- The network captures email + per-type marketing consent at checkout and **pushes the subscriber to the maker's ESP**; the ESP owns everything after (compliant unsubscribe, suppression, deliverability).
- Opt-outs happen in the ESP; the network **reflects them via the ESP's unsubscribe *webhooks*** (prefer webhooks to polling). The network is a connector, never an ESP.
- **Imported pre-existing lists** then need no special handling — they live in the maker's ESP, naturally arm's-length from the network's records.
**Two consent domains — only one belongs in the ESP.***Maker-originating* marketing → the maker's ESP is authoritative. *Network-originating* communications (buyer feed, aggregate marketing emails below, follow notifications) are the network's own relationship with the buyer, governed by **network-communication consent** the network must own. Keep them strictly separate: **the network may never borrow a maker's ESP list for its own sends.** "Send A's curation to A's buyers" means *A's buyers who also opted into network email* — the overlap, never A's whole ESP list.
**The cross-maker buyer dashboard is a thin cache + fan-out, not a ledger.** With consent scattered across N ESPs, the unified dashboard ("manage all my subscriptions," "opt out of all promotional across all makers") needs a **read cache** (webhook-synced reflection — explicitly *not* the source of truth) and **fan-out writes** into each maker's ESP. Per-*maker* full unsubscribe is easy everywhere; **per-*type* across makers is the fiddly part** (each ESP models promotional-vs-drop differently — groups/tags/interests/lists — so your normalized type taxonomy must map onto each). Every dashboard control writes per-maker (per-type) records; a buyer-level standing preference ("never promotional from anyone") acts as a *default that generates per-maker records as new consents form*, not a send-time global override.
**Greenfield fork: no ESP → network light-sending is the temporary source of truth.** Greenfield makers (the two interviewed) have no ESP, so the network provides **optional light first-party sending**, where it *is* authoritative because no ESP exists. Keep it deliberately minimal (never a Klaviyo competitor) and **exportable to seed a real ESP later**. The graduation path is the right shape: greenfield → grows → adopts an ESP → the network steps *back* from authority to integration. Network involvement *shrinks* as the maker matures.
### The network marketing channel (aggregate emails & email-embedded curation)
Distinct from maker-originating ESP email, the network runs its **own** marketing channel — a discovery engine, provided it obeys the feed discipline.
- **Personalized aggregate emails.** The network emails buyers (on the **network's** consent list) digests aggregating content/deals from *multiple* makers. The hard rule that keeps this from becoming retail-media-by-email: **content traces to the buyer's own engagement graph** — drops/deals from makers they follow, plus those makers' Curated-By picks — and the network *aggregates, personalizes, and delivers* (pipe) but **never injects platform-chosen merchants or sells placement.** Maker-as-discovery-engine, platform-as-pipe.
- **Two-sided opt-out, both network-owned:** buyers opt out of receiving network marketing; makers opt out of being *included* in it.
- **Curation as living discovery.** A buyer who engaged with Maker A can receive A's *current* Curated-By picks in their network digest, and as A's curation evolves the fresh picks flow into emails to A's (network-consented) buyers — turning Curated-By into a *recurring* discovery surface for the makers A vouches for, through the channel the network legitimately owns.
- **Curated-By as an email widget in the maker's own ESP.** Makers embed their live Curated-By block in their own newsletters, with links carrying the stateless referral token — so a maker's own newsletter becomes a referral-generating surface (they earn credit; attribution works without identity). Points only to verified makers on controllable storefronts; reputation-staked, not paid; and — since email can't run JS — the widget is a send-time-pulled HTML block or a server-rendered image (refreshed per send).
### Verification: the gate to the trust tier
Verification sits at the boundary between the commodity layer and the moat layer. Three states, not two:
- **Unverified → full SaaS, zero network.** Any maker gets the complete commitment-commerce storefront (drops, pre-orders, clubs, own processor) — a paying customer of a genuinely good tool, but in *nothing* trust-gated (no referrals, no Curated-By either direction, no buyer feed, no agent feed). The storefront is commodity; gating it would suppress the Phase-1 wedge. Let everyone in the front door — *once the membership gate has loosened to open signup* (the phasing note below; at launch the door itself is invitation-only).
- **Verified → eligible** for referrals, Curated-By, buyer feed, and agent feed — eligibility, not automatic inclusion.
- **One gate, then independent switches.** Verification is the single floor; the channel opt-ins (network, agent) are independent choices within it.
**Curated-By and referrals are verified-only in *both* directions** — a verified maker's stake can't vouch for unverified supply, so an unverified maker can be neither curator nor target. (A useful forcing function toward verifying.)
**Network opt-in and agent (ACP) opt-in are independent siblings over one shared verified catalog — don't gate agents behind network membership.** A sovereign maker may refuse the maker-to-maker network yet *want* agent reach (net-new, sovereignty-neutral demand). **Verification — not network membership — is the precondition for the agent feed**, so the agent feed inherits the differentiator automatically ("*verified* products for agents," the structured trustworthy supply agents can't scrape). **Default agent inclusion ON (opt-out) for verified makers**: it maximizes the supply density that is your leverage with agents, and it's safe because agent sales route back through the maker as MoR. The agent feed is the **net-new-demand hedge** against the buyer feed's deliberate reach-weakness — the feed *deepens* existing follow graphs, agents *reach* outside them.
**Verification is aspirational, not punitive — by design.** Because it gates the *demand* (referrals, feed, agents), not the *tool*, makers are pulled toward verifying rather than blocked at signup, and the unverified SaaS tier becomes a **verification funnel** (already paying, catalog in-system, upgrade = "verify → unlock demand"). It also keeps the trust guarantee **absolute**: both consumer-facing surfaces are hard-gated, so anything a buyer or agent sees is verified.
**The membership gate itself phases — start closed, loosen toward open.** The three states above and the "front door / funnel" framing describe the **loosened end-state**. At **launch the gate is invitation-only, end to end**: there is no self-signup even for the unverified tool — every maker enters by invitation from an existing member who vouches they make original art or craft, rooted in a seed set Wiggleverse staff verify directly (the *originating edge*; full mechanics in the trust-&-safety section). Early scarcity is a feature: it lets word-of-mouth carry the beachhead, keeps the trust guarantee absolute while the rooted web is small, and makes every early edge high-intentionality. **Loosen toward open signup once roots and beachhead density exist** — then the unverified-tool front door opens, verification still gates the demand, and the funnel above kicks in at scale. This is the membership-gate analog of the peer-verification sequencing below (verify-makers-yourself-early → peer-verify-once-roots-exist): both start closed and open only as the trust web earns it.
**Peer verification — the scaling mechanism.** Makers verify makers, staking reputation. It's *provenance verifying provenance* (real makers spot real makers), the web *is* a trust graph (harder to copy than a checkmark DB — it deepens the moat), and vouching doubles as community formation. **But it's the highest-stakes mechanism** — a Sybil/collusion surface that fails *catastrophically* (one polluted item in the "verified" feed breaks the guarantee). Build a *rooted, staked, multi-vouch trust web with a sampling audit*, never flat "anyone verified can verify anyone":
- **Real, slashable stake** — a bad vouch costs the voucher (authority revoked, status reviewed), or "staked reputation" is a farmable click.
- **Rooted graph** — anchor early verifications to a seed set *you* verified; every verified maker traces back to a root, so a compromised subtree can be found and revoked.
- **Multiple independent vouches** for full status (ideally not all from one cluster).
- **Sampling audit** (random + risk-triggered) so abuse is expensive and detectable, and **ring-pattern instrumentation** from day one.
**Sequencing:** do *not* launch with peer verification. Verify makers yourself early (few enough for manual review, and you *need* to establish the root set). Enable peer verification once roots exist and volume makes manual review the bottleneck. Verification is now load-bearing in four places (referrals, Curated-By, buyer feed, agent feed), so throughput is a real growth governor — design the scaling path (tiered verification, community vouching as signal, provenance-documentation standards) early.
### Per-item provenance: the catalog's originality layer
Verification answers a question about the *maker* (is this a real maker of original work?); provenance answers it about the *item* (is *this product* their original work?). A real maker's catalog is mixed — a potter sells their pots **and** resells pottery tools — and that is fine. What matters is that the buyer, and the trust surfaces, can always tell which is which. So every catalog item carries a **provenance classification** (metadata, like the cross-maker component layer below), **self-attested** by the maker, **audited** by the trust machinery, and **shown to the buyer**:
- **Original** — the maker's own original art or craft (the pots). Purchased raw materials and supplies (clay, glaze, blanks) are inputs to *making*, not other-sourced components — a pot thrown from bought clay is original.
- **Original + components (composite / kit)** — primarily the maker's work but incorporating identifiable parts from others; attributes each contributor (in-network Maker Y, or flagged where out-of-network). The kit / "partial" case, reusing the cross-maker component-metadata layer below.
- **Resale — fellow Maker** — reselling another in-network maker's original item; provenance still traces to the true maker. (This is Curated-By / consignment expressed as a catalog item.)
- **Resale — third-party / not original** — out-of-network commercial goods, tools, or supplies (the resold pottery tools). Honest, allowed, and clearly *not* original.
Two rules ride on the classification:
- **Buyer transparency is the point.** Every item shows its provenance badge — the consumer-facing expression of the moat: not merely "this maker is verified," but "this *item* is original / partly original / a resale / not original (and contains these makers' work)." It is the precise anti-Etsy signal — you always know what you're buying — and it *appreciates* as AI-generated and drop-shipped fakes proliferate.
- **Trust-surface eligibility keys off it, per item.** Only **original** and **original-+-(in-network)-components** items are surfaced as the maker's original work in Curated-By / buyer feed / agent feed. A **fellow-Maker resale** may surface *attributed to the true maker* (that *is* Curated-By). **Third-party resale never enters a trust surface** — surfacing it would launder non-original goods through a trusted face (the Etsy-pollution failure mode, from the inside). A composite that contains any non-original component is flagged as such wherever it appears.
The hard, still-open part is the **line between making and reselling** — finishing, assembling, and kitting sit in between (the standard to write, §14 #2): purchased supplies don't taint "original," but assembling mostly-third-party parts isn't original either. Misclassifying a resale as "original" is a provenance lie → a verification-revocation trigger (trust & safety, §10). Self-attestation makes classifying cheap; the sampling audit plus buyer reporting make gaming it risky.
### Non-maker referrers: the verified taste-maker tier (Phase 2)
Any website can join as a *referrer* — a taste-maker/curator (a hobby YouTuber, blogger, podcaster) who isn't a maker but has audience and taste. Financially low-risk (pay-on-conversion, no custody, no MoR, no inventory). The risk is to the **verification moat**, handled by the *same tiering as makers*:
- **Unverified referrer (open tier).** Generates referral links to verified makers, earns on conversion, but is **not surfaced in any trust-dependent surface** — a traffic source, self-limiting (a bad one doesn't convert) and contained (can't touch trust surfaces).
- **Verified taste-maker (trust tier).** A legitimate community voice verified as a *trusted curator* (not a maker), reputation-staked and slashable — badge, surfacing, loses status for shilling. Verification separates the genuine taste-maker (additive) from the affiliate-spam farm (corrosive).
**The load-bearing guardrail for this tier: uniform, non-biddable referral rates.** A maker-curator's commission pull is counterbalanced by peer respect (and the structural ranking-neutrality guarantee), which is why **maker↔maker rewards are negotiable above the fixed spread** (§7, "Referral economics"). A pure taste-maker's incentive is more purely the fee, so that same negotiability would let them chase the highest payer — retail media through the referrer door. **For non-maker taste-makers, therefore, rates stay uniform and non-biddable** — they feature on **taste, not who pays most.** Plus **disclosure/labeling** (distinguish a maker's peer vouch from a taste-maker's disclosed-affiliate pick; FTC-required anyway), **referrer-only/one-directional** (never a destination, never a maker-verifier), and the **no-walled-garden rule** still holds.
**Why it's worth doing:** taste-makers are the **net-new-demand engine** the maker-only network is structurally weak at — a third source alongside maker-curation (deepens) and agents (reach), and the most community-native (a trusted human voice, not an algorithm).
**Phase 2, and a marginal add — not a new crossing.** A pure referrer has no fees to offset, so they need **cashable payout** — the same Connect/mass-pay rail Phase 2 already builds for cashable maker wallets and kit pure-supplier payouts. Three consumers, one scoped crossing; the marginal cost is the verification tier + uniform rate, not new money plumbing. (Paying a taste-maker is a *payout* to an affiliate — principal-on-both-sides, two independent events — not consumer money transmission.) Reserve option: a marquee taste-maker can accrue a pending cashable balance in Phase 1, paid on rail launch — don't open generally.
### The buyer-facing feed (Phase 2+) — how the marketplace emerges
A consumer surface (site/app + email) where buyers see followed makers' drops, "buy it again," and Curated-By from makers they follow. This is **how the marketplace *emerges*** from accumulated follows rather than launching cold into the curation-vs-liquidity graveyard (§5).
**Core principle — discovery is delegated to makers the buyer chose, never performed by the platform.** Every recommendation traces to a follow the buyer initiated. The platform never originates a recommendation — no "you might also like," no algorithmic cross-maker surfacing, no house-promoted placement. **Maker-as-discovery-engine, platform-as-pipe** — the *inverse* of the Shop app. Three payoffs: it keeps you **out of the discovery war** (you never compete with Amazon/Google/agents on recommendation quality); it keeps the feed **non-threatening to sovereign makers** (no buyer sees a maker they didn't choose or that a followed maker didn't vouch for); and it preserves **curation integrity** (follow-gated, reputation-staked curation can't be gamed toward pollution like an engagement algorithm).
**The deliberate tradeoff:** pure follow-gated discovery is intentionally *weaker at net-new demand* — it deepens the graph buyers already know but doesn't introduce makers outside it. Growth stays permanently "makers bring audiences and vouch," never "the platform surfaces new reach" (agents and taste-makers are the net-new hedges). The correct trade for this positioning, as long as it's chosen knowingly. Disciplines: **buyer-opt-in by nature** (doubling as cross-merchant data consent); lead with the safe end (buy-it-again → followed drops → curated-by); any move toward platform-originated/algorithmic discovery is a deliberate, opt-in-by-everyone, much-later decision.
### Storefront architecture & Shopify coexistence
**Two layers, kept separate — the core architectural decision.** A *storefront layer* (per maker) sits under a *shared cross-maker network service* (the moat). Conflating them couples the moat to one storefront engine and to single-tenant boundaries.
- **Storefront layer (per maker).** Either your **white-label storefront** (headless backend + themed frontend) or the maker's **existing Shopify store** (federated). Handles that maker's catalog, cart, checkout, orders, and own payment processor (MoR).
- **Shared network service (cross-tenant — the moat).** Verification graph; **canonical catalog index** — *with a cross-maker component-metadata layer* ("this product contains a component made by Maker Y," the kit/BOM relationship expressed in the catalog itself); cross-maker identity/follow graph; **a complete per-maker order history** (every order since the maker joined — captured because referral/fee computation must see orders, and reused for the transparency below); referral/Curated-By attribution + fee/wallet ledger; buyer feed; agent/ACP feed. A standalone service with its own datastore, spanning *all* makers and federating over heterogeneous storefronts — deliberately **not** part of any storefront engine.
**The canonical catalog index lives in the network service — not a Medusa "mega-store."** Every maker's catalog (Shopify via Admin API, your Medusa storefronts via their API, anything else via adapters) is transformed into one normalized, verified index that powers Curated-By, the feed, and agents. A Medusa instance is a *storefront* (cart, checkout, one MoR, sellable inventory); the network catalog is a read-optimized *index* of products that live and sell elsewhere. Pouring all makers into one Medusa instance would make a thing shaped like a store that must never behave like one, and couple the neutral network to one engine. Keep each storefront as the system of record; the network holds a normalized verified *projection* — which also keeps Shopify and Medusa products *co-equal sources*, not Shopify imports into a competitor-shaped container.
**Cross-merchant order transparency — the positive-sum twin of the money-flow "no."** Because the network already sees every maker's orders (it must, to compute referrals) and knows which products contain other makers' components (the catalog metadata layer), it can hand each maker something no single-store tool can: **visibility into every order that touches their work anywhere in the network** — their item sold inside another maker's kit, a referral they sent that converted, a component of theirs moving through a partner's store. This is the grocery **scan-based / Direct-Store-Delivery** pattern: the supplier sees the sell-through and knows when to restock or re-engage, *without being the store*. It costs the network nothing to give (it already holds the data), it is **uniquely the network's to give** (only the cross-tenant vantage sees across stores — which deepens the moat), and it stays firmly on the right side of the line: **transparency and coordination are free; custody is not** (the kit-supplier notification in Appendix C.2 is one instance). One asset, three uses — the same order history powers the referral ledger, the network-health metrics (§12), and this reporting.
**Build the white-label storefront on a headless backend (Medusa recommended).** "Build the 20%, rent the 80%" in code: the headless backend (Medusa — Node/TS, modular, payment-agnostic, no per-order revenue share; alternatives Saleor, Vendure, Spree) supplies cart, catalog, orders, customers, fulfillment, BYO payment, and you add the commitment-commerce engine — **drops, pre-orders, clubs, raffle/queue — as custom backend modules.** Mental model: in Medusa, *modules are backend domain logic; the storefront is a separate frontend app* consuming the Store API. So **the storefront is not a module** — the commitment-commerce *features* are modules, the storefront is their client, and the network service above is neither (standalone). Multi-tenancy (one shared instance vs. per-maker instances) is decoupled from the moat because the network service is separate either way; for two pilots, a single instance + shared theme is plenty.
**Shopify makers: federate, don't migrate.** The network is storefront-agnostic, so a Shopify maker keeps Shopify (their MoR/processor) and joins via two hooks: **catalog sync** (Admin API + product webhooks into the verified index → eligible for Curated-By/feed/agents) and **referral handoff + attribution** (the Curated-By link carries a signed token that rides in as a **cart attribute → order note_attribute**, read from the order webhook to bill B / credit A — no checkout customization, any plan). **Hybrid wedge:** evergreen catalog stays on Shopify; the maker uses your platform only for the commitment-commerce *events* Shopify handles badly. Migrate later only if earned.
**Curated-By on Shopify** rides **one installed app** built on **theme app extensions** (not legacy ScriptTag): a draggable **app *block*** for the curator role (renders verified picks from your network service, links carry the token) and an **app *embed*** for the recipient role (reads `?ref=` on landing, writes it as a cart attribute → order note_attribute → `orders/create` webhook). The app is a thin client — curation, verification, and the ledger live in your network service. Optional app proxy for crawlable server-rendered sections. Because it rides cart attributes through native checkout, the *entire* loop — display and attribution — works on a stock Shopify store with no checkout access and no theme surgery.
**Strategic payoff:** the storefront-agnostic network makes your addressable makers the *entire* Shopify/Etsy/standalone install base — reachable via federation, not just makers willing to switch storefronts. The storefront is the wedge for makers who want a better tool; the network is open to anyone who verifies and syncs a catalog. This de-risks the scariest adoption question ("will makers switch storefronts?") — they don't have to. (Caveats: Shopify APIs are partly rented land, but you're not dependent on them — one source among several; Shopify takes its cut on Shopify sales, fine, since you bill your fee separately via ACH.)
**Admin surfaces — three, not two.** The *network* is one product with one admin for everyone; the *storefront* admin is Medusa's (your makers) or Shopify's (theirs).
- **Storefront admin** — only for your Medusa makers (products, drops, orders, fulfillment); a Shopify maker uses Shopify's admin.
- **Network admin (bespoke, universal)** — curation, referral earnings + wallet, verification status + peer-vouching, follow/feed participation, network + agent opt-ins. No home in either storefront engine because it's the cross-tenant moat layer.
- **Billing/account (bespoke, universal)** — ACH mandate, fee tier, invoices, payment history.
So everyone uses the bespoke network + billing admin; Medusa makers *additionally* get Medusa's storefront admin; Shopify makers get theirs from Shopify. Notes: **ACH is universal, not referral-specific** — every maker gives a debit mandate at onboarding (gate mandate-on-file as a precondition for referral eligibility, so a referral-only maker can't accrue an uncollectable fee). And **Shopify makers get a read-mostly catalog/sync/analytics view** — a trust surface: a mirror (not a second editor; Shopify stays system of record), sync health (a silently-broken sync makes products vanish from the feed), and **network analytics** uniquely yours to provide because only you see across stores ("Curated-By sent me $800 last month" does quiet retention work). **Build-ordering:** the bespoke network + billing + analytics admin is foundational and on the critical path for both populations from day one — even the two Medusa pilots need it the moment Curated-By and referrals exist.
### Business model: network is the product, storefront is an optional convenience
Now that Medusa exists and the network federates over any storefront, *centering* on storefront hosting has weakened — three erosions: the storefront is the commodity layer; Medusa makes it cheap for everyone; federation means a maker doesn't *need* your storefront to be in the network.
- **The network is the product and the value capture.** Charge for the network — referral take + subscription — **uniformly, whether a maker is on your storefront or Shopify.** Revenue must not depend on storefront adoption; that keeps you credibly neutral and makes TAM = *every* maker.
- **The storefront is an optional, opt-in convenience — SaaS-priced, never GMV.** GMV-take would recreate channel conflict, tax makers for using your rails (making your storefront *worse* than self-hosted Medusa), and pull you back toward money-flow entanglements. Price it as a flat SaaS fee that covers cost.
- **Three postures — reject the first.** *Don't* be a storefront company with a network (GMV fees, competing with Shopify on hosting — wrong center of gravity). *Do* be a network company that offers a storefront — the best-in-class native commitment-commerce experience for makers who want it or have nowhere else to be — as a wedge, not the business.
**"Why not just point makers to Medusa Cloud?"** Because Medusa Cloud sells *hosted infrastructure to developers*; it doesn't give a maker a working drops-and-clubs storefront. You sell a **vertical, maker-ready commitment-commerce product** where Medusa is *invisible plumbing*. The entire gap between raw infrastructure and a working maker storefront is your product — pointing a maker to Medusa Cloud is like pointing them to AWS. Corollary: **don't position or price as a hosting company** ("Medusa Cloud + modules" drags you into competing on infra margins). Hosting is a cost you absorb; the vertical experience (and the network) is what you sell.
### Partner / consultant network: onboarding the high-touch tail
Implementation consultants (community-embedded especially) onboard the **high-touch tail** without the network becoming a services business, doubling as community-aligned distribution and mirroring the partner ecosystems that grew Shopify and Medusa — a second flywheel you *enable* (certification, a directory, the referral-income share below) but don't *staff*. Guardrails: keep the product **genuinely self-serve for the median maker** (if makers *need* a consultant for a basic store, the product failed and partners are masking it), and structure partners as **referral/implementation partners, not white-label resellers**, so they don't become the relationship-owner and disintermediate you.
**How partners are paid — a negotiated, tapering share of the maker's *earned* referral income.** A maker may opt to bring on a partner to stand up their storefront and onboard them onto the referral network, and pay for that help out of the upside it creates: the partner earns a **share of the referral income the maker earns *as a curator*** (the negotiated Curated-By referral reward in "Referral economics" above) — not a fee on the maker's sales, and not a cut of the platform's spread. The natural shape is **front-loaded and tapering** — e.g. 100% of the maker's first $X in referral earnings to the partner, then a declining share as the maker's curation takes off — a *help-me-start, earn-out* deal, not a perpetual tax. The two negotiate and structure the schedule through **platform tooling**; the network stores the agreed terms and settles the split. This is the *one* partner-compensation leg the network touches, and it rides the same invariants as the rest of the money model, so it adds posture, not exposure:
- **Out of the flow, principal on both sides.** The platform never routes the maker's money to the partner (that is custody / transmission — Appendix C.2's line); it independently *reduces* the maker's referral credit and *extends* the partner a credit or payout — two events, principal on each, never a conduit (the §7 referral-economics pattern).
- **A fourth consumer of the one Phase-2 cashable rail.** The maker's referral credit is non-cashable (fee-offset); a partner who isn't itself a maker has no platform fees to offset, so — exactly like the verified taste-maker and the kit pure-supplier — it needs *cashable* payout over the same scoped Connect/mass-pay crossing Phase 2 already builds. (A partner who *is* a maker can take non-cashable wallet credit instead.) One more rider on that crossing, not new money plumbing; Phase 1 can accrue the partner's split as *pending* and pay it on rail launch.
- **The negotiation tooling is the ledger pattern already required.** "Partner P takes schedule S of maker A's referral earnings, tiered by cumulative $" is **stateful settlement on a running total** — the same machinery as the wholesale volume tiers (Appendix C.5): the schedule is a stored term, settlement is cumulative (not per-order-independent), and the retroactive-vs-prospective question at a tier boundary is a term the two agree and the platform applies. Build the ledger for cumulative partner splits from the start.
- **The curation-integrity guardrail still binds.** The partner shares the maker's *earned* income but gets **no say in *whom* the maker vouches for** — otherwise a partner would push the maker toward whatever converts, reintroducing the commission-corruption drift the whole referral design resists (§3; "Curated By This Maker"). Disclosure applies where a partner relationship would read to buyers as paid placement (FTC, §11). The deal is comp for *activation*, not influence over *taste*.
**Cash, payment terms, and any other agreement live *outside* the network — by the same money-flow rule.** The referral-income split above is the only money leg the network handles, precisely *because* it can be done principal-on-both-sides without entering the flow. Everything else a partner and maker might agree — an **upfront cash payment, a setup fee, a retainer or hourly, milestone payments, or any other lawful arrangement** — is a **direct business agreement between the two, settled off-platform**, exactly as a maker pays any other vendor it hires. The network neither processes nor takes custody of that money, because doing so would put it squarely back in the money flow it is built to stay out of (custody is the line — "Money flow: stay out of it"; Appendix C.2; the spine). So the division is clean: **the network settles the one leg it can keep out of the flow (the referral-income share, via the cashable rail), and stays entirely clear of every direct-cash leg, which the parties arrange and settle themselves.** The tooling may *record* an off-network term for the parties' own clarity (recording is coordination, which is free) — but it never *moves* that money.
The org is a **true non-profit (501(c)(3) or equivalent), radically transparent (open books), engineered by volunteers with LLM-accelerated development, not raising money or selling equity.** This converts the trust position from a *promise* into a *guarantee*, and it's funded-viable for a reason that's thematically exact:
- **The cost structure that usually makes non-profit tech infeasible is the one LLMs just collapsed.** The primary cost center — engineering — has been deflated by the same force the venture exploits. The entity and the opportunity are the same bet pointed two ways.
- **No fundraising removes the only strong argument against true non-profit** (a PBC/B-Corp hedge exists only to preserve VC/equity optionality — which here is the door makers fear, so foreclosing it is the point).
- **The structure *enforces* the anti-Etsy promise.** A 501(c)(3) legally can't be sold or distribute profits — the strongest answer to "will you sell our trust for GMV?" "Bind with structure, not promises," realized in the entity itself.
- **Radical transparency is the substrate of the verification moat.** Open books/governance let the community *verify the incorruptibility* of "verified handmade" rather than take it on faith — the mechanism, not a nice-to-have.
**The risk moved, it didn't vanish:** apply the rigor you'd have spent on fundraising to **volunteer sustainability.** LLMs change the math but not the human dynamics (attrition, bus-factor). Separate what needs reliability (network service, ledger, verification) from what tolerates volunteer cadence (themes, nice-to-haves), and keep the critical core off bus-factor-one. Also watch the **"fragile" perception** with professional makers — non-profit + volunteer reads as *aligned* to commons-minded makers but possibly *might-fold* to those building a livelihood; transparency is the counter, and §8 should test whether it reads **safe** or **nervous**.
### Hosting: managed vs. self-host (and the pilot)
**What you sell and where you host are independent** — makers never see the infrastructure, so hosting is a pure cost/ops choice, *reversible and invisible* because Medusa is portable. **Managed (e.g., Medusa Cloud) now** (your scarce resource is attention on product + network, not infra savings); **self-host at scale** (unit economics; don't couple margins to one vendor). Multi-tenancy interacts with hosting price (per-maker instances multiply managed per-instance pricing; a shared instance is different math) — negotiate as a *multi-instance platform customer*. **The network service is hosted separately, always** — that separation is what makes the hosting choice switchable.
**The two-maker pilot:** self-host on **GCP — Cloud Run + Cloud SQL (Postgres)**. Cloud Run scales toward zero when idle (suits drop-spiky traffic) and avoids babysitting a cluster at n=2; the shared-instance cost is low tens of dollars/month. **Watch the drop-traffic spike** — a scheduled drop is a burst of concurrent buyers, exactly the load that embarrasses an under-provisioned instance, and a storefront falling over *during a drop* is the worst moment for maker trust; load-check before a real drop. On cost: pass-through or a flat fee is fine, but **treat cost recovery as trivial** — two happy pilot makers (your first verification roots and references) are worth far more than reconciling a small GCP invoice. Frame any charge as "covering pilot costs," not the product's pricing model.
---
## 8. Next step: maker discovery (do this before building the platform)
Goal: verify whether the cross-merchant-identity conversion advantage (Shop Pay's lift) is a *real moat for these makers*, and whether you can build your own version — and, more broadly, whether the demand side exists.
**Avoid the measurement trap.** Don't ask "how much value does Shop Pay give you" — makers can't see the conversion counterfactual, so answers are vibes. Shop Pay's lift comes from **cross-merchant identity recognition removing first-purchase friction**, so measure the driver: the revenue split between **repeat fans vs. first-time strangers**, and whether buyers **already have Shop Pay**. (Repeat-fan-heavy makers capture little of the network effect; viral/stranger-traffic makers capture a lot.)
**Don't concede a false tradeoff.** "Lose conversion to gain alignment" assumes you can't have the lift — but a curated cross-promotion network *structurally generates* cross-merchant identity as a byproduct (your own niche-scoped Shop Pay equivalent). You can't offer it day one (cold-start), but it's a **year-three asset, not a launch feature.** Concede the *timeline*, not the moat.
**Listen for (beyond what you ask):** where buyers come from today (traffic-mix tell); what they pay Shopify **all-in** vs. what they *think* (most underestimate — the gap is your opening); whether the value-alignment grievance is real willingness-to-switch or venting; whether they'd want shared buyer recognition or guard their list; and — the asset they'll least volunteer — **whether they have an audience they'd bring** (a maker with no audience is a cost, not an asset). Also test whether the **non-profit/volunteer/transparent** framing reads as *safe* or *fragile*.
**Weight what makers *do* over what they *say*.** "I'd switch for alignment and lower fees" is cheap and constantly contradicted by behavior (people stay on Etsy they openly resent). The makers worth building for already maintain a second channel, already *moved* on something, already bring their own buyers.
**Interview log — early signal (2 greenfield makers, no existing site).** Liked *quickly spinning up an in-network storefront* (a network subdomain, not a dedicated domain) over a standalone site — confirming the greenfield on-ramp and the in-network address as a *preferred default*. Both conditioned it on *owning the customer*, which probing clarified means **usage-rights** (market to them directly, use/export the list, on or off the network) — the sovereignty principle reinvented unprompted. **Two cautions:** (1) the weakest evidence tier (liking an idea ≠ adopting ≠ paying ≠ staying) — chase the *behavioral* next step (real catalog in, a real drop, a referral); (2) it validates the *supply/storefront-convenience* (commodity) layer only — the **demand/curation moat is still untested** (do they have audiences, would they vouch, would they want to be vouched-for?). The network layer remains the load-bearing unknown.
---
## 9. Decision gates
Gate the real platform build on evidence, not enthusiasm:
- Do the first makers **refer you** to others?
- Is the **pain consistent** across makers (the same 20%)?
- Do target makers **have audiences**?
- Can you reach roughly a **dozen makers** who want the same thing?
Two makers justify a thoughtful, portable data model. They do not justify a platform. Build the data layer and the vertical primitives now; gate everything else on the dozen.
These gates are stated qualitatively here; §12 gives each a quantitative instrument (and a North Star) computed from the cross-merchant order history, so the dozen-maker gate can be *measured* rather than felt.
---
## 10. Trust & safety & maker accountability
Verification (§7) is only an *entry* gate — it answers "is this a real maker of original work?" at the door. This section is the other half: **what happens when a verified maker behaves badly afterward.** Commitment commerce makes this the *signature* failure mode, not an edge case — "a verified maker collects pre-orders/deposits and ghosts" is the structurally most-likely scam, because the model takes money before delivery (§4). The money-flow stance solved the *financial* exposure (the maker is MoR, so the platform never holds the funds at risk — §7), but it did **nothing** for the *reputational* exposure — and the reputational one is the exact thing the moat rests on. A single polluted "verified" item breaks the guarantee for every buyer and every agent downstream.
The **shape** below is settled; the **reputation engine itself is explicitly OHM-guided work** (handbook §4.4, [OHM](https://rfc.wiggleverse.org/p/ohm/c/default/)) and is gathered in the last subsection. This whole section turns on OHM concepts — **reputation, trust, harm, recourse, value, dignity** — so where it names one, the canonical RFC governs: cite it, propose it where undefined, don't coin a local meaning.
### The originating edge — the trust topology
- **Every maker enters by invitation, and the invitation *is* a vouch** that the invitee makes original art or craft — rooted in a staff-verified seed set (§7 verification). The invitation graph is a **permanent topology**: every maker traces back, by some chain of vouches, to a root the platform verified directly. (The membership gate starts invitation-only and loosens toward open signup over time — §7 — but the originating edge persists as graph structure even after the front door opens.)
- **Inviting doesn't pay.** The incentive to invite is the commercial relationship the network creates, **never a bounty** — a per-invite payout would manufacture exactly the Sybil/farming incentive the rooted graph exists to resist. You invite people whose work you'd stake your standing on, because that is what the edge means.
### How reputation flows along the edge
- **Reputation flows *up* the originating edge** — when a maker misbehaves, consequence propagates back toward whoever vouched for them — but **transitively, decayed (a per-hop coefficient), and hop-capped.** So the impact is **strong right next to the misbehavior** (a prompt-to-act for the inviter who actually can act) and **negligible by ~6 degrees out** (a distant root isn't punished for a great-great-invitee's fraud).
- **Framed as positive reinforcement, not punishment.** The primary direction is *earning and growing standing* by vouching well and making well; the up-the-edge consequence is the downside tail of that same mechanism, not a separate penalty system. Good vouching compounds standing; a bad vouch costs the voucher (this is the §7 verification "slashable stake," seen from the accountability side).
### Consequence: loss of standing, not expulsion
- **The consequence is a low, buyer-visible reputation score + loss of all network benefit** (Curated-By, the buyer feed, referrals, the agent feed) — **not expulsion.** The misbehaving maker **keeps the storefront and the tool** (they are a paying SaaS customer, and the tool was never the thing gated — "gate the demand, not the tool"), but **loses amplification** and **wears a score buyers can act on.** This is *transparency as enforcement*: rather than policing every maker centrally, the network makes standing legible and lets buyers route around bad actors — which keeps the trust surfaces clean *by construction*, since a low-standing maker has already fallen out of Curated-By / feed / agents.
- **This is a "member in bad standing," not the rejected model "a."** It is emphatically **not** flat "anyone can verify anyone" (§7 warns against that). At launch every storefront holder was *invited*, so even a maker in bad standing entered through the rooted graph — they are a member who lost standing, not an anonymous bad actor who slipped the gate.
### Authority & appeal
- **The inviter holds primary suspend/expel authority** over their own sub-graph — the person who vouched is the person best placed, and most motivated (their standing is on the line), to act. Layered on top: a **platform floor for active buyer harm** (the platform can act directly when buyers are being harmed, regardless of what an inviter does), and a **governance appeal path** (§14 #1) for the maker who believes a consequence was unjust. **Expulsion is the rare extreme**, reserved for active harm — the default consequence is loss of standing, above.
- **Provenance lies are trust violations.** Misclassifying a resale as "original" (§7 per-item provenance) is not a clerical error — it is a deception that pollutes the trust surfaces, and so it is a verification-revocation trigger handled by this machinery.
- **The legal spine of the ghosting case is in §11.** Non-delivery isn't only a reputation event: the FTC 30-Day Rule (§11, "Consumer protection / FTC") is what a ghosting maker is *violating*, and the platform's compliance-by-design notice/refund UX is the buyer's first recourse *before* a chargeback against the maker's processor. Reputation consequence and legal recourse are two responses to the same act.
### Still open — the OHM-guided reputation engine (and adjacent frameworks)
The **shape** above is settled; the **system** that implements it is the open work, and it is OHM-guided by nature:
- **The reputation engine itself** — scoring, the decay-coefficient and hop-cap *values*, how good standing accrues over time, how the score is *displayed* to buyers, and the benefit-gating thresholds (what score loses Curated-By vs. the feed vs. agents) — all turn on operationalizing OHM **reputation, trust, harm, recourse, value, dignity**. Defer to the relevant RFCs; propose them where undefined (a load-bearing concept OHM hasn't defined is itself OHM work, not license to improvise — top-of-file note).
- **Verification-revocation triggers and process** — the concrete patterns that drop a maker's standing or revoke verification (non-delivery pattern, inauthentic/AI-generated goods passed as handmade, sustained non-response), and the process around each.
- **The buyer-harm / dispute framework** — how a buyer reports harm, how it's adjudicated, and the recourse on each side.
- **Non-delivery handling, given the platform is out of the flow** — the platform is **not a guarantor** (it holds no funds to refund from); the buyer's monetary recourse is a chargeback against the maker's own processor (maker is MoR), and the platform's contribution is *transparency* (the score, the public consequence) plus the §11 compliance UX — not an escrow it deliberately declined to hold.
- **False-report and collusion controls** — the abuse surface of the accountability system itself (weaponized reports, retaliatory low scores, collusion rings), instrumented from day one alongside the §7 verification ring-detection.
---
## 11. Legal & compliance
The memo's legal strategy is not a list of compliance chores bolted on at the end — **it is one architectural choice, viewed through a legal lens.** Staying out of the money flow (§7, "Money flow: stay out of it") was justified there as a financial-risk decision; its larger payoff is *legal*: a single structural fact — **the maker is merchant of record on the maker's own processor, and the network never touches buyer funds** — discharges obligations across three otherwise-separate regulatory categories at once. **No money transmission. No marketplace-facilitator tax duty. No merchant-of-record liability.** Where a competitor that sits in the flow must license, collect, remit, and indemnify, the network simply isn't the regulated party. The genuine open exposures are exactly the ones that *aren't* dissolved by the money-flow stance — and the discipline of this section is to separate the two: what the architecture already answers (recap, hold the line) from what it doesn't (engineer down, or flag for counsel).
**Convention: flag and verify — not legal advice.** Everything below is the *engineering posture* — the structural choices that keep the regulatory surface small, and the questions worth putting to specialist counsel. It is not legal advice; each item names what to verify and with whom. Where a principle turns on a load-bearing concept — *consent, harm, recourse, value, dignity* — it defers to the [Open Human Model](https://rfc.wiggleverse.org/p/ohm/c/default/) per the top-of-file note (handbook §4.4): cite the RFC, don't coin a local meaning.
### Money transmission (MTL) — recap from §7
Out of the flow → **none.** Holding customer funds (escrow, a balance, a payout you control) triggers state-by-state money-transmitter licensing in the US — the single most expensive licensing regime a small org could wander into. The network never holds buyer funds: the maker is MoR on the maker's own processor, and the platform fee is billed in arrears via ACH/invoice (§7, "How the platform gets paid"), which is the network charging *its own customer for software*, not transmitting a third party's money.
- **The cashable Phase-2 rail rents a licensed transmitter — it doesn't become one.** When cashable payouts arrive (maker wallet cash-out, kit pure-supplier settlement, taste-maker affiliate payout — §7), the money moves over a BaaS rail (Stripe Connect/Treasury, Dwolla, a mass-pay provider) whose operator *is* the licensed money transmitter. The network is a platform user of that rail, not the regulated transmitter — the "rent the licensed infra, don't build it" move applied to compliance.
- **The non-cashable wallet is not stored value.** The fee-offset wallet (§7) credits a maker against *future platform fees* — a discount / accounts-receivable entry, not a balance the maker can withdraw or spend with third parties. It is therefore neither stored value, a prepaid-access instrument, nor transmittable money, and stays outside the MT and stored-value regimes by construction. **Cashing out is the deliberate crossing** that re-opens the door — which is precisely why it is gated to Phase 2 behind a rented transmitter, never a toggle. *(Verify the wallet's non-cashable design against your states' stored-value / prepaid-access definitions before launch.)*
### Marketplace-facilitator sales tax — the centerpiece
This is the high-consequence area the memo had entirely missing, and the one most likely to surprise. Post-*Wayfair*, every US state with a sales tax has enacted **marketplace-facilitator statutes** that can attach a *tax-collection-and-remittance duty* to a "marketplace facilitator" **even when it is not the merchant of record** — the whole point of these statutes was to make the platform, not thousands of small sellers, the collection point. So "the maker is MoR" does **not**, by itself, settle it; facilitator status turns on a separate test.
**The two-part conjunctive test.** In most states (modeled on the SSUTA / MTC definition) you are a marketplace facilitator only if you do **both**: **(prong 1)** list, advertise, or otherwise facilitate the sale of a marketplace seller's products, **and****(prong 2)** directly or indirectly **collect the payment** from the purchaser and transmit it to the seller. Both prongs are required — it is conjunctive, not "either."
- **The referral-handoff model (§7, Model A) fails prong 2 — by design.** Checkout happens entirely on Maker B's own store and processor; the network passes a signed referral token, then bills B a fee and credits A — money on which the network is *principal* (its own fee revenue, its own credit), never buyer payment it collects and forwards. It arguably satisfies prong 1 (it facilitates discovery) but **cannot satisfy prong 2**, so it is not a facilitator. Many statutes reinforce this with an explicit **advertising-only / referral exclusion**: a person who merely advertises or lists products and refers purchasers to the seller, *without processing the payment*, is carved out by name. The referral network sits squarely inside that exclusion — which is *why* it is a referral network and not a checkout.
- **The fragile edge is "indirectly collects payment."** Prong 2's "indirectly" is the word that does the damage: some statutes read it broadly enough to sweep in arrangements where the platform touches the payment flow even lightly (routing, splitting, holding briefly). The referral handoff is safe because it touches **zero** payment flow — but the margin of safety is "we never touch the money," not "we're small." The moment any feature lets the network touch buyer payment, the edge moves.
- **Danger zones — where prong 2 attaches and facilitator status flips on:**
- **Phase-3 shared checkout (§7).** A unified cart where the *network* collects the buyer's payment and routes/splits it to makers directly collects payment — prong 2 satisfied, facilitator duty attaches. This is exactly the "much later, optional, opt-in" crossing the phasing reserves, and **it carries a sales-tax-collection obligation as a first-class consequence**, not an afterthought.
- **Split-payment kits (Appendix C, Model 3 — Connect destination charges).** One checkout auto-splitting to N connected accounts has the platform *indirectly collecting and transmitting* — facilitator. One more reason Model 3 is "avoid until you choose to be marketplace-of-record for kits."
- **Connect destination/separate charges or `application_fee` where the platform is MoR.** The §7 charge-type dial that flips MoR to the platform *also* flips facilitator status, because platform-MoR means the platform is indirectly collecting the buyer's payment. The Connect setting is, again, a legal-posture decision (next).
- **Tax calculation belongs to the maker's storefront layer — never the network.** Sales-tax *calculation, collection, and remittance* is the MoR's job, and the MoR is the maker. Both storefront engines do it natively (Shopify Tax; Medusa's tax module) and both integrate the specialist engines (Avalara, TaxJar) for nexus-aware rates and filing. The network must **not** build tax-calc — doing so would quietly adopt the very duty the architecture declines, and would invite the argument that a thing computing sales tax across makers is behaving like a facilitator. The network computes *its own* fees; the storefront computes the buyer's tax. *(Confirm facilitator status per state with a SALT attorney before any feature that touches buyer payment — especially before Phase 3.)*
### Stripe Connect configuration as legal posture — see §7
The Connect configuration is the hinge on which MTL, facilitator status, *and* merchant-of-record liability all turn, and it is **already specified in §7** ("Money flow"): the stance holds **only at Standard accounts + direct charges + `application_fee`** — maker stays MoR, disputes stay on the maker's balance, the network skims a fee without entering the flow. Destination / separate-charges-and-transfers and Express/Custom accounts each flip one or more of those properties (MoR → platform, dispute liability → platform, indirectly-collecting → true → facilitator). This section only records *why* §7's setting is a legal constraint and not an implementation detail; the dial itself is governed there. **Do not re-decide it here — cross-reference and hold the line.**
### Raffle / lottery — engineer out the consideration
The raffle drop is the one primitive (§4) with direct **gambling-law** exposure. A lottery is three elements, **conjunctive: prize + chance + consideration.** Remove any one and it is not a lottery — so the design removes the controllable one.
- **Free-entry allocation removes *consideration*.** The default raffle/queue mechanic allocates a *right to buy* a scarce drop by random draw, with **free entry** — no payment to enter the draw; the winner then purchases at the normal price like any other buyer. With no consideration paid for the *chance*, there is no lottery: it is allocation of limited inventory by lot, not a paid gamble (the same shape as a "no purchase necessary" sweepstakes — the chance must be free). The OHM frame is *fairness/dignity* in allocation: a transparent, equal-chance draw for scarce goods, not pay-to-play.
- **Paid-entry raffle is off by default, pending per-state clearance.** A raffle where the buyer *pays to enter a draw for a prize* re-adds consideration and is a regulated raffle/lottery — generally unlawful for a commercial entity, lawful only for licensed nonprofits in some states, banned or tightly restricted (registration, caps, reporting) in others. It ships **disabled by default**, gated behind explicit per-state legal clearance. *Note the cross-current:* the 501(c)(3) entity (§7) may actually *open* charitable-raffle paths a commercial operator can't use — but that is a flag for counsel and a deliberate per-state opt-in, **not** a green light to turn paid raffles on. *(Verify per state — gambling / charitable-gaming law is among the most locally variable regimes there is.)*
### Consumer protection / FTC
Three distinct FTC-adjacent duties: two fall on the maker (the seller / MoR) with the platform easing compliance, one the platform's own architecture already discharges.
- **Affiliate disclosure (maker's + referrer's duty; platform surfaces it).** The verified-taste-maker tier and any compensated curation must carry clear, conspicuous affiliate disclosure (FTC endorsement guides, 16 CFR 255) — already required by the §7 taste-maker guardrails. The platform's job is to **make disclosure automatic in the UX**: label a disclosed-affiliate pick distinctly from a maker's reputation-staked peer vouch (reciprocal/reputational, not cash-compensated), so the buyer can tell sincere vouch from paid referral. Honest labeling here is a moat property, not just a rule — the whole anti-retail-media stance depends on the buyer seeing the difference.
- **The pre-order / 30-day delivery rule (maker's duty; platform UX eases it).** Commitment commerce *is* taking money before delivery, which squarely triggers the FTC **Mail, Internet, or Telephone Order Merchandise Rule** ("the 30-Day Rule"): the seller must ship within the stated time — or within 30 days if none is stated — and on delay must give the buyer notice and a right to cancel for a prompt refund. This is the **maker's** obligation (maker is seller / MoR), but the commitment-commerce engine is uniquely positioned to make compliance the path of least resistance: **require a stated fulfillment window** at drop/pre-order creation, surface it to the buyer at commit time, **prompt delay notices** when a window slips, and support one-click cancel/refund. Compliance-by-design as a product feature — the platform eases the duty without assuming it. (This is also the legal spine of the §10 "verified maker collects pre-orders and ghosts" failure mode: the 30-Day Rule is what a ghosting maker *violates*, and the platform's notice/refund machinery is the buyer's first recourse before any chargeback.)
- **Handmade-claim substantiation (platform architecture already answers it).** "Handmade," "original," "made by this person" are advertising claims subject to FTC substantiation; an unsubstantiated claim is a deceptive practice. The **per-item provenance system (§7) *is* the substantiation mechanism** — self-attested classification, audited by the sampling audit + buyer reporting, shown as a buyer-visible badge, with misclassification a verification-revocation trigger. The trust architecture the moat already requires doubles, exactly, as claim-substantiation infrastructure — a place where the product-defining feature and the compliance obligation are the same build. (OHM *value* / *dignity*: the truthfulness of "handmade" is a value claim about the maker's work, which is why it is load-bearing both legally and morally.)
### Privacy
Recap the §7 consent architecture, now read as the privacy-law posture.
- **Two consent domains, two consent layers, source-of-truth in the maker's ESP.** Maker-originating marketing lives in the maker's ESP (authoritative); network-originating communication consent the network owns; the maker decides store participation and the buyer decides cross-network recognition (§7, "Customer ownership, consent & martech"). This separation isn't only good product design — it is what keeps each personal-data flow attributable to a lawful basis and a controller.
- **DPAs.** Where the network processes personal data on a maker's behalf (catalog sync, ESP push, the dashboard cache, the buyer feed) it acts as a **processor** and needs **Data Processing Agreements** with makers, plus back-to-back DPAs with its own sub-processors (ESP, hosting, the Connect/BaaS rail). Stand the DPA chain up at onboarding, not after a buyer asks.
- **Build to the strictest state law, not a 50-state matrix.** Rather than tracking divergent regimes feature-by-feature, build to the **strictest common denominator** — CCPA/CPRA plus the newer comprehensive state laws (and GDPR the moment EU buyers appear) — and apply it everywhere: real consent capture, access/deletion rights, opt-out of "sale/sharing." The cross-maker identity graph is the privacy-sensitive surface, and it is **opt-in by design** (§7) — so the architecture is *already* aligned with the strictest "no sharing without affirmative consent" reading, rather than retrofitting opt-outs onto a default-share. The OHM *consent* RFC is canonical for what "consent" must mean across these surfaces — cite it; don't re-derive a local definition.
### Freedom-to-operate / patent
- **Low-novelty mechanics → low patent-thicket risk.** The commitment-commerce primitives (scheduled drops, pre-orders/deposits, raffle-as-allocation, clubs/memberships, referral links, cross-merchant attribution) are widely practiced, decades-deep mechanics with abundant prior art. The novelty is in the *combination and positioning*, not in any patentable mechanism — so the risk of a blocking patent thicket over the core build is low.
- **Do a basic FTO check anyway.** Before building a headline feature, run a basic freedom-to-operate search — particularly for anything resembling a specifically-patented method (one-click-style checkout flows, specific loyalty/attribution or pledge-management methods). Cheap insurance against the rare narrow patent; not a reason for alarm.
- **Transparency doubles as defensive prior art.** The radically-transparent / open-books posture (§7 entity) means the design is *published as it is built* — which is **defensive publication**: dated prior art that makes it harder for anyone (including a well-funded incumbent) to later patent the combination and assert it against you. The transparency that serves the verification moat pays a second dividend in patent defense — one posture, two protections.
### Novelty / competitive finding
*(Restored — this finding didn't survive the generalization from the miniatures memo and belongs here.)* The honest competitive read: **the components all already exist** — cross-merchant inclusion (Shopify Collective, Carro), pre-order/drop tooling, affiliate/referral networks, verification badges, non-profit governance — but the **specific combination is novel and unproven**: verified per-item provenance + reputation-staked cross-maker referral + native commitment-commerce + non-profit/transparent governance, scoped to one dense vertical. **The moat is positioning and governance, not patents.** Do not expect IP to defend the position; expect the defense to be community standing, the rooted trust graph (§7 verification), the no-walled-garden value rule (Appendix D), and a 501(c)(3) structure a commission-optimized incumbent structurally cannot copy without betraying its own customers (§7, "Why this is the defensible core"). This is the same truth the spine states — *the components exist; the combination is novel but unproven* — carried into the legal lens: novelty here buys no monopoly, so the work is to make the *combination* hard to replicate by other means.
### Entity structure / UBIT
- **The 501(c)(3) path** (§7, "Entity structure & trust positioning"): a true non-profit that legally cannot be sold or distribute profits — which is what converts the anti-Etsy promise from a pledge into a structural guarantee. The legal work here is *formation*: exempt-purpose drafting, governance documents, state charitable registration.
- **The UBIT tension — flag for nonprofit counsel.** A 501(c)(3) that earns **platform fees and referral fees** is earning income from a trade or business regularly carried on — which raises **Unrelated Business Income Tax (UBIT)**. The crux is whether that fee income is *substantially related* to the exempt purpose (e.g. sustaining independent makers / a charitable-educational mission) or is merely a commercial activity that happens to fund it. Get it wrong and the exposure ranges from UBIT liability on the fee revenue to — if commercial activity comes to *dominate* — jeopardy to the exemption itself. This is the **one place the non-profit choice creates legal complexity rather than dissolving it** (the mirror image of the money-flow stance, which dissolves complexity), and it is genuinely unsettled at this memo's altitude — so it is an early, explicit **flag for specialist nonprofit/tax counsel**, who may reshape the exempt-purpose framing, structure the fee-earning activity to stay "related," or recommend a taxable subsidiary for the commercial layer. Surface it in §8/§9 diligence rather than discovering it post-formation.
**The through-line, restated.** The pattern of this whole section is one shape: **where the architecture stays out of the money flow, the legal burden largely dissolves** — MTL, marketplace-facilitator tax, and MoR liability are all discharged by the single choice that the maker, on the maker's own processor, is merchant of record. What remains are the exposures that *aren't* a money-flow question — and each gets handled in kind: **engineer it down** (consideration out of the raffle; compliance-by-design pre-order UX; provenance-as-substantiation; opt-in privacy aligned to the strictest law) or **flag it for counsel** (UBIT, paid-entry raffles, per-state facilitator confirmation before Phase 3). The legal strategy is not separate from the architecture — **it is the architecture, audited.***Flag and verify — not legal advice.*
---
## 12. Sustainability economics & health metrics
The memo is deep on architecture and silent on whether the architecture pays for itself. That silence is the dangerous kind: ventures rarely die of a bad money-flow diagram, they die of a cost base no one modeled. Two questions sit under "is this sustainable," and they are different questions. **Does the fee model cover the cost base, and at what scale?** — the unit-economics question. And **is the network actually working?** — the health/liquidity question that turns the §9 gates from enthusiasm-readings into instruments. Both rest on the same asset: the cross-merchant order history the network already holds to compute referrals (§7, "Storefront architecture & Shopify coexistence"), which is *uniquely* able to see across stores. The *unit-economics* numbers here are deliberately left as variables — n = 2 can't calibrate them (§4) — because the contribution this section makes is the *model and the instruments*, not invented values; the **market-sizing anchors** added below are the one deliberate exception, since external market structure is publicly knowable rather than an uncalibrated internal variable. This whole section turns on OHM **value** (the metric must track *earned* value, not gamed volume) and **trust/recourse** (the trust guarantee is only as good as the funded reliability behind it); where it names one, the canonical RFC governs (top-of-file note).
### "Non-profit" is not "needn't cover costs"
The 501(c)(3)/volunteer/transparent structure (§7, "Entity structure & trust positioning") changes *who keeps any surplus* — no one; it cannot be distributed — but it does **not** change the arithmetic that revenue must meet cost or the org folds. Exemption is not exemption from a budget. The structure's funding-viability rested on one specific claim: the dominant historical cost center, engineering, has been deflated by LLMs (§7) — the entity and the opportunity are the same bet. But "deflated" is not "zero." The reliability core (network service, ledger, verification) needs *sustained* funding, not best-effort volunteer cadence (§4), and that floor is a real recurring cost the fee model must carry.
- **There is a ceiling as well as a floor — the §11 UBIT band.** The mirror of "must cover costs" is "must not look like a commercial marketplace wearing a non-profit badge." A 501(c)(3) earning platform and referral fees raises Unrelated Business Income Tax exposure unless that income is *substantially related* to the exempt purpose, and if commercial activity comes to *dominate*, the exemption itself is in jeopardy (§11, "Entity structure / UBIT"). So the sustainable target is a **narrow band**: enough fee revenue to fund the reliability core off bus-factor-one, framed as sustaining the exempt mission — not so much, or so commercially-shaped, that the org reads as a marketplace that incorporated as a charity. Cost-coverage and UBIT pull from opposite sides onto the same number.
- **The discipline §7 names, applied to the numbers.** "Transfer the rigor you'd spend on fundraising onto volunteer sustainability" (§7) has a quantitative edge: a non-profit that cannot model its own break-even is already exhibiting the volunteer-org failure mode — dying of *sustaining*, not *building* (§4). Modeling it is the rigor; the model below is the minimum form of it.
### Unit economics — does the fee model cover the cost base?
Per the decision above, this is a **parametric** model: the fee *rates* are design parameters fixed in §7 ("How the platform gets paid"); the volumes and costs are named variables, because the honest values don't exist yet (§8 discovery and the first dozen makers are what populate them).
**Two revenue lines, both from §7.**
- **Subscription.** Cold-start makers pay Starter (≈2–4% of captured GMV, no/low monthly); at scale they auto-graduate to Pro (flat **$29–49/mo**, 0%). The flat Pro fee is the *predictable* margin; the Starter percentage is cold-start-friendly but thin on low-GMV makers.
- **Referral spread.** On a referred order the platform takes a **fixed ≈3–5% spread** (the network's referral revenue line), and Maker A earns a **negotiated reward above it** (§7, "Referral economics"). The spread is the platform margin modeled here; A's reward is a *non-cashable draw against A's own future platform fees* — so it is **foregone future fee revenue**, not free money. The model must net it: referral activity generates spread *and* erodes subscription/fee revenue as credits are drawn. Treat the credit as a cost line, not a wash.
**A note on partner-network splits.** Where a maker pays a partner out of its earned referral income (§7, "Partner / consultant network"), the split **redistributes the maker's curator income, not the platform's spread** — the platform stays principal on both legs and its 3–5% margin is unchanged. So partner comp does not move the platform's break-even directly; it is **maker-borne activation cost, paid from the upside**, that lowers the friction of turning a maker into an *active referrer*. Model it as a driver of the referral-activation rate (and thus of the North Star, below), not as a platform cost line.
**The cost base — three buckets** (the §4 / launch-prompt decomposition).
1.**Network-service hosting.** The cross-tenant moat service is hosted *separately, always* (§7, "Hosting"); the per-maker storefront cost is largely the maker's own (their processor, their Medusa/Shopify). Mostly a fixed base with mild per-maker/per-order scaling. The §7 pilot (GCP Cloud Run + Cloud SQL, low tens of dollars/month) is the *floor* of this term — and the trap is mistaking that floor for the whole of it (below).
2.**Verification labor.** The human cost of the trust gate — staff-verifying the seed/root set early, then the sampling audit, ring-detection, and revocation handling as peer verification scales (§7, "Verification"; §10). Scales with maker inflow and audit volume; the part that needs reliability cannot be best-effort.
3.**Reliability core.** The funded floor that keeps buckets 1 and 2 *plus the ledger* off bus-factor-one (its own subsection below). This is the line item the cloud invoice does not show, and the one most likely to be under-modeled.
**The break-even shape.** Let N be active makers, with per-maker net contribution m (subscription, plus referral spread, *minus* drawn credits, netted across the Starter/Pro mix), and a cost base C = F + v·N where F is the fixed reliability-and-base term and v the marginal per-maker cost (incremental verification + hosting). Break-even is the familiar fixed-cost-coverage form:
```
N* ≈ F / (m − v)
```
Two things fall out of the *shape*, no values required:
- **This is a fixed-cost-coverage problem, not a margin problem.** Each maker contributes a small but positive m − v (mostly the subscription; the referral spread is thin and partly self-cancelling via credits). The question is therefore not "is a maker profitable" (yes, modestly) but "**how many modest contributions fund the reliability floor F**." That directly *reframes the §9 dozen-maker gate*: a dozen makers validates **demand**; break-even is a larger N governed by how lean F is kept (the §7 LLM-deflated-cost bet is precisely the bet that F is small) and how much per-maker margin the tier mix yields.
- **N\* falls as makers *grow* and *refer*, not merely as they're *added*.** A network stuck on cold-start Starter percentages at low GMV barely moves m; break-even improves as makers graduate to flat Pro (margin firms up) and as referral activity lights (spread revenue). So the two levers that move N\* most are **F** (keep the reliability core lean — the §7 bet) and the **Starter→Pro graduation + referral-activation mix** (raise m). Adding low-GMV, non-referring makers moves break-even the least.
**An illustrative pass — the *shape*, not validated numbers.** To see what the formula implies, fix the variables at plausible midpoints — average active-maker GMV `G` = $30k/yr, Starter take 3%, Pro $39/mo, referral spread 4% — and let the Pro-tier mix and referred share `ρ` mature as the network lights:
| Makers `N` | on Pro | referred `ρ` | Pro fees | Starter % | Referral spread | **≈ revenue/yr** |
Two readings fall out, both reinforcing the parametric conclusions above. The revenue **mix flips with maturity** — ~90% thin Starter percentage at the §9 gate, but the Pro flat fee and the referral spread carry it by density and beyond (the *graduate-and-refer*, not merely *add*, point). And against a lean reliability floor `F` ≈ $75–150k/yr (the funded core ops + ledger + verification audit + hosting), break-even lands somewhere around **~150–300 makers** under these midpoints — **well past the dozen-maker §9 *demand* gate.** The dozen validates demand; sustainability is a later, larger N, and that gap is exactly the thing this section exists to name.
**The honest caveat (memo voice).** These are the variables, not values: n = 2 cannot calibrate per-maker GMV, the referred-GMV share, churn, or graduation rate. Naming the model is the point — and the §9 gate should start **instrumenting** the inputs (per-maker GMV, referred share) so that break-even stops being unknown by the time the dozen-maker gate is cleared. The same order-history asset that powers the metrics below makes every one of these variables measurable per maker (§7) — the model and the instruments are the same build.
### Market size — count makers, not craft-market GMV
The memo asserts *TAM = every maker* (§7, "Business model") but never sizes it. The sizing discipline that matters: **the unit of TAM is makers, not the dollar size of the craft market** — because revenue is per-maker subscription + referral spread, never a GMV take (§7). A roughly **$0.8–1.2 trillion** global handicrafts market ([Fortune Business Insights](https://www.fortunebusinessinsights.com/handicraft-market-108435)) is a category-scale backdrop, *not* our revenue base; counting *makers who run commit-then-make* is the honest denominator. And note the category distinction from the parametric caveat above: external market structure is publicly knowable, so unlike the *unit-economics* variables (per-maker GMV, churn — calibrated only by discovery), these are **researched anchors** — but anchors are proxies and ranges, not point truths.
- **TAM — every independent maker who runs commit-then-make.** Federation makes the addressable supply *the entire controllable-storefront + marketplace install base* (§7, "Strategic payoff"), not just makers willing to switch: Shopify reports ~4.8M active merchants (~2.5M live storefronts — [cropink](https://cropink.com/how-many-shopify-stores-are-there)), and Etsy ~5.6M active sellers — *down from ~9M in 2023* as it purged for quality ([Marketplace Pulse](https://www.marketplacepulse.com/stats/etsy-number-of-active-sellers)), which is the authenticity reckoning this thesis rides on, expressed as a number. Not all of these run commit-then-make; the true TAM is that subset — unknowable precisely, but **millions of makers, not thousands**.
- **SAM — commit-then-make-native makers, reachable community-by-community.** The model only works where you show up as a member (§5), so the serviceable market is *summed over verticals*, not addressed at once. The beachhead (tabletop minis/dice, Appendix A) sits in a **~$3.8–4.2B/yr tabletop-miniatures market growing ~7–10%/yr** ([DataIntelo](https://dataintelo.com/report/tabletop-miniatures-game-market)); the relevant maker population is the independent casters/sculptors/dice-makers running drops and clubs. Patreon's **~286k paying creators** ([Backlinko](https://backlinko.com/patreon-users)) is a usable proxy for the *commit-then-make creator* population across all verticals — tabletop is one slice, and SAM grows dice → broad tabletop → adjacent craft scenes.
- **SOM — left parametric, by design.** This is deliberately *not* a top-down "capture X% of a $Y market" number — that is exactly the fiction the "variables not values" discipline refuses. The obtainable near-term market is governed by the break-even `N* ≈ F/(m−v)` above: clear the **dozen-maker §9 demand gate** in one community, reach **break-even density (~150–300 makers under the illustrative midpoints)**, then compound vertical by vertical. The honest SOM story is *reach self-sustaining density in one scene, then repeat* — not a share of a giant pie.
### Network-health & liquidity metrics — instrumenting the §9 gates
The §9 gates are all qualitative — *do makers refer you? is the pain consistent? do they have audiences? can you reach a dozen?* Those are the right questions, but the network's success is fundamentally a **liquidity** outcome (§4: curation fights liquidity, and the graveyard is full of platforms that had supply and no demand). Liquidity needs liquidity instruments.
**North Star: the share of GMV that is cross-maker-referred.** This is the one number that is near-zero for a pile of disconnected storefronts and rises *only* as the referral network actually does work. A storefront-only success — a genuinely good commitment-commerce tool that never becomes a network — shows a **low North Star**, which is exactly the most-feared failure mode (a good tool that never lights the moat, §4/§5). It measures "the network is the product" (§7, "Business model") directly, in a single figure, in a way no vanity supply count can fake.
**The leading indicators beneath it** — the funnel that *predicts* the North Star, earliest-first:
- **Follower growth** — the §2 flow asset (drop-followers accumulating across makers, the embryonic cross-merchant identity graph). The leading-most signal: follows precede referred GMV by definition.
- **Curated-By activation** — the share of verified makers who actually *vouch*, and the breadth of their curation. Referred GMV cannot exist without curators curating; a network rich in follows but where makers don't vouch is still dead.
- **Drop sell-through** — the commitment-commerce engine's own vitality (do drops clear?). The tool-layer health the network rides on; a stalling engine starves the network upstream.
- **Repeat-buyer rate, especially cross-maker repeat** — demand durability, and whether the buyer-side keystone (§13; §8) is real. A buyer who returns *across* makers is the network effect made visible at the buyer level.
**Mapped onto the §9 gates, making each quantitative:**
- *"Do makers refer you?"* → Curated-By activation + referred-GMV share (the North Star itself).
- *"Do target makers have audiences?"* → follower growth (and the §8 "an audience they'd bring" question, now a number).
- *"Consistent pain / a dozen who want the same thing?"* → drop sell-through + Starter→Pro graduation rate.
**The order-history asset computes all of this for free.** §7 already commits it: *"One asset, three uses — the same order history powers the referral ledger, the network-health metrics, and this reporting."* The cross-tenant vantage is the only place cross-maker-referred GMV and cross-maker repeat *can* be computed — no single-store tool sees across stores (which is itself moat-deepening, §7). So these metrics are not new instrumentation to fund; they fall out of the ledger the referral system already requires.
**Goodhart caution — the metric must measure *earned* referral.** A North Star is a target, and a target invites gaming. The corrupt way to lift "cross-maker-referred GMV" is to *manufacture* referrals — pay for placement, juice the slots — which is precisely the retail-media drift §3 and §7 ("Curated By This Maker") exist to forbid. The North Star is only valid as a measure of **reputation-staked, earned** cross-referral; optimized the wrong way it rebuilds Etsy's pollution from the inside, through the dashboard. This is the OHM **value** point in metric form: the number must track real value to buyers and makers, not gamed volume — so pair the North Star with the §7 anti-corruption guardrails (structural ranking-neutrality — the platform's spread is constant, so its algorithms ignore referral economics; capped per-maker featuring; per-relationship approval; reputation on the line; uniform rates for non-maker taste-makers) rather than reading it naked.
### Volunteer-sustainability economics — funding the critical core off bus-factor-one
§4 names volunteer-core sustainability as **the single point of failure**, and §7 sharpens it: "the risk moved, it didn't vanish" — LLMs make a smaller core go further but do nothing for attrition or bus-factor. The economic question this section must answer is therefore not "what does it cost to *build*" but "**what must the fee model *fund* to keep the critical core reliable when any one volunteer leaves.**"
Start from §7's own partition of what needs reliability versus what tolerates volunteer cadence:
- **Must be funded (the reliability core).** *Network-service uptime* — drops are spiky and a storefront falling over *during a drop* is the worst possible moment for maker trust (§7, "Hosting"). The *fee/wallet ledger* — money-adjacent correctness: pending→cleared settlement, clawback, negative-balance handling (§7, "Referral economics"). And *verification* — the root set, sampling audit, ring-detection, and revocation that hold the trust guarantee, where a single polluted "verified" item breaks the guarantee for everyone downstream (§7; §10). None of these can be best-effort.
- **Tolerates volunteer cadence.** Themes, storefront nice-to-haves, non-critical features (§7). These can wait on a volunteer's Saturday; the core above cannot.
So the model's job is to fund *enough* of that reliability core that it **survives any single departure** — concretely, that the fixed term **F is not modeled as pure cloud cost.** The seductive error is to set F to the §7 pilot's tens-of-dollars-a-month GCP bill; the honest F also includes **compensated, documented, more-than-one-deep ownership** of network-service ops, the ledger, and the verification audit. Under-modeling F is exactly how an org clears break-even *on paper* and still dies of bus-factor — the volunteer-org killer §4 warns about, expressed as an accounting omission. "Bind with structure, not promises" (the spine) applied here means the reliability core is **funded, documented, and redundant by design** — not hoped for.
- **The UBIT mirror is favorable here (§11).** Paying core maintainers from fee revenue is ordinary non-profit operation (reasonable compensation for exempt-purpose work), and funding the *mission's reliability* is far more defensibly "substantially related" to the exempt purpose than accumulating surplus would be. So the sustainability framing actually *helps* the §11 UBIT posture rather than straining it — fees fund the exempt-purpose reliability core, which is the cleanest story to tell counsel. (Still a flag for specialist nonprofit/tax counsel, per §11 — but a flag that points toward "related," not away.)
- **This is the trust moat's operating budget — OHM *trust/recourse* made economic.** The buyer's trust guarantee (verification and the §10 accountability machinery) is only ever as strong as the funded reliability behind it; an under-funded verification audit is a trust promise the org *cannot keep*, and a ledger run on best-effort is recourse the org cannot honor. Sustainability economics is therefore not a separate concern bolted onto the moat — it *is* the moat's budget line. Defer to the relevant OHM RFCs for *trust*, *value*, and *recourse*; where a load-bearing one is undefined, defining it is itself OHM work (top-of-file note).
### The through-line
"Non-profit" raises the bar on cost discipline rather than lowering it: the org must cover a cost base whose **dominant term is the reliability floor under the trust moat**, fund it off bus-factor-one, and do so inside the §11 UBIT band (related, not dominant-commercial). The unit economics is a **fixed-cost-coverage** problem — `N* ≈ F / (m − v)` — governed by how lean the LLM-deflated core stays and by makers *graduating and referring*, not by per-maker margin or by adding low-GMV makers. The health metrics turn §9's qualitative gates into instruments around a single North Star — **the share of GMV that is cross-maker-referred** — fed by follower growth, Curated-By activation, drop sell-through, and cross-maker repeat, and they fall out of the §7 order-history asset for free. The numbers are still variables (n = 2 cannot calibrate them); the deliverable is the **model and the instruments**, so the §9 gate can start populating them. And the line a sustainable non-profit under-funds at its peril is the one the trust moat rests on — so bind it with structure: **the reliability core is funded, documented, and more than one person deep.**
---
## 13. Demand strategy & buyer-side go-to-market
The memo names demand as the unvalidated keystone everywhere — *the binding constraint* (§4), *earn into the marketplace* (§5), *the unvalidated keystone is demand, not technology* (the spine) — but never attempts a plan; everything concrete is supply-side. This section is that plan, carried to the depth the memo's own logic supports: a buyer-side value proposition stated as its own thing, where buyers actually come from, the content/community posture, and the §8 extension that tests *demand* rather than supply. It is the most consequential section because it is the keystone — and it remains, by construction, the **least validated**: the §8 interviews tested the supply/storefront-convenience layer, not this. The deliverable is the strategy and its test, not a claim that demand is proven. The section turns on OHM **trust** and **value** (the buyer's reason to return must track *earned* value, not manufactured engagement); where it names one, the canonical RFC governs (top-of-file note).
### The buyer value proposition — a three-pillar stack, not three claims
The buyer-side "why" is not one reason but three, each doing a different job in the funnel; the discipline is to say what each is *for*, never to lead with all three flatly (a value prop that leads with everything leads with nothing):
- **Authenticity / provenance — the precondition, not the magnet.** The floor that makes everything else safe. The per-item provenance badge and verification (§7) are the thing a buyer *cannot* get on a polluted Etsy, and the signal **appreciates** as AI-generated and recast fakes proliferate (§3). It is the advertised trust guarantee and the grievance-content angle — but trust is a tiebreaker/enabler, not a thing buyers wake up wanting. In the dice/miniatures beachhead (Appendix A) it runs *hottest*, because recasting is literal piracy there; the weighting across the three pillars is therefore community-dependent.
- **The fan relationship — the acquisition-and-retention engine.** Commitment commerce, from the buyer's side, is *being a fan*: following a maker, waiting for the drop, joining the club, holding insider status. This is why the buyer is present at all (they follow a maker) and why they return (the cadence) — the §2 asset of "people who *wait for* makers and commit ahead," seen from the buyer. It is the pillar word-of-mouth carries and the one the beachhead's density compounds.
- **Trusted discovery — the compounding mechanism.** "Makers I trust point me to makers I'll love" — Curated-By (§7) as the buyer experiences it. This is the §12 North Star (cross-maker-referred GMV) made human, and it is the *growth lever, not the entry hook*. Hard rule inherited from §7: it is framed as *emerging from makers the buyer chose to follow*, **never** as the platform performing discovery. Leading with discovery-as-destination is the curation-vs-liquidity graveyard (§4/§5) and violates *maker-as-discovery-engine, platform-as-pipe* (the spine).
### Buyer surface & the "come back" mechanic — phased like the rest
Mirror the §7 unified phasing — the buyer surface appears late and stays deliberately thin:
- **Phase 1 — invisible / maker-fronted.** Buyers transact as guests on the maker's own storefront; attribution is stateless (§7), so no buyer identity exists yet. "Come back" runs entirely through the *maker's own* channels — the maker's ESP / IG / Discord "next drop" notice (§7, martech). The platform's only retention role is powering follow/notify; it has no buyer-facing surface and needs none.
- **Phase 2+ — the soft destination.** The buyer-facing feed (§7) becomes an *opt-in* surface — "your makers, in one place" — with a light identity buyers return to, every item still traced to a follow. This is a retention **upgrade** layered on the maker's own channels, not a replacement, and pointedly **not** a buyer-facing *brand* a buyer evangelizes ("I shop on X") — that is the marketplace-destination posture §5/§7 reject. The platform earns a thin buyer-facing presence; it never becomes the buyer's primary relationship.
### Where buyers actually come from
The conclusion forced by *platform-as-pipe* (§7) and *demand must be earned, not bought* (§4): **buyers do not arrive at the platform; they arrive at makers, and the network compounds them.**
- **The first ~100 are activation, not acquisition.** They are the founding (invited — §7) makers' *existing* audiences, transacting on the new rails. The platform acquires no one; the test is whether a maker's existing fans will follow them into a drop here. This is precisely why an audience-having maker is an asset and an audienceless one is a cost (§8) — restated as a buyer-acquisition fact.
- **The first ~1,000 come from compounding plus supply.** Two engines: cross-maker propagation (a buyer who follows A discovers and follows A's Curated-By makers — the §12 cross-maker-repeat indicator), and more makers onboarding, each bringing an audience. Word-of-mouth inside the one tight beachhead (§5) is the multiplier — the reason density, not breadth, is the correct cold-start move.
- **Net-new demand is deliberately deferred — and named, not hidden.** Everything above is *reshuffle and deepening* of audiences that already exist; the buyer feed is **by design** weak at net-new reach (§7). The two net-new hedges are scheduled, not early: **verified taste-makers (Phase 2)** are the genuine net-new-demand engine — community voices who bring *their* audiences (§7) — and **AI shopping agents (Phase 2+)** are net-new reach (§3, §7). Early demand is therefore honestly a reshuffle; pretending otherwise is the graveyard's mistake (§4). *Concede the timeline, not the moat* (§8).
### Content, community & SEO posture
The §5 *member, not vendor* principle applied to demand — and an explicit rejection of the marketplace-SEO play:
- **Embed in the beachhead's existing hubs; don't broadcast.** Show up inside the tabletop Discords, subreddits, painting forums, and conventions as a member of the scene (§5) — the same standing that recruits makers recruits buyers.
- **Maker-amplified, not platform-voiced.** The platform's owned content surface is the network digest (§7, network marketing channel): followed makers' drops plus their Curated-By picks, aggregated and personalized but never platform-injected. Buyer-side SEO accrues to *makers' own* verified-provenance product pages, not a marketplace landing page — competing with Etsy/Amazon on generic "shop handmade" search is unwinnable and off-strategy (the discovery war §7 declines to fight).
- **One native editorial voice: the authenticity grievance.** "How to spot a real cast," provenance explainers, the anti-recast / anti-AI-slop story — community-native in the beachhead, doubling as SEO and values signaling. Plus the **verified badge as a portable trust mark** makers display wherever they already are (their IG, their leaving-Etsy posts), pulling buyer awareness back to the verified graph.
### The §8 extension — test demand, not supply
§8 discovery talked only to makers, and the two interviewed were *greenfield, with no audience* (§8) — so it tested the supply/storefront-convenience layer and **could not test the demand moat at all** (you cannot measure "do a maker's fans follow them here" with makers who have no fans). The buyer-side extension must therefore:
- **Recruit audience-having makers specifically** — a different discovery target from the greenfield on-ramp. The demand moat can only be probed where an audience exists to move.
- **Test behaviorally, not by survey** (§8's *weight what makers do over what they say*, carried to buyers): run a real instrumented drop; run a Curated-By referral between two makers and measure click → follow → buy **propagation** (the keystone network assumption, made measurable); measure provenance's effect on willingness-to-pay / switch; track repeat and cross-maker-repeat (§12).
- **Avoid the Shop Pay measurement trap (§8).** Don't ask buyers what they'd value — measure the driver: the repeat-fan vs. first-time-stranger revenue mix, and whether buyers already carry a recognized cross-merchant identity.
- **Feed the §9 gates and §12 instruments.** These tests populate the very inputs §12 said the dozen-maker gate should start instrumenting (per-maker GMV, referred share, repeat rate) — the demand strategy and the health metrics are the same build, validated together.
### The through-line
The keystone, finally grappled with rather than admitted: **buyers arrive at makers, and the network compounds them** — so the value prop is a three-pillar stack (authenticity the precondition, the fan relationship the engine, trusted discovery the compounding), the surface stays maker-fronted and only *softly* a destination, net-new demand is honestly deferred to taste-makers and agents, and the §8 extension tests it **behaviorally, with audience-having makers, before the platform is built.** It is the most consequential section and remains the least validated — by design, that is the next thing to *earn*, not assume.
---
## 14. Open sections to develop (backlog)
This memo is deep on the architectural/strategic axes (money flow, network mechanics, moat theory, consent) and thin on several operational ones that matter as much or more. The gaps cluster on the un-fun, operational side — which is usually where ventures actually die. Each below is a separate future session. (Trust & safety, legal & compliance, sustainability economics & health metrics, and demand strategy & buyer-side go-to-market were written up in prior sessions — now §10, §11, §12, and §13 — and have left the backlog. Concrete MVP scope, the build roadmap, and the data-model sketch are intentionally *not* tracked here: this is a **strategic memo, not a roadmap/rollout doc** — those belong in the implementation plan the strategy feeds, not in the strategy itself.) Rough priority order; with the demand keystone now drafted (§13, still to be *validated* via its §8 extension), the **live threads** are §10's open reputation-engine work (gathered in that section's last subsection) and the governance mechanics below (#1) — whose *direction* (progressive delegation to network representatives; §7/§10) is now set, but whose machinery is deliberately deferred.
1.**Governance — progressive delegation (direction set; mechanics deferred).***Direction set:* a **layered hybrid**. The non-profit (its board, with fiduciary duty) retains the **legal floor and the entrenched core** — the trust guarantee, non-extraction, the no-walled-garden value rule, the out-of-flow stance — which *bind with structure*, not a changeable majority (a 501(c)(3) cannot sell or distribute them — §7). Authority over **maker issues** (verification standards, the provenance line, the §10 standing thresholds — §7, §10, §14 #2) is **progressively delegated to representatives of the network as it scales beyond what the non-profit can manage**, on the same *start-closed, open-as-the-trust-web-earns-it* phasing as the membership gate and peer verification (§7): founder/staff-led at launch, delegated as density demands. The vision is **network self-governance for maker issues, modeled on a functioning democracy**: members *elected* to network roles — dispute-resolution among them — where **holding and discharging a role well is itself a way to earn standing**, the same reputation currency as making and vouching well (§10's positive-reinforcement model). It is also how the org *scales* without the volunteer core adjudicating every dispute (§12). *Still open — and deliberately not fleshed out now:* what those representative bodies are and how they're constituted, how delegation resists capture (the §7 verification concern applied to governance itself), and the concrete appeal/dispute machinery (the §10 governance-appeal-path home). Over-specifying a governance apparatus before the community exists would be premature; the direction is set, the machinery is later work. (Also the body that stewards the §12 UBIT band.)
2.**Hybrid makers — the making-vs-reselling line (standard).***Direction set:* provenance attaches **per-item, not per-maker**, via a self-attested, buyer-facing catalog classification (Original / Original + components / Resale – fellow Maker / Resale – third-party), with trust-surface eligibility keyed to it — see §7 "Per-item provenance: the catalog's originality layer." *Still open:* the precise, **auditable line between making and reselling** — purchased supplies don't taint "original," but where exactly do finishing, assembling, and kitting fall? — plus the enforcement/audit hook (ties to §10 accountability) and the exact buyer-facing label wording. Interacts with the consignment/resale "avoid" fork (§7) and the no-walled-garden value rule (Appendix D).
3.**International tax & cross-border operation (US-only today — flag for specialist counsel).** §11's analysis is entirely US (the *Wayfair* facilitator test, MTL, FTC). But the beachhead is **STL/digital-file-heavy and globally distributed** (UK/EU/AUS casters), so this is a *live* hole, not a someday: **EU/UK VAT on digital goods** (OSS/IOSS — VAT owed in the buyer's country from the first unit) and the EU **"deemed-supplier"** marketplace rule, which can pull a *facilitating* platform into VAT collection on logic that **does not mirror** the US "we fail prong 2" defense — so the out-of-flow stance does not automatically transfer abroad. Adjacent: **PSD2/SCA** on EU recurring club billing (the maker's processor must handle it; a "Standard account" doesn't discharge it), multi-currency display/settlement, and **KYC/AML/OFAC** onboarding for non-US makers/taste-makers on the Phase-2 cashable rail. *Direction: scope which jurisdictions Phase 1 actually serves, and put the VAT/deemed-supplier question to specialist cross-border counsel before international participants are first-class. Flag and verify — not legal advice.*
4.**Information security & breach posture for the cross-tenant network service.** §7/§11 cover privacy *consent* thoroughly; neither covers *security*. The shared network service holds the single most attractive breach target in the design — **every maker's full order history + buyer PII + the cross-maker identity graph** — and for a *trust* brand a breach is existential, not merely costly. Still open: encryption at rest/in transit + key management, tenant-isolation and least-privilege access to the cross-tenant store, secrets handling, and an incident-response / breach-notification plan (state laws + the GDPR 72-hour clock). *Direction set here: infosec of the network service belongs in the §12 **funded reliability core** alongside the ledger and the verification audit — a trust-moat budget line, not a volunteer-cadence nice-to-have; the concrete controls are later work.*
5.**Content moderation beyond authenticity (third-party IP / DMCA / prohibited goods).** Provenance verifies *handmade*, not *lawful to sell*. The minis/tabletop beachhead carries a heavy **third-party-IP/DMCA** load (fan-sculpts of others' IP; the Games Workshop takedown culture), plus counterfeit, regulated, and offensive-content surfaces — and the network *amplifies* whatever it surfaces (Curated-By, the buyer feed, the agent feed), so it inherits **amplification / contributory liability** distinct from "is it handmade." Still open: a DMCA §512 notice-and-takedown posture + designated agent, an IP-complaint / repeat-infringer policy, and the line between *verified original craft* and *originality of the depicted IP* (a verified maker can still infringe). Interacts with verification (§7) and accountability (§10). *Flag for counsel; design the takedown path before the agent feed amplifies at scale.*
6.**Verification methodology — the evidentiary act (currently treated as a primitive).** §7 specifies the verification *graph* (rooted, staked, multi-vouch, sampling audit) and §10/#1 above defer the reputation *engine* — but **how a verifier actually establishes that a human makes original work** (what proof, what process, what staff and peers inspect) is neither specified nor flagged, and it is the literal foundation of the trust moat and the §11 FTC-substantiation claim — the hard adversarial core in an AI-fake world. Still open: the **provenance-documentation standard** (studio evidence, work-in-progress, live demo?), the staff seed-set method, and what a peer verifier must attest. *Name it as load-bearing open work, not a solved primitive.*
7.**Support & dispute operations — the function and its cost.** §12 funds the reliability core (uptime, ledger, verification audit) but never a **support/ops function**: maker tickets (a broken sync at drop time), buyer-harm report intake, and the verification-revocation / appeal queues (§10). For a volunteer-built, money-adjacent, trust-critical platform this is a real recurring **F-term omission** and an operational-credibility question. *Still open: the support model, triage/SLAs for money-adjacent vs cosmetic issues, and its line in the §12 cost base.*
8.**Competitive engagement: creator-commerce tools.** The "no continuous (non-campaign) platform treats commit-then-make as first-class" claim (§2) is load-bearing and currently engages only Etsy/Shopify/Patreon/Kickstarter/Gamefound. The sharper counter-examples a skeptic raises are the **creator-commerce tools** — Gumroad, Payhip, Ko-fi Shop, Fourthwall, Lemon Squeezy — several of which already do drops + memberships + digital delivery at low fees. *Still open: a head-to-head that substantiates "first-class, not covered" against these specifically — the likely cut being that each does the storefront/transaction but none does the cross-maker reputation-staked referral network (the moat), and most treat the cadence as features rather than the spine; verify the claim rather than assert it.*
9.**Lower-priority flagged items (named, not yet developed).** (a) **cuttle.xyz / generative-tool integration** is cited as a differentiator (§2) without substance — develop what the integration is and why it's defensible, or demote it to a mere example. (b) **Catalog-sync reliability at scale** — N adapters against rented APIs (Shopify rate limits, webhook-delivery failure, deprecation cycles, reconciliation) is a chronic ops burden the moat surfaces depend on. (c) **Accessibility** (WCAG/ADA) for generated storefronts and the buyer feed — a compliance surface and an OHM-*dignity*-aligned one. (d) **Trademark / certification mark for "verified"** — a certification mark is the natural instrument to protect the badge from imitation (FTO/patent is covered in §11; this isn't). (e) **Platform wind-down plan** for the network asset — given volunteer-sustainability is the named #1 risk (§4), what becomes of the cross-maker graph, follows, buyer accounts, and outstanding wallet credits/payables if the org folds. (f) **Team / execution capacity** — the docs argue the model is *affordable*; named team/board/recruiting capacity is a separate, unaddressed question (arguably a roadmap/ops-doc concern more than a strategy one).
---
## Appendix A — Choosing a beachhead vertical (and sequencing expansion)
The platform serves makers in general, but it must *launch* into one dense community. This is the selection method, with miniatures as the worked candidate.
**The filter.** Score candidate communities on: made-to-order/drop motion; non-fungible inventory; hybrid digital + physical; recurring drops; variant explosion; audience-having makers; authenticity grievance; scalper/counterfeit problem; a reachable community hub. The recurring finding across verticals: the storefront/build layer is already commoditized (Shopify, Fourthwall), so the prize is the **demand-aggregation / curation layer** (flow). The right target is a vertical where that layer is *unoccupied* and you can belong to the community.
**Worked example — miniatures as the beachhead.** Miniatures express every form of the commit-then-make primitive at once: recurring monthly STL/digital releases (Patreon / Cults3D model), digital delivery with licensing, *and* physical resin/metal casting that's pre-order or made-to-order, plus heavy variant explosions (scale, material, painted/unpainted) and army-builder bundles. That membership + digital + physical-preorder combination is exactly where Shopify is mediocre. The expansion scan:
| **Resin dice** | Drop culture is the *default* motion; large maker audiences; vivid authenticity grievance (cast-copies undercutting real casters); active scalper market makes queue/anti-flip valuable; drop/queue/commission infra **unserved**. | Lower price points; casting is labor-intensive; design-theft enforcement complexity. | **Open.** | **Yes — same tabletop buyer.** | **Top pick / first expansion.** Reuse minis' made-to-order/pre-order/variant/provenance primitives; add drop-scheduling, queue/raffle, anti-scalper as net-new. Compounds community density, no second cold-start. |
| **STL / digital files** | Shares minis' digital gnarl (tiered licensing, membership drops, re-upload piracy where provenance defends); huge audience. | Most contested and **consolidating** — MyMiniFactory bought Thingiverse; Cults3D, Patreon, MakerWorld entrenched. | **Owned.** | Yes (minis' digital half). | **Partner/coexist; don't build.** Own the physical + storefront + cross-maker network it doesn't touch. |
| **Hand-dyed yarn** | Non-fungible inventory (dye lots); dyed-to-order pre-orders; yarn clubs = subscription drops; variant explosion; tight community (Ravelry + IG); strong anti-mass ethos. | Shopify + apps cover the storefront; **a curated demand-aggregator already exists (Indie Untangled)**; non-adjacent buyer = full second cold-start. | **Partly owned.** | No. | **Strong-but-contested; validate first.** Best "wide" option, but probe whether the incumbent has *earned* switching-cost loyalty or merely lightly occupies the niche. |
| **Custom knives** | High value/unit; waitlist/lottery/deposit by default; secondary market makes queue integrity valuable; collector culture. | **Entrenched decades-old curated marketplaces own the flow** (Arizona Custom Knives, Noblie); blade-shipping regulatory drag; non-adjacent buyer. | **Owned.** | No. | **Deprioritize.** Dislodging earned loyalty *plus* weapons-shipping compliance. |
| **Enamel pins** | Large audiences; campaign/pre-order motion; LE secondary market; B-grade sub-market. | Largely **design+manufacture (POD), not craft**; grievance is art theft (originality), not handmade provenance; Fourthwall holds the creator-merch layer. | **Owned.** | No. | **Skip.** The product isn't really handmade, so a verified-*provenance* moat doesn't fit. |
**Strategic conclusion — deep-and-adjacent over wide.** Dice wins on every axis *and* shares the buyer, so the arc is **beachhead → dice → broad physical tabletop** — one buyer, one community, one compounding set of drop-and-provenance primitives. Yarn/knives are "wide" bets into scenes where the flow layer is already held by an embedded member — the "don't fight where someone's embedded" trap. Of the wide options, only yarn merits a validation probe before being ruled out.
---
## Appendix B — The commitment-commerce layer: incumbents & the open gap
"This feels Kickstarter-ish" is correct, and the incumbents are specific. The crowdfunding/pledge-management space is large, mature, and consolidating — but built for **episodic, project-scale campaigns**, not an individual maker's **continuous drop cadence.** That distinction is the entire opening — with one correction this appendix originally missed: there are **two** incumbent shapes, not one. The *episodic* campaign players below (Kickstarter / Gamefound / BackerKit), and — easy to miss because it doesn't look like crowdfunding — the *continuous-membership* incumbent, **Patreon**, which already serves the monthly-club primitive and sits *inside* the beachhead (its own treatment after the table). (The pattern for the campaign players: every one started as the tool managing the gap between committed demand and delivery — pledge management — then grew up into the funding layer.)
| Player | What it is | Built for | Relevance |
|---|---|---|---|
| **Kickstarter** | All-or-nothing campaign crowdfunding; no integrated pledge manager | Episodic, project-scale campaigns | The launchpad |
| **Gamefound** | Tabletop-native; pledge-manager → full crowdfunding platform with late-pledge stores | Episodic tabletop campaigns + post-campaign stores | **Sitting in your adjacent vertical**; fast-growing, Kickstarter's biggest tabletop rival |
| **BackerKit** | Pledge-manager (surveys/shipping/tax/add-ons) → also crowdfunding | Post-campaign fulfillment + campaigns | "Mission control" for fulfillment |
| **Patreon** | Per-creator recurring memberships; platform is MoR, processes the charge (~8–12% all-in), pays out | **Continuous** creator membership (the monthly club) | **The recurring-club incumbent — and it's *inside* your beachhead** (the Patreon/Cults3D model in minis, Appendix A); a sharper competitor than Shopify for the club slice, on the wrong side of three invariants — treatment below |
**The open gap (where to play):** none of these *campaign* players serve the maker running a small drop every other Saturday or a 10-piece lottery — and the **monthly club**, the one continuous-cadence slice that *does* have an incumbent, is served by **Patreon** on the wrong side of the invariants (below). The unserved space is **continuous commitment-commerce cadence** — the recurring, relationship-driven, small-batch motion *between* Shopify (continuous but stock-only) and Kickstarter/Gamefound (commitment but episodic). The recurring strategic shape (the same as the rest of this memo): there's always an entrenched incumbent owning the *episodic/distribution* layer — Shopify (stock), MyMiniFactory (file distribution), Gamefound (campaigns) — and the open prize is the *continuous cross-maker relationship* layer they don't serve. **Coexist with the episodic incumbent; own the continuous demand-relationship network.**
**Patreon — the continuous-membership incumbent inside the beachhead.** Patreon is *not* §2's stock-then-sell foil the way Shopify is: a monthly club is already *commit-then-make* (patrons commit ahead; the creator produces against it), so Patreon is genuinely doing this category for the recurring-club/membership primitive (§2, §6, §7) — and in miniatures it's the de-facto infrastructure (the "Patreon / Cults3D model", Appendix A). That makes it a *sharper-edged* competitor than Shopify for the slice it touches, and an unavoidable one: your first community lives on it. But it sits on the wrong side of three invariants at once —
- **In the money flow.** Patreon is MoR, processes the recurring charge, takes ~8–12% all-in, and pays out — precisely the thing §7/§11 design out. A native replacement must keep the maker MoR on their own processor (Stripe Billing on a **Standard account + direct charges + `application_fee`**, §7). *Recurring billing is the sharpest test of that dial*, because Patreon's whole model is "platform is MoR for a subscription" — one config-flip away, and the flip would quietly rebuild Patreon.
- **A walled garden on the buyer.** Run Patreon through Appendix D's three-surfaces gate and it scores like **Etsy, not Shopify**: you can't host a Curated-By block on a Patreon page, you can't attribute a referral through Patreon checkout, and Patreon owns the patron payment relationship. By the value rule it's an **invitation target, not an integration/destination** — "I'd feature your work the moment you own your commerce." The one federatable seam is **patron-email export → seed the maker's ESP** (§7, ESP-as-source-of-truth): billing and delivery you want native, the *list* you can lift.
- **No moat, and structurally can't grow one.** Patreon is single-creator; its cross-creator discovery is platform-performed engagement-algo — the inverse of *maker-as-discovery-engine* (§7 buyer feed) — with zero reputation-staked, attributed cross-maker referral. It won't build that, for the same *shape* of reason Shopify won't (§7, "Why this is the defensible core") but a different specific one: its business *is* the captive recurring relationship and the algorithmic discovery surface. So it contributes nothing to your North Star (§12, cross-maker-referred GMV) — every patron on Patreon is a follow you never capture into the cross-maker identity graph.
**The play is two-sided, and already latent in the sequencing (§5).***Act 1 (Tool) — out-tool it:* the engine already lists "recurring clubs/memberships" + "digital-file delivery + licensing" as primitives (§2, §6); for minis that *is* the Patreon feature set (monthly STL drop, tiered licensing, patron list). Build it **maker-MoR**, grant **usage-rights ownership of the patron** (§7 — the exact inversion Patreon doesn't offer), lower the all-in fee, and wire it into the network. (Appendix-A discipline holds: don't build a Cults3D/MyMiniFactory *file marketplace* — "partner/coexist; don't build" — but the club mechanic + storefront + network layer is yours.) *Act 2+ (Network) — out-flank it:* the cross-maker referral/feed is the durable reason a maker prefers you **even if Patreon matched the club features** — which it can't, without becoming a different company.
---
## Appendix C — Composite multi-maker kits
A kit combining products from multiple makers, sold as one SKU on a maker's storefront — the deepest expression of maker collaboration, a natural Curated-By extension, a strong "kit drop" — but it presses hardest on the one line the architecture defends: **custody of funds.** Two governing rules. For the kit creator: **be a *principal reseller* of the kit, never a *conduit* aggregating others' sales** (principal is a product; conduit is money transmission). For the platform: **coordination and bookkeeping are free; custody — funds resting in an account you control — is the line.**
### C.1 The retail model
One charge means one merchant of record and one payout destination; "one SKU, N makers, money perfectly siloed" is a contradiction.
| Model | Mechanism | Verdict |
|---|---|---|
| **1. Lead maker = MoR, others = suppliers** | A sells the kit as A's own SKU on A's processor; A owes X/Y wholesale COGS. A is a principal reseller (legitimate drop-ship/wholesale, **not** transmission). | **Recommended.** Single charge, single MoR, out of the consumer flow. The virtual-kit/BOM pattern with components from other makers. |
| **2. Curated kit, no unified checkout** | Themed Curated-By bundle; each component hands off to its own store. | Free but weak — N transactions in a bundle costume; not a true SKU. |
| **3. Facilitated split-payment** | One checkout, auto-split to N connected accounts (Connect destination charges) — Shopify Collective's mechanism. | Cleanest *experience*, but you become facilitator / in the flow. Avoid until you choose to be marketplace-of-record for kits. |
Model 1 has two physical variants: **A assembles** (components ship to A, A builds + ships one box) or **A drop-ships** (X/Y ship directly; A is still MoR and still owes wholesale). C.6 is the decisive reason to prefer assembly.
### C.2 Supplier settlement — how A pays X and Y
**Custody is the line:** the moment funds rest in an account you control and you pay them onward, you're a transmitter. "Facilitate without being in the flow" means facilitating the *coordination* (or netting on your own account as principal), never custody.
**The default stance: the kit merchant (A) handles every supplier obligation; the platform moves no money at all.** A is MoR and a principal reseller, so A owes X and Y on whatever wholesale terms they agreed and **settles with them directly, off-platform**, the way any two businesses do. The platform's role is **transparency, not transfer**: it can *notify* a supplier when their item sells in someone else's kit ("your *Frostfang Drake* sold 3× in **Hearthforge**'s 'Winter Warband' kit"), so makers see their cross-maker pull — **without facilitating any payment between them.** Notification is pure coordination (free); routing a single dollar from A to X is custody (the line). This knowingly re-weighs the peer-to-peer friction below: accept the friction (notification softens it) to keep the platform *entirely* money-free. Models B and C are then **optional conveniences a maker may elect**, never the platform stepping into the flow.
| Model | Mechanism | In the flow? |
|---|---|---|
| **A. Bookkeeper / peer-to-peer (default)** | Platform records the payable and *notifies* the supplier; A→X money moves directly, off-platform. | No — the cleanest; notification offsets the "makers chasing each other" friction. |
| **B. Net through the existing fee ledger** | X's receivable → credit in X's fee-offset wallet; A's payable → charge on A's next invoice. Principal on both sides. | No — *for the non-cashable portion.***Optional, maker-elected** (still cashless: a fee credit, not a transfer). |
| **C. Connect direct payout** | Buyer pays A; platform routes component cost to X/Y connected accounts; Stripe is the transmitter. | Yes — scoped re-entry. **B2B-first is the safest place to cross** (verified, KYC'd, mandate-on-file makers). |
**Supplier choice with a carrot:** beyond the money-free default (A), a supplier may elect **non-cashable wallet credit** (nets their own fees, out of flow) or **Connect payout** (real money, scoped in-flow), with a **bonus for wallet**. Caveat: wallet credit only helps a maker who *has fees to offset* — a **pure supplier** (supplies many kits, rarely sells) accrues trapped credit and needs Connect regardless. Plan for both. Phasing: Phase 1 = Models A/B (record + notify + net; settle the remainder peer-to-peer); Phase 2 = Model C for pure suppliers, on the shared cashable rail.
### C.3 Fee economics — taxed once
Components carry a referral fee (supplier bears it, as in Curated-By) — but **tax each kit dollar once.** Example: kit retails at R; wholesale $40 (X) + $30 (Y) = $70 COGS to A. X's $40 → 15% = $6 platform, X nets $34; Y's $30 → 15% = $4.50, Y nets $25.50; A pays the standard platform fee on **A's own margin (R − $70)**, not the full R. Charging A's full fee on R *and* referral fees on the components would double-tax the $70. All of it runs through the ledger off the order event, never the consumer payment.
### C.4 Where kits can be sold — inventory integrity, not fees
The fee/settlement machinery works on *any* storefront (computed from the order webhook + the kit BOM in your network service), so a **Shopify maker can sell a kit, be MoR, and have settlement run on the webhook.** What Shopify can't give is a **real-time cross-maker stock check at purchase** (you don't control its checkout), so finite-stock components risk a sync-lag oversell. Therefore: **finite-stock kits → favor your Medusa storefront** (you control checkout: atomic availability gate + atomic order+payable); **made-to-order kits → storefront-agnostic** (no finite-stock race; kit lead time = max of component leads = pre-order semantics). v1 scoping: launch kits as a Medusa-seller feature; optionally allow made-to-order kits for Shopify sellers; defer Shopify finite-stock kits.
### C.5 Wholesale bookkeeping — including volume tiers
Storing "X charges A $W/unit, tiered by volume" and computing settlement from units is **pure facilitation (out of flow).** Two details tiers force: **retroactive vs. prospective** (when the price drops at unit 11, do 1–10 reprice or only 11+? — a *term A and X agree to*, which the platform stores and applies); and **stateful settlement** (tiered pricing depends on cumulative units, so settlement is a running total per supplier-agreement, not per-order-independent — build the ledger for that from the start).
### C.6 Shipping & fulfillment — the decisive argument for assembly
A kit drop-shipped from N makers = **N shipments; shipping scales with maker count, not order** (≈3× for three makers). The premium lands somewhere and every option hurts: on the **buyer** (visible combined shipping — a conversion killer on a "deal" kit), **A** (uncontrollable margin variance), or **suppliers** (inflated COGS). Managing it, best to worst: **(1) assemble-and-consolidate (default)** — components ship to A, A packs one box; fixes three problems at once (single shipping cost, single-package experience, QC liability), at the cost of A doing micro-fulfillment (which *is* A's value, and justifies the margin); **(2) 3PL/hub consolidation** (defer — overkill at indie volume); **(3) honest drop-ship** ("ships in N packages," disclosed — reserve for when consolidation is impossible); **(4) shipping-smart kit construction** — surface estimated combined shipping *at kit-design time* and prefer same-region makers (your network sees cross-maker geography no single maker can).
| Made-to-order | Consolidate | One box, but kit lead = max(component leads) + assembly hold |
| Made-to-order | Drop-ship | N boxes, N arrival times, N charges — **worst; avoid** |
**Through-line:** shipping argues the kit creator should be a real **assembler-principal**, not a thin aggregator. The clean money model (principal reseller) and the clean shipping model (assemble-and-consolidate) point at the same role for A — the signal the design is coherent.
---
## Appendix D — Storefront control & network participation (why walled gardens are out)
The gating property is **control of the three surfaces the network must touch**: the **storefront page** (to host the verified merchant referral collection), **checkout** (to attribute referrals and run clean agentic purchase), and the **buyer relationship** (to own identity). Merchant-controlled storefronts grant all three; walled-garden marketplaces deny all three *by design* — intermediating the buyer is the marketplace's business model, so participation **degrades monotonically as a maker cedes control to a walled garden.**
Layered on top is a value rule stricter than the technical limits: **the network never routes buyers *into* a walled garden — not via Curated-By, the buyer feed, or the agent feed.** So walled-garden makers are **invitation targets, not destinations** — even where a marketplace's API would permit ingesting their catalog, the value rule forecloses surfacing it as a buyable destination.
Legend: ✓ supported · ◐ partial/limited · ✗ not supported.
| Provider | Catalog sync-in | Be a curator | Be a network destination | Clean referral-fee attribution | Owns buyer | Clean agentic checkout |
|---|---|---|---|---|---|---|
| **Your white-label (Medusa)** | ✓ native | ✓ you build the page | ✓ controllable + value-OK | ✓ you own checkout | ✓ maker owns relationship | ✓ you expose ACP |
| **Self-hosted (Woo, Saleor, Vendure, custom)** | ✓ open APIs/plugins | ✓ full page control | ✓ controllable + value-OK | ✓ controls own checkout | ✓ owns buyer | ✓ their build exposes ACP |
| **BigCommerce** | ✓ Catalog/Admin API | ✓ open storefront | ✓ controllable + value-OK | ✓ controls checkout | ✓ owns buyer | ✓ their processor |
| **Squarespace / Wix** | ◐ commerce APIs (read) | ◐ code-injection, no clean app-block model | ✓ controllable, value-OK | ◐ checkout more closed — coupon/landing only | ✓ owns buyer | ◐ depends on platform |
| **Etsy** | ◐ Open API v3 — *unused as a destination by value rule* | ✗ can't modify the page | ✗ **value rule** — invitation target only | ✗ Etsy owns checkout | ✗ Etsy owns the buyer | ✗ Etsy's decision |
| **Amazon Handmade** | ✗ gated/restricted API | ✗ zero storefront control | ✗ value rule + Amazon owns all; invitation target | ✗ Amazon owns checkout | ✗ Amazon owns the buyer (most completely) | ✗ Amazon's own agents treat you as a competitor |
| **Patreon***(membership)* | ◐ API reads tiers/posts — *unused as destination by value rule* | ✗ can't host a Curated-By block on the page | ✗ value rule; invitation target | ✗ Patreon is MoR for the subscription | ✗ Patreon owns the patron — *one seam: email export* | ✗ Patreon's decision |
The table's shape *is* the thesis: **controllable storefronts ✓ across; walled gardens ✗ across.** Not a coverage gap — a restatement of who the network is *for* (makers who own their commerce, or will) and what it's an alternative *to*.
**The three-surfaces gate:** storefront-page control → be a curator; checkout control → attribution + agentic checkout; buyer-relationship control → identity/sovereignty.
**Walled gardens are who you're an alternative to — not a gap to cover.** A maker deep in Amazon Handmade who can't participate is the person the pitch is *aimed at*, who hasn't left yet. The right move is **invitation, not integration**: "I'd feature your work the moment you own your commerce" — the absence of a link is the recruiting signal, making membership the price of inclusion rather than subsidizing captivity. Notes: Etsy is the *most permissive* walled garden (Open API v3, models made-to-order, runs an affiliate program) but the value rule forecloses using it as a buyable destination anyway; a maker on *both* Etsy and a controllable storefront participates via the controllable one. Amazon Handmade is the most walled and the most hostile (restricted API, total buyer ownership, its own agentic-commerce ambitions). The **verification inversion** becomes a recruiting message: "we'd vouch for your work — verified independent of any marketplace's compromised badge — the moment you own your commerce."
**Patreon is the *membership-side* walled garden — the gap this table originally missed.** Every other walled garden above is a *transactional* marketplace (one-shot sales); Patreon applies the identical captive-commerce model to *recurring relationships*, and — unlike Etsy/Amazon for most makers — it is the **actual home of the beachhead audience** (Appendix A; the recurring-club incumbent, Appendix B). On the three-surfaces gate it scores like Etsy, not Shopify: no page control (no Curated-By block), no checkout control (no referral attribution — Patreon is MoR for the subscription), no buyer ownership (Patreon owns the patron) — the lone federatable seam is **patron-email export → seed the maker's ESP** (§7). So the Patreon posture is the same **recruit-out, don't integrate** rule, but materially more load-bearing than the Etsy one the memo otherwise leads with: the tension to face head-on is that *your first community lives on the very walled garden you are recruiting them off of* (§4). The answer is the two-sided play in Appendix B — **replace the club** (native, out-of-flow, maker-MoR) **+ lift the list + out-flank with the network.**
---
## Recurring principles (the spine)
Every decision in this memo reduces to a few invariants worth stating once, plainly:
- **The network is the moat; the storefront, hosting, and Medusa are fungible means in service of it.**
- **Bind with structure, not promises** — non-cashable wallets, verification gates, sovereignty-by-policy, the non-profit entity, the no-walled-garden rule. The wrong path is foreclosed, not merely disavowed.
- **Custody is the line; coordination and bookkeeping are free** — cross into the money flow once, knowingly, with rented infra (the Phase-2 cashable rail), never by accident.
- **Maker-as-discovery-engine, platform-as-pipe** — discovery is delegated to makers the buyer chose, never platform-performed.
- **Gate the demand, not the tool** — the storefront stays open to all; the network's *demand* surfaces (Curated-By, feed, referrals, agents) are what's gated, by **verification** (entry) and **reputation** (ongoing standing) alike. Makers chase trust rather than resent it.
- **The unvalidated keystone is demand, not technology.** The components all exist; the combination is novel but unproven. Everything is gated on §8: whether enough audience-having, vouch-willing makers exist in one tight community.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
ben.stull
Ben Stull