§21. The Modular Stack: Twelve Primitives and Four Reference Applications

Jason St George. "§21. The Modular Stack: Twelve Primitives and Four Reference Applications" in Next‑Gen Store of Value: Privacy, Proofs, Compute. Version v1.0. /v/1.0/read/part-iv/21-modular-stack/

§21. The Modular Stack: Twelve Primitives and Four Reference Applications

Parts III and IV described the stack layer-by-layer. This section flips the view: instead of layers, think in terms of modules builders actually touch and the primitives the system enforces underneath.

Two things matter in practice:

1. A small set of developer surfaces:

   • PaL SDK – Proofs-as-a-Library.
   • PRK – Privacy Rails Kit.
   • PFS – Proof Factory Stack.
   • VCO – Verified Compute Orchestrator.

2. A substrate kit of twelve primitives that make the triad tradable as infrastructure: proofs as receipts, compute as verified FLOPs, privacy as boringly usable rails.

The four reference applications—private treasury & payroll, media provenance, verified inference, and proof/compute procurement—are just different ways of winding these pieces through the Create/Compute → Prove → Settle → Verify loop.

21.1 Primitive catalog (the twelve pieces)

The twelve primitives fall into four clusters:

• Compute / consensus primitives – how useful work becomes a commodity unit.
• Proof primitives – how claims become receipts anyone can verify.
• Privacy & settlement primitives – how value moves privately and non-custodially.
• Market & telemetry primitives – how all of this becomes a measurable economy.

Compute / consensus primitives (AI-money substrate)

1. MatMul-PoUW kit A work function that turns matrix multiplication into a useful lottery with verification asymmetry. Canonical sizes (e.g., MATMUL_4096), seeding rules, and adversarial tests ensure that:

   • production cost scales ∼O(n³),
   • verification cost scales ∼O(n²),
   • and cheating is more expensive than being honest. This is the Duplex-style substrate: when proofs from this kit clear, we mint verified FLOPs rather than heat. The VCO schedules these tasks across provers and binds them to Work Credits.

2. Verified-inference harness An Ambient-style proof-of-logits layer for AI workloads: deterministic transcripts, randomized audits, peer-prediction, and stake-and-slash for dishonesty. Where full ZKML is not yet practical, the harness gives us:

   • probabilistic guarantees that outputs came from model M under policy P;
   • receipts per inference that VCO and PFS can route and price. As ZKML matures, the same harness becomes the “front door” for full proofs.

   Inference Proof Tier Taxonomy

   Verified inference is the most economically significant—and currently most fragile—part of the “AI Money” claim. To prevent readers from concluding “so AI Money is backed by trust,” we tier the guarantees explicitly:

   Tier	Verification Type	Description	Error Bound	WC Issuance Weight
   Tier A	Cryptographic correctness	Full ZK proof of inference (ZKML)	0 (exact)	1.0x
   Tier B	Probabilistic soundness	Audited transcripts + randomized checks + peer prediction	Explicit (e.g., 99% confidence, 0.1% false positive)	0.6x
   Tier C	Attestation-backed	TEE attestation + sampling audits	Implicit (trust TEE vendor + sampling)	0.3x

   Eligibility rules:

   Use Case	Minimum Tier	Rationale
   WC-Base issuance (full weight)	Tier A	Monetary issuance requires highest assurance
   WC-Base issuance (discounted)	Tier B	Acceptable with explicit error bounds and discount
   Service market only	Tier C	Can sell inference; cannot mint WC-Base
   Collateral (pristine)	Tier A only	DeFi integrations require cryptographic certainty
   Collateral (standard)	Tier A or B	With appropriate haircut
   Collateral (ineligible)	Tier C	Not acceptable as collateral

   Why this matters:

   Without this taxonomy, “verified inference” conflates cryptographic proof with probabilistic audit with vendor attestation. A skeptic would correctly say: “Tier C is just ‘trust the TEE’—how is that different from trusting a cloud provider?”

   By making tiers explicit and tying them to WC issuance weights, the thesis acknowledges engineering reality (full ZKML isn’t always practical) while preserving the monetary story (only high-assurance verification backs money-like instruments).

   Tier B requirements (reference):

   For Tier B verification to qualify:

   • Transcript determinism: Given the same model + input, transcript must be reproducible.
   • Audit rate: ≥10% of inferences are independently re-executed by random auditors.
   • Peer prediction: Multiple independent provers; divergence triggers investigation.
   • Stake-and-slash: Provers stake collateral; fraudulent transcripts → 100% slash.
   • Error bound publication: Explicit statistical guarantee (e.g., “99% confidence that output matches claimed model within ε”).

   Migration path:

   As ZKML matures:

   1. Tier A coverage expands to more model classes.
   2. Tier B issuance weight increases toward 1.0x as probabilistic guarantees tighten.
   3. Tier C is deprecated from WC eligibility entirely.

   The goal is for inference verification to converge to Tier A over time, but the system functions with tiered guarantees in the interim.

