§21. The Modular Stack

Jason St George. "§21. The Modular Stack" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v3.2. /v/3.2/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

Twelve primitives, and collectively they do one thing: they let two strangers trade verified work without either one trusting the other’s platform. That is the whole catalogue. When proofs from this kit clear, we mint verified FLOPs rather than heat; when the receipt schema binds, a claim becomes portable instead of platform-bound; when the corridors settle non-custodially, the value moves without a custodian appearing in the middle. No single primitive accomplishes any of that. The twelve are what the stack ships so that trust can be withdrawn, one counterparty at a time.

They 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 (the MATMUL_4096_FP32 SKUs of §19: Layer 4: Truth & Work), seeding rules, and the adversarial acceptance suite ensure that:

   • production cost scales $\sim O(n^3)$,

   • verification cost scales $\sim O(n^2)$ [Freivalds 1977] (Freivalds; a theorem),

   • and cheating is more expensive than being honest — which, for the consensus role, is the conjecture of §19: Layer 4: Truth & Work and the open problem of §19: Layer 4: Truth & Work.

   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 [Ambient 2024] 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. Until then, it is what keeps an inference receipt from being a screenshot of a trust-me box: a transcript exists, an auditor can re-run it, and a prover who fabricates one loses stake.

3. Canonical workload registry — The dictionary of standardized SKUs for useful work, published as §19: Layer 4: Truth & Work: PROOF_2^20, the two MATMUL_4096_FP32 SKUs, INFER_LM_7B_512TOK, INFER_LM_70B_256TOK, PROVENANCE_MEDIA_V1, SETTLE_ATOMIC_BTC_XMR_V1, and the gated ZEC corridor. This is the thesis’s unit of account in physical form: without it, “compute” is a negotiating position rather than a quantity, and no two quotes mean the same thing.

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’s $0.3\times$ weight is stepped toward zero and Tier C is eventually retired from WC eligibility. 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$XMR settlement with refund-safety as defined in §20: Layer 5: Value & Settlement, and the shielded-scripting work that a BTC$\leftrightarrow$ZEC corridor would need before it can be built. The adversary here is the counterparty who takes your funds and disappears mid-trade, and the kit exists so that no one—including the corridor operator—can be that counterparty. Non-custodial rhetoric is cheap; invariants are not.

8. Lawful-privacy corridor pack — Hooks for viewing keys + receipts enabling regulated actors to prove compliance. A bank that cannot demonstrate compliance to its regulator cannot route anything, so these hooks are what keep lawful privacy lawful rather than merely private.

9. Bridge-safety templates — Pattern book for cross-chain settlement that classifies every signer set and haircuts it (§20: Layer 5: Value & Settlement). The graveyard this pattern book walks past is full of bridges whose security model was, on inspection, five signatures held by people who knew each other — and whose documentation did not say so.

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.

PRK (Privacy Rails Kit) bundles primitives 7–9, with 6 for the receipt schema and 11 for VerifySettle telemetry, to turn a payment intent into a non-custodial, refund-safe, selectively disclosable settlement. Every primitive now belongs to at least one bundle.

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 eighteen red lines. The seven they do not reach—Red Line 4 (telemetry capture), Red Line 8 (governance capture), Red Line 14 (the capturable wedge closing), Red Line 15 (the native collateral–capacity spiral), and Red Lines 16–18 (the three link-9 monetary tests: convenience-yield null, information-sensitivity reversion, denomination null)—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 16–18 read on holder behaviour and market structure of the base asset and cannot, by construction, be reached by any application. 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

It is the 26th of the month, and the payroll run is late. The company’s CFO is in Singapore, its controller is in Lisbon, and its 340 employees are spread across eleven jurisdictions. Under the incumbent way, the 26th is late because payroll is a daisy chain of NDAs: the bank wants the salary list, the auditors want the bank, the tax authority wants the auditors, and every one of those disclosures is a copy of the transaction graph that will never be recalled. The controller cannot prove the run is correct without handing over the graph, and cannot protect the graph without becoming the only person who can prove anything. Every quarter the company chooses which of those two failures to have.

This application removes the choice. Salary amounts stay confidential, the transaction graph stays private, and the auditors still get scoped evidence that every payment was authorized, complete, and properly reported—not the underlying ledger, but proofs about it, limited to what the mandate actually asks.

The flow is the stack, end to end:

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$XMR corridors (the ZEC corridor when admissible).

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

