§21. The Modular Stack

Jason St George. "§21. The Modular Stack" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v1.9. /v/1.9/read/part-iv/21-modular-stack/

The Modular Stack

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.

Primitive Catalog: The Twelve Pieces

The twelve primitives fall into four clusters:

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 $\sim O(n^3)$,

   • verification cost scales $\sim O(n^2)$,

   • 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.

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.

3. Canonical workload registry — A dictionary of standardized SKUs for useful work: MATMUL_4096, INFER_LM_70B_256TOK, PROOF_2^20, PROVENANCE_VIDEO_V1, SETTLEMENT_BTC_XMR_V1, etc.

Inference Proof Tier Taxonomy

Verified inference is the most economically significant—and currently most fragile—market under the “AI Money” analytical lens. The label does not make inference claims monetary; the guarantees are tiered explicitly so weak assurance is not marketed as strong:

Inference proof tier taxonomy.

Tier eligibility rules.

Why this matters: Without this taxonomy, “verified inference” conflates cryptographic proof with probabilistic audit with vendor attestation. By making tiers explicit and tying them to Work Credit issuance weights, the thesis acknowledges engineering reality while preserving the instrument hierarchy: assurance grades service claims; monetary candidacy belongs only to the separate base asset.

Tier B requirements (reference): For Tier B verification to qualify:

• Transcript reproducibility against a pinned kernel: FP32 arithmetic is non-associative and BLAS kernels differ across hardware profiles, so bit-identical transcripts across heterogeneous provers are not achievable. The requirement is pinned-kernel reproducibility: each workload registry entry names a reference kernel (arithmetic order, FMA contraction off, no TF32), a transcript is reproducible by any prover running that kernel, and cross-kernel divergence is handled through the workload’s relative error bound rather than exact-match. A prover may run a faster kernel only by proving conformance within $\varepsilon_r$ of the reference result.

• Audit rate: $\geq 10\%$ of inferences are independently re-executed by random auditors.

• Peer prediction: Multiple independent provers; divergence beyond $\varepsilon_r$ triggers investigation.

• Stake-and-slash: Provers stake collateral; fraudulent transcripts $\to$ 100% slash.

• Error bound publication: Explicit statistical guarantee (e.g., “99% confidence that output matches claimed model within $\varepsilon_r$”).

Migration path: As ZKML matures: (1) Tier A coverage expands to more model classes; (2) Tier B issuance weight increases toward 1.0$\times$ 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.

Proof Primitives (Receipts as First-Class Objects)

4. PaL SDK (Proofs-as-a-Library) — Developer surface for Layer 4.

5. Multi-ZK adapter & auto-selector — Policy engine keeping proofs a commodity, not a vendor feature.

6. PIDL (Proof Interface Definition Language) — Minimal receipt schema binding claim, workload, proof, SLA, timestamps, and signatures.

Privacy & Settlement Primitives (Private-Money Substrate)

7. Adaptor-signature atomic-swap kit — Library for non-custodial BTC$\leftrightarrow$ZEC/XMR settlement with refund-safety.

8. Lawful-privacy corridor pack — Hooks for viewing keys + receipts enabling regulated actors to prove compliance.

9. Bridge-safety templates — Pattern book for cross-chain settlement avoiding “magic multisigs.”

Market & Telemetry Primitives

10. SLA escrow & slashing contracts — Standard contracts for Bronze/Silver/Gold tiers with automatic refunds or slashes.

11. VerifyPrice telemetry & methodology — Measurement side of verification asymmetry.

12. Neutral router & fairness tests — Matching logic with house-share caps and entry-latency metrics.

PFS (Proof Factory Stack) bundles primitives 4–6, 10–12 to turn claims into routed proof jobs.

VCO (Verified Compute Orchestrator) bundles 1–3, 5, 10–12 to turn useful workloads into Work Credits.

The Four Reference Applications at a Glance

The four applications that follow are not a product roadmap. They exist to show that the stack closes: each one exercises a different span of layers, reports to a different set of public boards, and would trip a different set of red lines if the thesis is wrong. An architecture that cannot name which application would reveal which failure is not falsifiable in practice, however many metrics it publishes.

Between them the four applications stress eleven of the fifteen red lines. The four they do not reach—Red Line 4 (telemetry capture), Red Line 8 (governance capture), Red Line 14 (the capturable wedge closing), and Red Line 15 (the native collateral–capacity spiral)—are protocol-wide or market-wide failures rather than application-level ones, which is precisely why they cannot be caught by shipping an application and must be watched institutionally instead. Red Lines 14 and 15 are the clearest cases: an individual application can be technically successful while the capturable wedge closes or native collateral reflexivity degrades system-wide capacity.

Reference Application: Private Treasury & Payroll

Scenario. A globally distributed company wants to pay staff and vendors while preserving salary confidentiality, avoiding unnecessary exposure of the transaction graph, and giving auditors and tax authorities scoped evidence that payments were authorized, complete, and properly reported.

Flow:

1. Create. Finance defines a payroll batch with policy.

2. Compute. Application logic computes net pays and corridor selection.

3. Prove. PaL generates proofs that payments are within policy.

4. Settle. PRK executes payments over BTC$\leftrightarrow$ZEC/XMR corridors.

5. Verify. Auditors verify correctness via proofs and receipts.

Reference Application: Media Provenance

Scenario. A media network guarantees that “gold channel” content is accompanied by verifiable provenance.

Flow:

1. Create. Cameras capture footage with Layer-0 attested hardware.

2. Prove. Proof factories generate Provenance(C, chain) proofs.

3. Settle. Advertisers pay creators over privacy rails, conditioned on valid proofs.

4. Verify. End-users verify that content passed through the stated chain.

Reference Application: Verified Inference

Scenario. An AI service offers “verified inference” to enterprises who don’t want to trust a black-box API.

Flow:

1. Create. Client submits inference request with constraints.

2. Compute. Proof factory runs the inference.

3. Prove. PaL compiles into Inference(M, X; policy) with proof.

4. Settle. Payment via PRK contingent on valid proof.

5. Verify. Client verifies proof and accepts output.

AI Money is an analytical lens or legacy label for these inference-service markets. The instruments are typed Work Credits and derivatives; they are not themselves money.

Reference Application: Proof/Compute Procurement

Scenario. A DAO wants to pre-buy proof and compute capacity for future needs.

Flow:

1. Create. DAO defines demand curves for workloads over time.

2. Compute. Procurement module computes optimal schedules.

3. Prove. As Work Credits are minted, DAO purchases them.

4. Settle. Payments over privacy rails; typed Work Credits held as prepaid service inventory, not monetary reserves.

5. Verify. Anyone audits backing via VerifyPrice, profiles, and proof metadata.

The DAO’s treasury holds BTC/ETH reserve assets beside typed proof and compute capacity instruments. “ZK Money” and “AI Money” are analytical or legacy lenses for those service markets, not claims that the underlying Work Credits are money. Any separate base asset remains only a conditional monetary candidate.

Part IV Summary

Part IV 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.

With these in place, the legacy Private Money, AI Money, and Proof/Attestation Money labels become useful analytical lenses on settlement, compute, and proof-service demand. Their Work Credits and capacity instruments remain typed service claims, not monetary instruments. Only the separate base asset may become a monetary candidate if all conditions pass. In Part V, we 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.