3. Canonical workload registry A dictionary of standardized SKUs for useful work and their parameters:

   • MATMUL_4096, INFER_LM_70B_256TOK, PROOF_2^20, PROVENANCE_VIDEO_V1, SETTLEMENT_BTC_XMR_V1, etc. Each workload entry defines:
   • ABI and parameter schema;
   • expected VerifyPrice ranges and SLA tiers;
   • allowed hardware profiles. This is the common language PFS, VCO, PaL, and markets use. Without it, “one unit of compute” is hand-waving.

Proof primitives (receipts as a first-class object)

4. PaL SDK (Proofs-as-a-Library) The developer surface for Layer 4. PaL lets you write:

   • “prove this computation,”
   • “prove this provenance,”
   • “prove this settlement policy.” Under the hood, it:
   • maps claims to canonical workloads,
   • picks proving backends and hardware profiles subject to policy (e.g. “pure_zk_only”, “open_tee_v2”),
   • talks to PFS/VCO,
   • and returns a PIDL receipt plus proof artifact. Applications never hard-code a specific SNARK, miner, or cloud; they target PaL.

5. Multi-ZK adapter & auto-selector A policy engine that keeps proofs a commodity, not a vendor feature. Given a workload and SLA (latency, cost, jurisdiction constraints), it:

   • queries current VerifyPrice for each backend,
   • chooses among SNARK/STARK/zkVM implementations (and, where allowed, TEEs),
   • hot-swaps when congestion or failures hit,
   • and exposes its decisions in receipts (so anyone can see which backend was used). PFS calls the adapter whenever it assigns work; PaL treats it as an internal detail.

6. PIDL (Proof Interface Definition Language) The minimal receipt schema for the loop. A PIDL receipt binds:

   • receipt_id
   • claim_id
   • workload_id
   • proof_ref (hash or pointer)
   • policy_id / SLA tier
   • hardware_profile (if relevant)
   • timestamps and verify-time / cost samples
   • result (accept / reject / timeout)
   • optional: fer_id, compliance tags, jurisdiction tags
   • signatures from prover, verifier, and (if present) broker

   PIDL is the “bill of lading” for truth: it lets receipts travel across chains, institutions, and time without losing meaning. PFS writes them; everyone else reads them.

Privacy & settlement primitives (private-money substrate)

7. Adaptor-signature atomic-swap kit A library of audited protocols and UX flows for non-custodial BTC↔ZEC/XMR settlement (and analogues), with refund-safety as a hard invariant. It defines:

   • precise script / adaptor-sig patterns,
   • timeout and refund semantics,
   • typed failure modes (“counterparty gone”, “insufficient liquidity”, “fee too low”),
   • and test harnesses for clients.

   PRK uses this kit to turn “pay for proof/compute” intents into actual flows with two outcomes only: success or safe refund.