Design commitments. Policy conformance (each net pay within its band, batch total equal to the authorized total, every recipient in the authorized set) is proved under M1 as a succinct range-and-membership proof over the batch commitment, so the auditor’s check is milliseconds and independent of headcount; settlement runs over the SETTLE_ATOMIC_BTC_XMR_V1 corridor (Class-A-equivalent, no bridge), with the payroll disclosed to the auditor by epoch-scoped rotation and to each employee by payment-scoped disclosure (§20: Layer 5: Value & Settlement); and each PIDL receipt binds the batch commitment, the policy hash, the corridor identifier, both chains’ finality proofs, the refund-safety outcome code, and the signatures of the finance approver and the proving factory.

Reference Application: Media Provenance

A clip surfaces on a Tuesday: a minister, a private conversation, forty seconds that would end a career if they were real. By Thursday the newsroom knows it is synthetic and cannot say so with anything it can hold up. The platform’s provenance label says “authentic”; the label is a string in the platform’s own database, and everyone in the room understands what that is worth. The newsroom’s correction cites “internal review.” The clip keeps circulating. Nobody lied; there was simply nothing to check.

This application is what there is to check. Capture hardware attests at the moment of recording, provenance proofs travel with the footage rather than living in a platform’s database, and the question “did this come from camera C and reach us through the stated chain?” acquires an answer a reader can verify without trusting the newsroom, the platform, or anyone’s internal review.

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

Design commitments. The provenance chain is the PROVENANCE_MEDIA_V1 SKU, proved under M1 so a reader on Mobile-Class hardware verifies the whole chain in under a second; its trust root is a Layer-0 attested capture, which is M3 (hardware attestation) and is labelled as such in the receipt, so the modality of the chain’s first hop is never overstated. Advertiser-to-creator settlement is a conditional payment over the BTC$\leftrightarrow$XMR corridor with no bridge in the path. The receipt carries the content hash, the capture-device attestation and its hardware profile, one signed edit record per hop with the hop’s transform declared, the chain’s proof, and the timestamps of capture and each hop.

Reference Application: Verified Inference

A risk officer at an insurer signs off on a model whose outputs will move payouts on thousands of policies. The vendor’s API returns a number and a confidence score, and behind the endpoint the officer can see nothing: not whether the model is the one advertised, not whether the input was modified in transit, not whether the “confidence” is a measurement or a marketing decision. The incumbent answer is a due-diligence visit and an attestation letter. The officer files the letter and assumes residual risk, because there is nothing else to do with it.

This application replaces the letter with a receipt. The enterprise submits an inference request under stated constraints; the proof factory runs the model and produces Inference(M, X; policy) with a proof that the output came from model $M$ on input $X$ under that policy. Payment is contingent on the proof being valid, so the vendor is paid for verified work, not for uptime of a black box.

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

Design commitments. The inference is the INFER_LM_7B_512TOK SKU under M3 (sampled re-execution, Tier B) today, with the _ZKML SKU as the M1 destination once a production prover exists; the officer’s “proof” is, at present, a pinned-kernel transcript plus the audit record showing which random auditors re-executed it, and the receipt says so rather than calling it a proof. Payment is a conditional flow over the BTC$\leftrightarrow$XMR corridor, released against the receipt. The receipt binds the model hash, the input commitment, the output commitment, the pinned kernel ID, the transcript hash, the audit sample and each auditor’s signed verdict, the assurance tier, and the prover’s stake reference.

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

A DAO’s treasury committee is staring at a proof-capacity crunch it can see coming and cannot buy ahead. Under the incumbent way, the committee’s options are a cloud commitment letter—a price the vendor sets, hardware the committee cannot inspect, and a lock-in it will still be paying for after the crunch passes—or forward contracts on capacity nobody can verify exists. Neither instrument lets the DAO prepay for capacity it can later prove it received. The gap is not a pricing gap; it is a verification gap, and it is why procurement at distance has historically meant procurement on faith.

This application closes the gap. The DAO declares demand curves for canonical workloads over time, buys typed Work Credits as they are minted against verified work, and holds them as prepaid service inventory. Anyone can audit the backing: the credits are minted against registry workloads whose proofs and VerifyPrice profiles are public, so the committee’s claim to future capacity is checkable by any token holder, not asserted by the committee.

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

Design commitments. The credits the DAO buys are typed by registry SKU and therefore by modality: a PROOF_2^20 credit is M1/Tier A and pledgeable, an INFER_LM_7B_512TOK credit is M3/Tier B and is prepaid inventory only, and the procurement module refuses to net the two into one “capacity” figure. Purchases settle over the BTC$\leftrightarrow$XMR corridor or, where the DAO’s treasury sits on a Class A light-client bridge, over that bridge at full eligibility and never over Class D. Each Work Credit’s PIDL receipt carries the SKU, the minting epoch, the issuance weight applied and why (tier, hardware grade, concentration), the facility’s FCR reference, and the redemption terms, so the backing audit is a fold over receipts rather than a request to the committee.

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.

New here? Start with the one-minute version.

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