8. Lawful-privacy corridor pack Hooks and conventions for viewing keys + receipts that let regulated actors prove compliance without re-introducing custodians. Concretely:

   • corridor policies that require PIDL receipts with specific compliance fields,
   • standard formats for audit bundles (e.g. “show all payroll receipts for Q3”),
   • guidelines for how to expose this in wallets and treasury tools.

   When treasuries use PRK to pay over privacy rails, this pack is what makes “lawful privacy” an off-the-shelf product rather than a bespoke negotiation.

9. Bridge-safety templates Pattern book for cross-chain settlement that avoids “magic multisigs”:

   • light-client-based bridges,
   • zk-proof bridges,
   • HTLC/adaptor-sig bridges with clearly scoped trust,
   • plus a failure taxonomy (what can break, how it is detected, how losses are bounded).

   PRK and PaL tag any flows that touch bridges with a bridge-profile; VerifySettle and the SoV checklist treat unsafe templates as second-class citizens.

Market & telemetry primitives (making it all priceable)

10. SLA escrow & slashing contracts Standard contracts and on-chain logic for Bronze/Silver/Gold tiers:

    • Bronze: best-effort, cheap; retries allowed.
    • Silver: bounded latency, partial redundancy.
    • Gold: tight p95 latency, high redundancy, strong penalties.

    For each tier, proofs and settlements that miss SLOs trigger automatic refunds or slashes keyed to PIDL receipts. PFS and VCO use these when they match buyers and sellers; treasuries rely on them to underwrite spend.

11. VerifyPrice telemetry & methodology The measurement side of verification asymmetry:

    • reference verifier harnesses per workload,
    • sampling strategies over receipts,
    • public dashboards for p50/p95 verify time, cost, failure rates, and overhead r(W) = v/p.

    Without this, “cheap verification” is a slogan. With it, proofs and verified FLOPs become quotable commodities. Markets, PFS, VCO, and governance all use the same numbers.

12. Neutral router & fairness tests Matching logic and diagnostics that keep PFS and VCO honest:

    • open order-matching code (no opaque “magic routing”),
    • house-share caps (no more than X% of flow can be filled by in-house capacity),
    • entry-latency metrics (how long from new prover/LP registration to first fill),
    • fairness plots and audits (third-party orders get cleared alongside house orders).

    When we talk about “no chokepoints,” this is the concrete guarantee: routers behave like neutral markets, not dark pools.

Together, these twelve primitives are the substrate kit. PFS and VCO are the two big orchestrators built on top:

• PFS (Proof Factory Stack) bundles primitives 4–6, 10–12 to turn arbitrary claims into routed proof jobs, receipts, and payments.
• VCO (Verified Compute Orchestrator) bundles 1–3, 5, 10–12 to turn useful workloads (matmul, inference) into scheduled PoUW, verified FLOPs, and Work Credits.

PaL and PRK are what builders actually import. They speak in terms of claims and payments; PFS, VCO, and the twelve primitives make sure that, underneath, we only ever pay the machine for work anyone can verify cheaply, and that those payments leave behind receipts the rest of the thesis can lean on.

We can now revisit the four reference applications and show how they traverse the Create/Compute → Prove → Settle → Verify loop.

The goal here is a mental model: how triad capacities, Work Credits, and the stack interlock in realistic flows.

21.2 Private treasury & payroll

Scenario. A small but globally distributed company wants to pay staff and vendors in a way that:

• avoids single‑jurisdiction custody risk,
• preserves employee privacy,
• remains auditable for regulators and investors.

Flow.

1. Create.

   • Finance defines a payroll batch: who gets paid, in what asset/amount, under which policy.
   • Policy includes “proof‑of‑work” for invoices or deliverables where applicable.

2. Compute.

   • Application logic computes net pays, withholding, and corridor selection.

3. Prove (Layer 4).

   • PaL is invoked to generate proofs that:

     • Each payment is within policy (e.g., under KYC’d pseudonyms).
     • Withholdings and taxes are correctly computed.

4. Settle (Layer 5).

   • PRK executes payments over BTC↔ZEC/XMR corridors or shielded pools.
   • Refund safety ensures no funds are lost if a corridor stalls.
   • PIDL receipts link proofs and settlements; viewing keys allow the company to reveal exactly what regulators need, and nothing more.

5. Verify.

   • Auditors or investors can independently verify:

     • The correctness of computations (via proofs).
     • The fact that payments were made and landed (via receipts and chain checks).
     • Compliance with stated policies (via selective disclosure).

Monetary angle.

• The company may choose to hold Work Credits that entitle it to future private settlement capacity (ZK Money) as part of treasury.
• Employees implicitly rely on Layer‑5 and Layer‑4 health as part of their personal SoV.

21.3 Media provenance & authenticity

Scenario. A media network wants to guarantee that certain “gold channel” content—e.g., war footage, election coverage—is accompanied by verifiable provenance.

Flow.

1. Create.

   • Cameras capture footage with built‑in Layer‑0 attested hardware profiles.
   • Editors and aggregators transform content.

2. Compute.

   • PaL encodes lineage: camera → editor → platform.

3. Prove (Layer 4).

   • Proof factories generate provenance proofs (canonical workload: Provenance(C, chain)).
   • VerifyPrice ensures checking these proofs is cheap even on modest hardware.

4. Settle (Layer 5).

   • Advertisers or subscribers pay content creators and publishers over privacy rails.
   • Payment flows are conditioned on presence of valid provenance proofs.

5. Verify.

   • End‑users, regulators, or courts can verify:

     • That an artifact really passed through the stated chain.
     • That payments were linked to content with valid receipts.

Monetary angle.

• Truth Money emerges: claims on future provenance‑proof capacity.
• Advertisers and insurers may hold Work Credits for provenance workloads as a hedge.

21.4 Verified inference (AI as a service)

Scenario. An AI service offers “verified inference” to enterprises who don’t want to trust a black‑box API with their inputs or outputs.

Flow.

1. Create.

   • A client submits an inference request: model M, input X, constraints (e.g., maximum allowed L2 norm between two runs, or monotonicity conditions).

2. Compute.

   • A proof factory or PoUW miner runs the inference.

3. Prove (Layer 4).

   • PaL compiles the inference into a canonical workload Inference(M, X; policy).
   • A proof is generated attesting to correct execution under constraints.

4. Settle (Layer 5).

   • Payment (via PRK) is contingent on a valid proof being returned.
   • Work Credits may be spent or earned in the process.

5. Verify.

   • The client, or any third party, can verify the proof and accept the output.

Monetary angle.

• AI Money is just Work Credits and derivatives for these inference workloads.
• Enterprises may hold such instruments to hedge compute prices or ensure future access.

21.5 Proof/compute procurement

Scenario. A DAO or treasury wants to pre‑buy proof and compute capacity for future needs (compliance, analytics, AI features).

Flow.

1. Create.

   • The DAO defines demand curves for workloads W1…Wn over time.

2. Compute.

   • A procurement module computes optimal schedules and risk diversification over hardware profiles and jurisdictions.

3. Prove (Layer 4).

   • As Work Credits are minted from real workloads, the DAO purchases them (spot or futures).

4. Settle (Layer 5).

   • Payment flows over privacy rails; Work Credits are held in treasury.

5. Verify.

   • Anyone can audit the backing of Work Credits via VerifyPrice/W, profiles, and proof metadata.

Monetary angle.

• The DAO’s treasury becomes triad‑backed: part BTC/ETH, part ZK Money, part AI Money.
• The value of its Work Credits reflects the market’s belief in the ongoing necessity of Privacy, Proofs, and Compute.

Part IV, in summary, is where the triad learns to speak economics:

• Layer 4 turns computation and provenance into standardized, verifiable work units.
• Layer 5 turns those work units into private, non‑custodial value flows.

Only with these in place does it make sense to talk about Private Money and AI Money as more than metaphors. In Part V, we’ll climb to Layer 6 – Governance & Telemetry, where neutrality and repression‑resilience are kept falsifiable, not just promised.

Tip: hover a heading to reveal its permalink symbol for copying.