Truth, Work, and Settlement – Layers 4–5

Layers 0–3 answer four questions:

1. Can we trust the machine? (Layer 0)

2. Can we reach it under censorship? (Layer 1)

3. Can we get code onto it and keep it updated? (Layer 2)

4. Can actors prove “who” they are without doxxing themselves? (Layer 3)

Layers 4 and 5 take those answers as given and ask two more:

5. Can we turn machine work into claims that anyone can verify cheaply? (Layer 4)

6. Can we settle those claims as value flows without chokepoints? (Layer 5)

If Layers 0–3 are the nervous system and limbs, Layers 4–5 are the cortex and circulatory system: they decide what counts as action and how it is remembered in economic form.

Infrastructure $\neq$ Money

Layers 4–5 create markets for proofs, verified compute, and private settlement. They do not create money at all. A working market for verified FLOPs is necessary for the monetary thesis but not sufficient: Part II’s value-capture conditions decide whether the market’s economics accrue to the base asset through fees, burns, and collateral (Value Capture Lemma), and whether accrual becomes moneyness is the separate question of the three link-9 mechanisms.

Layer 4 is the Prove/Verify spine of the stack.

Its job is to take arbitrary claims—“this media object came from camera C at time T,” “this inference was computed by model M on input X,” “this corridor swap executed atomically”—and turn them into portable proofs that:

• anyone can check with cheap, public verification, and

• can be standardized as commodities (canonical workloads, SLAs, prices).

What Layer 4 Is (and Is not)

Layer 4 is:

• The layer of circuits, proofs, and verification economics.

• The place where verification asymmetry is engineered and measured.

• The home of Proofs-as-a-Library (PaL), proof factories, and canonical workload registries.

Layer 4 is not:

• A specific proof system (SNARK vs. STARK vs. something else); it assumes multi-ZK.

• A single PoUW design; it supports several patterns as long as VerifyPrice and anti-capture constraints are met.

• A truth oracle. Proofs do not prove truth; they prove specific claims under stated assumptions—origin, custody, computation, policy compliance, and settlement finality. The thesis is not that cryptography tells us what is true, but that it reduces the surface area over which institutions must be trusted.

Verification Asymmetry Revisited

Recall the definition from Part I. For a workload $W$:

• $p(W)$ = cost (time, energy, hardware) to produce a result + proof.

• $v(W)$ = cost to verify that result + proof.

• $r(W) = \frac{v(W)}{p(W)}$ = verification asymmetry.

Both $v(W)$ and $p(W)$ are aggregated into the same numeraire — USD via the per-run price model of Chapter 22: Layer 4: Truth & Work ($c_{\text{run}} = (e_{\text{run}}/3.6\times10^{6})\,p_{\text{energy}} + t_{\text{run}}\,p_{\text{opp}}$) — so the ratio is dimensionless and both halves carry the same measurement contract: $v$ under the adversarial harness, $p$ under the reference production model (Appendix A: Formal Model of Verification Asymmetry & VerifyPrice). Read the denominator before celebrating the ratio: $r(W)$ improves in two ways, verification getting cheaper or production getting dearer, and a passing $r(W)$ achieved by expensive production is a cost problem wearing an asymmetry credential. The ratio is therefore published with both components; a falling $r(W)$ driven by a rising $p(W)$ is flagged as such.

Layer 4’s goal is simple:

Make $r(W) \ll 1$ for the workloads that matter, and keep it that way in production.

This is the touchstone of the gold analogy, now carrying a price: expensive to smelt, cheap to assay. $r(W)$ is the assay, priced.

Why this matters:

• If $v(W)$ is small and stable, anyone (including small nodes) can check proofs.

• That makes proofs and verified FLOPs commodities: units of work that any counterparty can accept without trusting a platform.

Layer 4 introduces:

\text{VerifyPrice}(W) = \{\underbrace{\text{p50 time},\:\text{p95 time},\:\text{p50 cost},\:\text{p95 cost},\:\text{failure rate}}_{\text{canonical five-field tuple }([Appendix A: Formal Model of Verification Asymmetry & VerifyPrice](/v/4.1/read/appendix/a-verifyprice-model/))},\:\text{hardware profile mix}\}

where the first five fields are the canonical tuple of Appendix A: Formal Model of Verification Asymmetry & VerifyPrice and the hardware profile mix is Layer 4’s reporting context: every published series names the verifier classes it aggregates over, and the mix travels with the tuple rather than replacing any field.

Verification Modalities, and Which One Carries the Monetary Claim

The ratio $r(W)$ has been carried through this document as a single scalar against a single ceiling. That was adequate while cheap verification was an operational requirement. It is not adequate now that Chapter 13: Why Hold the Base Asset? makes cheap verification the mechanism the monetary claim runs on, because the ceiling as written does not protect the property the monetary claim needs.

The ceiling is not binding where it matters.

A workload can satisfy $r(W) \leq 0.3$ and be nowhere near the regime the touchstone image describes. At $r = 0.3$ checking a claim costs thirty per cent of producing it. Nobody checks everything at that price. Participants check samples, or delegate, or accept a counterparty’s assurance — which is precisely the symmetric ignorance described in Chapter 13: Why Hold the Base Asset?, arrived at by an SLO the network is passing. An asset whose verification sits at the ceiling is accepted because checking is too expensive to bother with, which is the old mechanism with better tooling, and it fails the way the old mechanism fails.

The ceiling is therefore an engineering floor and should be labelled as one. What the monetary argument requires is a statement about modality, because the three ways of establishing that work was done correctly differ by orders of magnitude and differ in kind.

Verification Modality Bands

M1 — Succinct. A cryptographic proof checked by a verifier whose cost is sublinear in, and typically independent of, the work proved. Target $r(W) \leq 10^{-3}$, stretch $10^{-5}$. Everyone can afford to check everything.

M2 — Algebraic or probabilistic. A structured check cheaper than re-execution by a factor of the problem size, accepting a stated soundness error — Freivalds-style matrix verification [Freivalds 1977] at $O(n^{2})$ against $O(n^{3})$ production is the canonical case. Each Freivalds round costs three matrix–vector products, so $k$ rounds at soundness $2^{-k}$ give $r(W) \approx 3k/n$ in arithmetic alone (a single round over a large field, with soundness $1/|\mathbb{F}|$, gives $\approx 3/n$); the $O(n^{2})$ input/output and hashing cost of reading the committed operands adds a constant. Target $r(W) \leq 10^{-2}$ with the soundness parameter published beside the ratio. Everyone can afford to check everything, in expectation.

M3 — Replicated or attested. Correctness established by independent re-execution, committee agreement, or hardware attestation. Verification cost does not fall asymptotically below production cost; what is bought is fault tolerance and accountability, not asymmetry. No $r(W)$ target applies, because the ratio is not the operative quantity. Someone checked. You are trusting who.

The aggregate $r(W) \leq 0.3$ ceiling is retained as a portfolio-level engineering floor and as the fallback for workloads not yet assigned a band. It is not a monetary threshold and no monetary claim reads on it.

Only M1 and M2 carry the monetary mechanism, and this is a consequence rather than a preference.

Chapter 13: Why Hold the Base Asset? locates moneyness in no-questions-asked acceptance reached by symmetric knowledge — checking is free enough, and public enough, that no counterparty can acquire an informational edge by performing it. M1 delivers that, to a security level published in provable rather than conjectured bits. M2 delivers it up to a published soundness error, which is a quantified and therefore acceptable dilution. M3 does not deliver it at all: under replication the participant is not checking, a committee is, and the participant is trusting the committee’s composition, independence, and continued availability.

That is not a criticism of M3. Replication is the right construction for a great many workloads and much of the useful capacity this thesis describes will be M3. It is a statement about what M3 capacity can be used for. M3 supports service delivery, Work Credits, and SLA tiers. It does not support the pledgeability claim, because a position whose correctness rests on a committee requires the lender to form a view about that committee — which is due diligence, which is the thing information-insensitivity is defined as the absence of.

Replication buys fault tolerance. Succinctness buys moneyness. The thesis needs both and has been pricing them as though they were the same good.

The modality is what the haircut was always pricing.

This resolves a loose end rather than creating one. The collateral haircut schedule of Chapter 17: Layer 0: Verifiable Machines & Energy already discounts positions by how legible their substrate is, and Chapter 13: Why Hold the Base Asset? identifies those haircuts as prices on residual unit-quality uncertainty. Modality is the second axis of the same schedule and the more fundamental one: an M3-verified position carries irreducible delegated-trust exposure regardless of how good its hardware grade is, and an M1-verified position on modest hardware may carry less. The haircut table is therefore indexed on modality $\times$ grade, and the two are not collapsed: Chapter 17: Layer 0: Verifiable Machines & Energy in Chapter 17: Layer 0: Verifiable Machines & Energy is the joint table, and the modality increment exceeds the grade increment in every cell but one.

What this changes in the instruments.

Three reporting consequences, none of which relaxes anything:

• VerifyPrice series are published banded by modality. An aggregate $r(W)$ across a mixed M1/M3 portfolio is a number with no interpretation, and its improvement can be produced by changing the mix rather than by improving anything.

• The M1+M2 share of verified capacity becomes a published series in its own right. It is the fraction of the network’s output that carries the monetary mechanism at all, and it belongs beside fee coverage on the Value Capture Board (Chapter 26: Extended Telemetry) rather than among the engineering metrics.

• Red Line 3’s monoculture condition acquires a second reading. Concentration of verification in a single vendor is one failure; migration of the capacity mix from M1 toward M3 is a quieter version of the same failure, because both end at “trust the verifier.” The second reading is instrumented by Invariant 1(a) of Chapter 25: Layer 6: Governance & Telemetry: the M1+M2 share of verified units is a published series with a floor, and a fall below it is Sev-1.

And the rhetoric can now be correct.

Claims that checking costs a small fraction of one per cent of producing are true of M1 and of M2 at realistic problem sizes — one Freivalds round at $n = 4096$ costs roughly seven parts in ten thousand of production ($3/4096$), and twenty rounds at soundness $2^{-20}$ cost about $1.5 \times 10^{-2}$, which is outside the M2 band. The band therefore admits MATMUL_4096 under Freivalds only at $k \leq 13$ rounds ($`\approx 9.5 \times 10^{-3}`$, soundness $2^{-13}$) or under the large-field single-round variant, and the registry entry must say which; larger $n$ relaxes the constraint linearly. “Two parts in ten thousand” would be $1/n$, which counts one matrix–vector product where the check needs three. The claims are false of M3 and of the aggregate ceiling. Any statement of the form “checking costs one ten-thousandth of producing” is a claim about succinct verification specifically and must name the modality wherever it appears, in this document and in every derivative artifact. The looser figure was never wrong as a floor. It was wrong as a description, and it was quoted as a description.

Canonical Workloads and Proof Types

To avoid an unbounded zoo of bespoke proofs, Layer 4 maintains canonical workloads:

• MatMul($n, k, m; \varepsilon_r$) – matrix multiplication at specified dimensions and componentwise relative error bound.

• Inference($M, X$; policy) – run model $M$ on input $X$ under constraints.

• Provenance($C$, chain) – provenance chain for content type $C$.

• Settlement($S$, policy) – settlement and refund logic for a corridor.

For each canonical workload, the stack defines:

• Circuits / arithmetization: how the workload is represented for proving systems.

• Proof schemas: which proof systems are supported.

• Verification modality: M1, M2, or M3 (Chapter 22: Layer 4: Truth & Work); a computation that can be checked under two modalities is registered as two SKUs, never as one SKU carrying both.

• SLO tiers: latency and assurance classes (Chapter 22: Layer 4: Truth & Work).

Canonical workloads matter economically:

• They become the SKUs for proof and compute markets.

• Work Credits are sold against committed capacity for units of these workloads.

• VerifyPrice and $r(W)$ are tracked per workload and tier.

Every SKU this document names lives in one table, the workload registry of Chapter 22: Layer 4: Truth & Work; the definition template, the starter set (Chapter 22: Layer 4: Truth & Work), the constitutional SLO table (Chapter 22: Layer 4: Truth & Work), and the primitive catalog (Chapter 24: The Modular Stack) all point at it rather than carrying their own lists.

The precedent for standardized work.

The requirement that demand standardize into canonical units before it can become an economic object has a long pedigree, and it is worth naming because it is easy to mistake for an engineering preference. The standardization thesis in the print literature [Eisenstein 1979] documents the sequence: typographic uniformity—every letter identical to every other letter of its kind, modular, movable, recombinable—was daily practice at scale for roughly three centuries before the machine shop embodied the same template in screws, gauges, and interchangeable parts. The claim is causal and well-documented as mechanism: standardization of the cognitive module preceded and enabled standardization of the physical one. The stronger claim—that industrialization was possible only because of movable type—is not adopted here. The analogy to this layer is exact at the level of function: canonical workloads and PIDL receipts are what make two providers’ units of work identical, comparable, and combinable; diffuse demand for “compute” becomes an economic unit only when the units are interchangeable. The registry is the type case; the receipt is the printed page.

Canonical Workload Definition Template

For a workload to become a tradable SKU (and eligible for Work Credit issuance), it must be defined precisely enough that two providers’ units are interchangeable—and that is the whole reason this template exists. Free-form compute cannot be a unit of account. If one vendor’s “matmul” means fixed dimensions under a relative error bound and another’s means whatever their kernel happens to produce, no counterparty can compare the two, no market can price them, and no registry can mint against them. The template fixes the fields that turn work into a unit: what is claimed, what is public, what is private, what gets checked, what it costs to check, and where it may run.

One field deserves to be stated in the open rather than left inside a parenthesis, because two natural drafts of this template get it wrong in opposite directions. The error bound is relative, componentwise, and normalized to the operands that produced each entry — never absolute, and never a matrix-norm inequality. An absolute bound fails honest provers: standard BLAS kernels reorder floating-point arithmetic, and the discrepancy that reordering introduces grows with the magnitude of the operands, so a correct product computed by a different honest kernel would still fail the test. A matrix-norm bound fails in the other direction. Written as $\|C - A \cdot B\|_\infty \leq \varepsilon_r \|A\|_\infty \|B\|_\infty$ with the matrix $\infty$-norm (maximum row sum), the right-hand side is a per-row budget of order $\varepsilon_r \cdot n^{2} \cdot \mathbb{E}|a|\,\mathbb{E}|b|$. At $n = 4096$ on i.i.d. Gaussian FP32 inputs with $\varepsilon_r = 10^{-3}$ that budget is about $1.16 \times 10^{4}$ against an honest FP32 error of $0.23$: a product computed from INT8-quantized inputs errs by about $3.97 \times 10^{3}$ and passes, and a single output entry corrupted by about $1.05 \times 10^{4}$ (typical $|C_{ij}| \approx 64$) also passes. A bound that admits the next-cheaper precision class and a two-hundred-fold corruption of one entry is not an acceptance test; it is a formality. The correct form is the componentwise backward-error bound of floating-point analysis [Higham 2002] (Higham, Accuracy and Stability of Numerical Algorithms):

$$|C_{ij} - (A \cdot B)_{ij}| \;\leq\; \varepsilon_r \sum_{k} |A_{ik}|\,|B_{kj}| \quad \text{for every } (i,j),$$

with $\varepsilon_r$ set from the pinned reference kernel’s precision — $\varepsilon_r \approx 10^{-5}$ for strict FP32 accumulation — and calibrated so that the next-cheaper precision class the template forbids (TF32, FP16, INT8) fails. The relative componentwise bound forgives honest implementations and still fails results that are actually wrong, entry by entry. Strict with dishonesty, tolerant of implementation—that is the register the entire template is written in, and a bound has to be tested against dishonesty before it earns the register: every workload registration ships an adversarial acceptance suite (INT8 input substitution, single-entry corruption, row zeroing, precision downgrade of the accumulator) that the bound must reject, and a registration whose bound passes any of them is returned.

Canonical Workload Definition Template

WorkloadID: Unique identifier from the registry of Chapter 22: Layer 4: Truth & Work (e.g., MATMUL_4096_FP32_FREIVALDS, MATMUL_4096_FP32_SNARK, INFER_LM_70B_256TOK). One ID names one modality; the same computation under a second modality is a second ID.

Statement: What is being proved (natural language + formal predicate)

• Example: “The matrix product $C = A \times B$ was computed correctly, where $A, B \in \mathbb{R}^{4096 \times 4096}$, and $|C_{ij} - (A \cdot B)_{ij}| \leq \varepsilon_r \sum_k |A_{ik}|\,|B_{kj}|$ for every $(i,j)$” — the componentwise, scale-normalized bound of Chapter 22: Layer 4: Truth & Work. Neither an absolute bound nor a matrix-norm bound is the template’s form: the first fails honest BLAS kernels, the second admits INT8 execution.

Public Inputs:

• Commitment to $A$, $B$ (hash or Merkle root)

• Claimed result commitment (hash of $C$)

• Error bound $\varepsilon_r$ and the reference kernel ID that sets it

• Timestamp range

Private Inputs (Witness):

• Full matrices $A$, $B$, $C$

• Intermediate computation trace (if required by proof system)

What Is Verified:

• Correctness (computation matches claim)

• Bounds (result within specified limits)

• Freshness (timestamp within allowed window)

• Liveness (proof generated within epoch, not precomputed)

Adversarial Acceptance Suite: the named set of dishonest transcripts the acceptance test must reject (for MatMul: INT8 input substitution, TF32/FP16 accumulation, single-entry corruption, row zeroing). Registration is refused while any suite member passes.

Verifier Complexity Class:

• Time: two regimes, and the registry entry must say which it prices. Succinct-proof (M1) workloads verify in $O(\log n)$ after the committed output is in hand; Freivalds-style (M2) audit workloads verify in $O(n^2)$ — reading and hashing the committed operands, then $k$ matrix–vector rounds — but avoid the $O(n^3)$ recompute. The template’s complexity field names the regime. A computation checkable in both regimes is two SKUs with two entries (MATMUL_4096_FP32_FREIVALDS and MATMUL_4096_FP32_SNARK in Chapter 22: Layer 4: Truth & Work); an entry never publishes both regimes under one ID, because the two have different modalities, tiers, and prices.

• Memory: specified peak (e.g., $\leq$512MB for Laptop-Class)

• Proof size: max allowed (e.g., $\leq$1MB)

Policy Hooks: (machine-verifiable predicates)

• Hardware profile requirements: the minimum grade in the Allowed Hardware Profiles field below (L0-A by default), with a higher floor named per SLO tier where the entry requires one (e.g., L0-B or higher for the Gold latency tier)

• Prover stake requirements

• Membership/non-membership predicates (allowlist proofs, not graph inspection)

Allowed Hardware Profiles:

• L0-A: Yes (with issuance weight 0.9$\times$)

• L0-B: Yes (1.0$\times$)

• L0-C/D: Yes (1.0$\times$; open-hardware premium via collateral grade and routing priority, never via issuance above delivered work)

SLA Tiers: Latency and Assurance

The obvious tier table — Bronze/Silver/Gold at 60 s/10 s/2 s prove-side latency with $1\times$/$2\times$/$3\times$ verification — prices the wrong thing. “$3\times$ verification + audit” is replication: modality M3 in the taxonomy of Chapter 22: Layer 4: Truth & Work, the one modality that carries no monetary mechanism. A 2 s prove-side target is reachable today only under M2 or M3, because succinct (M1) proving of any workload in the registry runs minutes to hours on current provers. Its highest-fee tier would therefore rest on the least monetary modality and reward provers for choosing it. Latency and assurance are separate goods with separate prices, and the tiers are two orthogonal axes: a latency tier that prices how fast the attested result arrives, and an assurance tier that prices how it was verified. A quote names one of each.

Latency tiers for canonical workloads. The target is the prove-side time to produce the attested result (generation plus attestation or proof), not verify-side time: verification SLOs are constitutional and set separately in Chapter 22: Layer 4: Truth & Work, and no prove-side tier can relax them. Gold is attainable today only with M2 or M3 assurance; an M1 quote at Gold latency is refused by the registry until a prover benchmark on record supports it.

Assurance tiers for canonical workloads, indexed by verification modality (Chapter 22: Layer 4: Truth & Work). The highest multiplier attaches to the modality that carries the monetary mechanism, and its latency promise is whatever current provers can honestly meet. A quote’s total multiplier is the product of its latency and assurance multipliers.

Example: MATMUL_4096_FP32, two SKUs

The same computation is registered twice, because it is checkable under two modalities and the two are different goods.

Why this matters: Without this template, “canonical workload” risks becoming “whatever the prover says it is.” With it, workloads are precisely specified (anyone can implement a conforming prover/verifier), auditable (claims can be checked against the template), and tradable (markets can price and exchange standardized units).

Workload Registry

A registry that is quoted three ways is not a registry. Chapter 22: Layer 4: Truth & Work is the single table; every other mention of a SKU in this document is a pointer into it, and an identifier that does not appear here is not a canonical workload.

PoUW Design Patterns

Layer 4 does not pick a single consensus recipe. It supports several proof-of-useful-work patterns, as long as they satisfy:

• Open admission: commodity participants can join.

• Unpredictable leader election: no one can cheaply bias the lottery.

• Useful work binding: you cannot precompute offline or reuse stale work.

• Proof quality & anti-spam: junk proofs cannot flood the system without penalty.

Pattern 1: Hash-gated useful work

• Miners perform a cheap hash race; crossing a threshold gives short-lived eligibility.

• To produce a valid block, the miner attaches a PoUW artifact seeded from header randomness.

Pattern 2: Proof-first selection

• Provers race to produce useful-work proofs and post them to a mempool.

• A lightweight mechanism selects which proofs get included and rewarded.

Both patterns are compatible with MatMul-PoUW, Inference-PoUW, and hybrid schemes.

The Usefulness–Unpredictability Dilemma

Neither pattern resolves the problem that sits under every proof-of-useful-work design, and this document has until now stated the problem’s two halves in separate places as though each were solved. It is one problem, it is open, and it should be named as such.

A work function must be unpredictable to secure consensus: if the input is known in advance, a miner can precompute and the lottery is not a lottery (property P1 below). A work function must be useful to have a buyer: someone must want the result of this input, not a random one. The two requirements pull on the same field of the block. Header-seeded inputs — Pattern 1 as written — are unpredictable and useless: nobody buys the product of two matrices drawn from a block hash, so the “useful” work is heat with better branding, and the demand curve the thesis relies on (Chapter 22: Layer 4: Truth & Work) does not exist for it. Client-supplied inputs — the only kind a buyer pays for — are predictable to whoever supplied them: a client and a miner who are the same party, or who collude, can precompute the work, submit it as fresh, and bias the lottery by exactly the amount P1 forbids. The hybrid designs — random-seeded verification challenges layered on client work, in the manner of Ambient’s proof-of-logits [Ambient 2024] — move the randomness from the input to the audit: the client’s input is taken as given and the header seeds which slices of the work get checked. That is the right shape, and it is not a solution until it comes with a stated collusion bound: for a client–miner coalition controlling fraction $\phi$ of demand and fraction $\theta$ of hashrate, what reward advantage does it obtain, and under what audit rate does that advantage fall below the grinding tolerance $\delta$ of P2? No design this document cites publishes that bound.

This is the flagship research problem for a build lab, and it is stated here as one rather than folded into an engineering table. Verification asymmetry is a theorem [Freivalds 1977] and is not the hard part. The hard part is making the work simultaneously worth buying and worth mining, and the honest current status is: unsolved, with a promising shape and no proof. Until a hybrid design carries a collusion bound, MatMul-PoUW and Inference-PoUW secure the service market (Work Credits sold against reserved capacity and extinguished by delivered, verified work) and do not by themselves secure consensus; the consensus role remains a conjecture in Chapter 22: Layer 4: Truth & Work, and the starter-set rows inherit that label.

PoUW Security Properties (Must Hold)

P1. Precomputation Resistance: Proofs seeded by unpredictable randomness; valid only for $N \leq 10$ blocks after seed.

P2. Grinding Resistance: Attacker with $X\%$ hashrate gains at most $(1+\delta) \cdot X\%$ rewards, where $\delta \leq 0.1$.

P3. Network Advantage Bound: p95 propagation delay $\leq 2$s for proof announcements.

P4. Spam Resistance: Deposit $\geq 10\times$ expected verification cost; 100% slash for invalid proofs.

P5. Cartel Detection: Top-1 share $< 20\%$; Top-5 share $< 50\%$; entry latency $\leq 7$ days.

P6. Useful Work Binding: $\geq 10\%$ of proofs independently re-verified by random auditors.

Research Maturity Labels:

PoUW component research maturity.

Implication for service claims: The “AI Money” label is an analytical lens on verified-compute demand, not an instrument classification. As components mature from Experimental to Production, inference Work Credits can receive stronger assurance grades and smaller service haircuts. Their issuance remains separate from the base-asset monetary constitution (see Tier taxonomy in Chapter 24: The Modular Stack).

Verification type and typed service-claim eligibility.

Proof Factories and PaL

Most developers do not want to think about circuits; they want to say:

“Prove that this computation happened, then get me a receipt and pay whoever did the proving.”

Layer 4 provides this via:

• Proof factories: infrastructure clusters specialized in generating proofs.

• Proofs-as-a-Library (PaL): an SDK that compiles high-level claims into proofs.

PaL exposes interfaces like:

prove_compute(f, inputs, policy)
prove_provenance(asset_id, lineage)
prove_settlement(tx, corridor_policy)

Under the hood, PaL:

1. Maps the request to a canonical workload $W$.

2. Selects suitable proof systems and hardware profiles.

3. Submits the job via neutral routers to proof factories.

4. Returns a PIDL receipt plus a proof artifact.

VerifyPrice Observatory

Verification asymmetry is a design goal; VerifyPrice turns it into a dashboard.

The VerifyPrice observatory continuously measures:

• p50/p95 verify times,

• estimated energy per verification,

• failure rates and mismatch rates,

• diversity metrics (how many independent verifiers are actually checking).

Reference Verifier Classes:

Reference verifier classes for VerifyPrice measurement.

VerifyPrice Measurement Specification

VerifyPrice is a service-assurance KPI and one necessary input to the base asset’s conditional monetary test. It determines whether Work Credits retain a verifiable service proposition; it does not make them monetary. That requires a rigorous measurement harness, not just a dashboard slogan.

The harness exists because the observatory is not a disinterested instrument. It is a publisher with interests, run by operators who can be pressured, and the numbers it publishes are exactly the kind a protocol under strain would prefer not to publish. Assume the observatory is fallible, and further assume it is adversarially fallible—inclined toward flattering measurements when the truth is inconvenient. The specification below is not written to make the observatory honest. It is written so that when the observatory lies, anyone can catch it: the samplers are named, the harness is open, the raw data is archived, and independent operators run the same tests on the same proofs. A lie has to survive all of that. The spec does not produce trust in the measurement; it produces detection of the absence of it.

Input View (What the Harness Records):

VerifyPrice has exactly one definition: the canonical five-field tuple of Appendix A: Formal Model of Verification Asymmetry & VerifyPrice, introduced at Chapter 22: Layer 4: Truth & Work,

$$\text{VerifyPrice}(W) = (p_{50,t},\ p_{95,t},\ p_{50,c},\ p_{95,c},\ \text{fail}).$$

Tuples that resemble it, here and in Chapter 26: Extended Telemetry, are the harness’s inputs, not rival definitions wearing the output’s name. What the harness records, per run, for workload $W$ on verifier class $V$, is the input view:

$$\text{Inputs}(W, V) \ni (t_{\text{run}},\ e_{\text{run}},\ m_{\text{run}},\ b_{\text{run}},\ \text{outcome}_{\text{run}})$$

Where:

• $t_{\text{run}}$: verification time (seconds); $p_{50,t}$ and $p_{95,t}$ are its percentiles over the window

• $e_{\text{run}}$: energy per verification (Joules, measured via hardware counters or watt-meter); enters $c_{\text{run}}$ below

• $m_{\text{run}}$: peak memory (MB) — published, not priced: a run exceeding the registry entry’s memory ceiling is recorded as a failure and lands in $\text{fail}$; observed peak is published beside the tuple

• $b_{\text{run}}$: bandwidth consumed (bytes) — published, not priced, on the same rule as memory

• $\text{outcome}_{\text{run}}$: pass, or a failure code (timeout, invalid proof rejected, crash, resource ceiling exceeded); $\text{fail}$ is the failure fraction

USD cost is derived per run, then percentiled: $c_{\text{run}} = \dfrac{e_{\text{run}}}{3.6 \times 10^{6}} \times p_{\text{energy}} + t_{\text{run}} \times p_{\text{opp}}$, where $e_{\text{run}}$ is the run’s measured energy in Joules, $p_{\text{energy}}$ is the reference energy price (USD 0.10/kWh, so the first term divides by $3.6\times10^{6}$ J/kWh), and $p_{\text{opp}}$ is opportunity cost (USD 0.001/s), both published quarterly. The cost percentiles of the canonical tuple — $p_{50,c}$ and $p_{95,c}$ — are the percentiles of $c_{\text{run}}$ across the measurement window, never recomputed from percentile inputs; in particular, deriving a cost figure from $t_{95}$ alone is not the construction.

Verifier Implementations:

Verifier implementation requirements.

Sampling Methodology:

• Random selection: Proofs selected uniformly at random from recent submissions (not cherry-picked).

• Stratified by region/profile: Measurements cover $\geq$10 regions and $\geq$3 hardware profiles per workload.

• Adversarial corpus: 10% of test proofs are malformed or worst-case (max witness size, pathological inputs) to measure failure handling.

• Continuous measurement: Not periodic snapshots; rolling 24-hour windows published hourly.

Adversarial Conditions:

Adversarial conditions for VerifyPrice testing.

Reproducibility Standard:

• Benchmark harness: Open-source, versioned, deterministic. Anyone can run the same tests.

• Signed results: Each measurement batch is signed by $\geq$2 independent measurement operators.

• Divergence alerts: If independent operators diverge by $>$5%, investigation triggered.

• Archived raw data: All proof samples and timing logs archived for 1 year.

Why this matters: Without this spec, “VerifyPrice observatory” is an oracle claim. With it, VerifyPrice becomes reproducible consensus—any skeptic can run the harness, check the measurements, and falsify the dashboard if it is wrong.

Real-Resource VerifyPrice SLOs (Constitutional):

Constitutional VerifyPrice targets, banded by modality. The band is not decoration: M1 verification, once the proof is wrapped, is milliseconds independent of model size, and M3 verification of a language model is running the language model, so a single “INFER_LM_7B $\leq 30$s” row was either an M1 promise no prover can yet keep or an M3 promise no laptop can keep. Rows marked “registry target” are published so the destination is public; placing them in the constitutional set as though they were deliverable would trip Red Line 1 on publication day, and they become constitutional only when the maturity gate of Chapter 22: Layer 4: Truth & Work lifts for their component. Where the reference class is Server-Class, the Laptop-Class figure is still published.

VerifyPrice in Practice

At the North-Star level, VerifyPrice answers a simple allocator question:

“If I hold this asset for a cycle, does one unit still buy at least as much verification as it used to?”

VerifyPrice matters in three dimensions, designed to avoid circular reasoning:

The Constitutional SLO Band

These are non-negotiable targets, measured in real resources on reference hardware. They are exogenous to token price. Whether the token rallies or dumps, these targets must hold. If verification takes 30s on a laptop, the “anyone can verify” promise is broken. The table below is the one referenced as Chapter 22: Layer 4: Truth & Work’s SLO band; the measurement specification that produces its inputs is Chapter 22: Layer 4: Truth & Work.

What “Exogenous” Does and Does Not Cover

Exogeneity to token price is the property needed here, and it is the one being claimed: the target must not be redefined because the market moved.

It is not exogeneity to everything. Measuring in real resources on reference hardware makes these SLOs dependent on two conditions a state can adjust—whether unprivileged reference hardware remains obtainable, and what power costs at the edge and at the prover. Both are policy surfaces (Chapter 5: Threat Model).

The consequence is that Red Line 1, the thesis’s hinge, is externally triggerable. This is monitored upstream via sovereign optionality (Chapter 17: Layer 0: Verifiable Machines & Energy) and Red Line 13 rather than left to be discovered at the hinge. Chapter 17: Layer 0: Verifiable Machines & Energy separates the verification-side exposure (hardware obtainability) from the proving-side exposure (bulk energy), which behave differently and should not be conflated.

There is also a reason the exogeneity requirement runs deeper than engineering preference. If the framing of Chapter 2: The Failure of Soft Guarantees is right that a medium restructures only those who habituate to it, then verification must be cheap enough to become a habit before it can become anything else. If its cost tracks the token’s price, habit never forms, and neither does whatever the habit would have built. The SLO is not a performance target; it is the precondition of the medium having any effect at all.

Protocol Affordability SLOs (Operational)

These measure whether verification remains affordable as a fraction of typical transaction costs:

$$\text{AffordabilityRatio}(W) = \frac{\text{VerifyCost}(W)}{\text{MedianFee}(W)}$$

• Target: AffordabilityRatio $\leq 5\%$ for all workload classes.

• Settlement: Verification cost $\leq 1\%$ of median transaction value.

Read the denominator before celebrating the ratio.

The ratio improves in two ways: verification gets cheaper, or the fee gets bigger. A protocol that raises $\text{MedianFee}(W)$ passes this SLO while becoming less affordable to use, so the ratio must never be published without its components, and a falling ratio driven by a rising denominator is a deterioration wearing an improvement’s clothes. The settlement variant has the mirrored exposure: if median transaction value is measured in token terms, appreciation mechanically lowers the ratio and re-imports token price through the back door — the exact circularity the physical SLOs exist to exclude. Three guards hold the family honest, each of a different kind. The first is component disclosure: the fee-based ratio is always published alongside the fee level itself, so a denominator-driven improvement is visible on inspection. The second is a unit convention: the settlement ratio is computed on USD-referenced transaction value, never token-referenced. The third is a monotonicity rule: the affordability SLO is credited only when the ratio falls while the fee level is flat or falling, and improvements achieved on a rising fee are reported as neutral, not as passes. The affordability family is operational, not constitutional, and these guards are why it stays that way honestly.

Token-Quoted VerifyPrice (Market Signal, Not Target)

Token-quoted VerifyPrice is a useful market signal, but not a constitutional target. For a scalar reading, fix a single reference workload $W^{\ast}$ and take the cost-percentile field only, with the fee schedule expressed as a fixed token quantity:

$$\text{VerifyPower}(\text{token}; W^{\ast}) = \frac{q_{\text{fee}}(W^{\ast}) \cdot P_X}{p_{50,c}(W^{\ast})}$$

where $q_{\text{fee}}(W^{\ast})$ is the fee schedule for $W^{\ast}$ denominated in units of the native asset $X$, and $P_X$ is the asset’s USD reference price at the observation — so the signal carries the token price explicitly on the right-hand side, which is what makes it a market signal rather than a disguised operational one. A vector has no reciprocal; the scalar must be constructed by naming the workload and the field. Which workload is the reference is a publication choice, not a free parameter — it is declared, pinned, and changed only with notice, so the signal cannot be dressed by re-picking $W^{\ast}$. Note the family relationship: this quantity is the token-side image of the AffordabilityRatio, and the two must be published together so neither is read alone; the affordability ratio is the operational SLO, this is its purchasing-power translation.

Token price is endogenous. Making this a target creates circular reasoning. The protocol commits to real-resource SLOs and affordability ratios. Token-quoted metrics are dashboards for market participants, not governance constraints.

SLO Hierarchy:

Physical VerifyPrice: Auditing the Infrastructure Behind a Workload

Note on terminology: Chapter 22: Layer 4: Truth & Work names the constitutional cost band on verifying a proof or compute claim in real resources on reference hardware the Real-Resource VerifyPrice SLO. This section introduces the metric that carries the name “Physical VerifyPrice” alone: the cost of verifying the physical infrastructure claims (energy, hardware, jurisdiction) behind that proof or compute claim, i.e., the Facility Capacity Receipts introduced in Chapter 17: Layer 0: Verifiable Machines & Energy.

VerifyPrice tells us whether a proof or compute claim is cheap to check. Physical VerifyPrice tells us whether the physical claims behind that proof are cheap to audit. A Work Credit cannot be high-assurance if verifying the proof takes seconds but verifying the facility, hardware profile, energy receipt, and jurisdictional risk takes months of trust-the-vendor diligence.

Concretely, Physical VerifyPrice asks:

• Can an allocator verify the facility’s claimed energy profile?

• Can an auditor verify outage and curtailment history?

• Can the network verify that the hardware profile was not silently substituted?

• Can a user verify that compute was not routed through a sanctioned or coerced jurisdiction?

Physical VerifyPrice

The time, cost, and confidence required to verify the physical infrastructure claims (energy, hardware, jurisdiction) behind a unit of verified work.

For each facility profile, the stack should publish p50/p95 time and cost to verify FCR claims, sampling frequency, third-party challenge success rates, and unresolved discrepancy counts. If Physical VerifyPrice rises above threshold, credits from that facility receive reduced issuance weights or issuance caps (Chapter 25: Layer 6: Governance & Telemetry). This metric is formalized alongside the VerifyPrice model in Appendix A: Formal Model of Verification Asymmetry & VerifyPrice.

Layer-4 Stress Tests

Layer 4 passes its SoV audition if it survives several adversarial scenarios:

Circuit bloat.
Can we detect when proofs become too expensive to verify? Is there a migration path to leaner circuits?

Prover cartel.
Can neutral routers and SLA/slashing mechanisms prevent a small set of proof factories from monopolizing high-value workloads?

Proof system break / new attack.
Can we deprecate a proof system, rotate to alternatives, and quarantine affected Work Credits?

Delegation depth (joint completion).
The VerifyPrice SLO reads on one verification. A delegated task is a tree of them (Chapter 7: The Delegation Economy: Who Buys Verification), and a tree’s tail is not the tail of any one of its hops. Does a deep tree still complete inside its refund window?

Why the single-verify SLO does not cover a tree.

Take a task that fans out to $k$ children at each of $d$ levels, every hop returning a receipt its parent verifies. The tree has $N = (k^{d+1}-k)/(k-1)$ hops; a parent cannot accept until its slowest child has returned, and the levels run in sequence. Two consequences follow from arithmetic alone. First, the tree’s completion time is governed by the far tail of the single-verification distribution, not by its p95: with hops treated as independent, the chance that all $N$ land inside their individual $p_{95}$ is $0.95^{N}$, which for the reference tree below is of order $10^{-8}$. What matters is the p99.9 and beyond, which the canonical tuple does not publish. Second, failure compounds: at the reference failure SLO of $0.1\%$ per verification, a 340-hop tree completes with no failed hop about $71\%$ of the time, so roughly three trees in ten exercise a retry or a refund path somewhere. Independence is the favorable assumption. Under the common-cause scenarios of Chapter 17: Layer 0: Verifiable Machines & Energy hops fail together, and the tree aborts more often than the product says.

Scenario.

For a published reference tree—$(d,k) = (4,4)$, 256 leaves and 340 hops, chosen as a first reference and not as a threshold—report, for each canonical workload and under each Layer 0 disruption scenario already specified: the p50 and p95 completion time of the whole tree on Laptop-class verifiers; the probability that the tree completes before its outermost refund window closes; and the hop or settlement edge whose failure aborts the most leaves. Publish the three beside $t_{95}$ on the Proof & Compute Board. No SLO is set on any of them in this version; the purpose is to find out whether the single-verify SLO is the binding one for the workloads that delegation would generate, before anyone assumes it is.

If Layer 4 remains cheap to verify, open to participate, and instrumented enough to handle change, then Proofs and Compute deservedly move closer to “monetary primitive” rather than “platform feature.”

Minimum Viable Layer-4 Economy

Canonical Workload Starter Set:

The starter set is the subset of the registry (Chapter 22: Layer 4: Truth & Work) that a minimum viable Layer-4 economy launches with. Identifiers are the registry’s; the columns here are the ones a market maker reads.

Canonical workload starter set, drawn from Chapter 22: Layer 4: Truth & Work. Two target levels are distinct by design and must not be read as one: the constitutional floor (Chapter 22: Layer 4: Truth & Work SLO table) is the minimum a network must hold to remain constitutional, while this starter-set target is the commercial bar the registry holds itself to for the named SKU. Where the two coincide, as they now do for the inference row, it is because the constitutional table was rebanded by modality and the earlier “$\leq 10$s” commercial figure for a 7B re-execution on Laptop-Class was not a target any verifier could meet. WC tiers shown are the ceiling each workload can reach once its verification component is Production-mature; current effective tier is the lower of the ceiling and the maturity-gated tier (Chapter 22: Layer 4: Truth & Work tier rules). The _SNARK SKU is listed so the M1 destination for matrix work is public; it issues nothing until a production prover exists.

Maturity gate.

No workload may issue Tier A (full-weight, pristine-collateral) Work Credits while the maturity label of its verification component (Chapter 22: Layer 4: Truth & Work) is Experimental or Pilot. Until a component reaches Production, its workloads issue at Tier B or below regardless of the mathematical tier their proof type would support. As of this writing that gate is binding on every PoUW-based row in the starter set: MatMul-PoUW consensus security is a conjecture (the verification asymmetry itself is Freivalds’ theorem [Freivalds 1977] and is not what the gate reads on; Chapter 22: Layer 4: Truth & Work), succinct MatMul proving is research, inference PoUW is pilot-stage, and pricing pristine collateral over any of them would define a AAA rating on an instrument whose proof system has not survived production. For starter-set rows whose verification component does not appear in Chapter 22: Layer 4: Truth & Work at all (PROOF_2^20, PROVENANCE_MEDIA_V1, SETTLE_ATOMIC_BTC_XMR_V1), the gate reads on the maturity of the underlying proof system family — generic succinct proofs, provenance attestation, atomic-swap verification — each of which the maturity table tracks at the family level; a family not yet tracked is treated as Pilot until it is. The gate lifts only when the maturity table lifts, and the maturity table is moved by deployment evidence, not by argument.

Tier Rules for Work Credit Issuance:

Work Credit issuance tiers.

Fee + Burn + Slashing Logic:

• 70% of fee to capacity providers and their delegating stakers (reward)

• 20% retired (a pro-rata buyback; net-issuance arithmetic, not moneyness)

• 10% to the assurance budget (Layer 0 sampling, audits, security review)

This is the reference-design partition pinned in Chapter 25: Layer 6: Governance & Telemetry. Its 20% burn share is a deliberately conservative variant of the 30–50% band in Chapter 8: The Triad and the Monetary Candidate: the reference design also funds an assurance budget, so the three shares are set to sum to 100%. The band remains the design space; a 20% burn is the harder case for the value-capture claim, not the easier one.

Fee formula (reference):

$$F(W) = \text{BaseFee}(W) \times (1 + \text{CongestionMultiplier}) \times \text{SLATierMultiplier}$$

Layer 4 turns work into truth. Layer 5 turns truth into money movement.

It is the layer where balances change, salaries get paid, cross-asset swaps execute, and collateral gets posted or released.

The constraints are harsh:

Repression-resilience.
Default assumption: yield-curve control, capital controls, KYC chokepoints.

Privacy & lawfulness.
Users need privacy by default and auditability by consent.

Non-custodial safety.
Settlement protocols must be self-custodial and refund-safe.

Privacy Rails and Lawful Obligations

Privacy rails are designed for lawful confidentiality and user-controlled disclosure; they are not framed as tools for evading legal obligations. Some regulatory demands may be incompatible with privacy-preserving systems; in those cases, the protocol acknowledges the tension rather than promising universal compliance. See Chapter 27: Legal, Policy, and Jurisdictional Posture for the full legal posture.

Settlement as a First-Class Workload

The stack treats settlement itself as a canonical workload:

• Workload type Settlement(S, policy) includes chain(s) involved, transfer size, corridor routing, and policy hooks.

• Proofs at Layer 4 can attest that settlement followed policy and the final state matches expectations.

This means:

• Layer 5 is not “just payments”; it is a proven computation over state transitions.

• Settlement events generate PIDL receipts that can be audited, archived, or collateralized.

Design Constraints for Privacy Rails

Privacy rails must satisfy a tight triangle:

1. Non-custodial. Users never relinquish both principal and unilateral control to intermediaries. Adaptor signatures, HTLC-like constructs, or scriptless scripts enforce this.

2. Refund-safe. If a swap fails, no party loses value, and every party has a unilateral no-loss exit within bounded time — an exit that may be a refund of its own leg or a claim on the counterparty’s, depending on which side of the protocol it stands on (Chapter 23: Layer 5: Value & Settlement). Refund logic is testable and provable.

3. Privacy-by-default with optional disclosure. Default flows have strong anonymity sets; viewing keys allow specific flows to be revealed.

This is where the Privacy Rails Kit (PRK) lives.

Policy = Predicates, Not Surveillance

Policy compliance in Layer 5 is achieved through predicate proofs, not graph inspection.

What can be proved (ZK-compatible):

• Not on sanctions list $\to$ Membership proof: “sender $\in$ AML-cleared set $S$”

• Within limits $\to$ Range proof: “amount $\leq$ $10,000”

• Authorized counterparty $\to$ Set membership proof

• Tax reporting $\to$ Viewing key + receipt disclosure

What can be proved about one’s own inputs only:

• “None of my inputs to this transaction is in published exclusion set $E$” — provable as non-membership against a committed set, in the manner of Privacy-Pools association sets [Buterin et al. 2023]. The proof reaches exactly one hop: it says nothing about where those inputs came from before the prover held them.

What cannot be proved, and is not attempted:

• “Never interacted, at any distance, with blacklisted address $X$” — taint at distance requires global graph knowledge, and the protocol does not have it

• “Full transaction history disclosure” — defeats privacy model

• “Real-time surveillance feed” — centralizes and doxxes

The Privacy Rails Kit (PRK)

PRK is the Layer-5 sibling of PaL. It gives builders a way to express pay-for-proof and pay-for-compute intents and execute them over privacy-preserving, non-custodial corridors.

At a high level, PRK supports:

• BTC$\leftrightarrow$XMR corridors, and a gated BTC$\leftrightarrow$ZEC corridor. Using adaptor signatures, ensuring atomicity. Prior art is directly deployed for BTC$\leftrightarrow$XMR only: the Bitcoin–Monero atomic-swap protocol of Gugger (2020) and its production implementations (COMIT’s xmr-btc-swap [COMIT 2021], UnstoppableSwap [UnstoppableSwap 2025]) are the operative reference, and Chapter 23: Layer 5: Value & Settlement’s refund-safety invariants are stated so that such corridors can be certified against them rather than merely named. BTC$\leftrightarrow$shielded-ZEC adaptor-signature swaps do not exist in production. Transparent-ZEC HTLCs exist and forfeit privacy on the ZEC leg, which is the leg the corridor exists to protect; a shielded corridor requires scripting or adaptor constructions inside the shielded pool that Zcash does not currently offer [Hopwood et al. 2026]. Two routes between BTC and ZEC that are not atomic swaps do exist, and neither meets the constraints of Chapter 23: Layer 5: Value & Settlement. One wallet routes the purchase through an intents network in which market makers compete to fill the order, “settlement is enforced on-chain by smart contract”, and the ZEC is “deposited directly to a fresh shielded address”; the user first sends a deposit and names a refund address for a failed swap [Zodl Support 2026], so the exit runs through the service and is not unilateral in the sense of Chapter 23: Layer 5: Value & Settlement. A cross-chain liquidity network receives ZEC at a vault whose address is transparent and whose incoming viewing key it publishes [Maya Protocol 2026], and transparent transfers have the same privacy properties as Bitcoin’s [Hopwood et al. 2026]. Both routes are evidence of demand for the corridor, and the adaptor-signature gate stands. The ZEC corridor is therefore registered (Chapter 22: Layer 4: Truth & Work) and gated on that work: it is a design target, not a route, and nothing in this document counts it toward a minimum viable stack.

• Shielded pools and internal flows. For in-asset privacy with proofs for policy compliance. Outflows from each pool cannot exceed the value that entered it.

• Conditional payment flows. “Pay address A if proof P of workload W is posted within time T; else refund.”

PRK exposes intents like:

pay_for_proof(claim_id, max_price, corridor_policy)
execute_corridor(btc_input, xmr_output, privacy_policy)
batch_payroll(payroll_blob, corridor_set, audit_policy)

Settlement Safety: Refund and Bridge Invariants

Non-custodial rhetoric is cheap; invariants are not.

Refund Safety Invariant:

Refund safety is often stated as “both sides can unilaterally reclaim funds,” and the deployed prior art does not give that. The Gugger (2020) BTC$\leftrightarrow$XMR protocol gives no-loss-or-punish, which is asymmetric by construction: Monero has no scripting, so the XMR leg cannot time out on its own. If the BTC-side party goes offline past the refund window, the XMR is unrecoverable by either side and the protocol’s remedy is the punish path, which delivers the BTC to the XMR-side party. Nobody who acts within the window ends the swap poorer than they began it; the exits are not symmetric refunds. The invariant is therefore stated in the terms the protocol actually satisfies:

Refund Safety

A corridor $C$ is refund-safe if, for every transaction $T$ and every party $P$ to it, $P$ has a unilateral no-loss exit available within a bounded time $\tau_C$ from the moment $T$ leaves the happy path — an action $P$ can take without the counterparty’s cooperation after which $P$ holds value at least equal to what it committed (its own leg refunded, or the counterparty’s leg claimed). Formally,

$$\text{refundSafe}(T) = 1 \iff \bigl(T \text{ succeeds}\bigr) \;\lor\; \bigl(\forall P \in T:\ P \text{ exits without loss within } \tau_C\bigr).$$

Where:

• $\tau_C$ is bounded and published per corridor (e.g., $\leq 24$ hours for BTC$\leftrightarrow$XMR at current timelocks) and is the sum of the longest refund window and the longest confirmation delay on either chain. The XMR leg’s confirmation depth is set above 18 blocks, the depth of the September 2025 reorganization [Rucknium 2025]. The bound presumes chain liveness, each chain confirming an exit within that delay; a chain that halts, censors an exit, or reorganizes deeper than the published depth breaks the presumption, and the failure is classed under chain liveness, not under the user’s environment.

• An exit is unilateral if it requires no counterparty signature after the setup phase. Which exit a party holds (refund or punish) depends on which leg it stands on and is published in the corridor’s profile.

• Value is counted in units of the asset each party committed, with a claimed counterparty leg valued at the exchange rate fixed at setup, so a price move inside $\tau_C$ is market risk and not a refund failure.

• Success means both legs complete atomically.

• The metric $\text{refund\_safe}(C)$ of Chapter 23: Layer 5: Value & Settlement is computed over protocol-attributable failures: a party that has an available no-loss exit and fails to take it within $\tau_C$ (client offline, keys lost) is recorded under a root-cause class and does not count against the corridor, because a hard $1.0$ that trips on user liveness is a metric no corridor with humans on it can hold.

• The overall reading of the same metric is the user-outcome series. It drops the user-liveness assumption the protocol-attributable reading makes (that each party, or an agent acting for it, is online to take its exit within $\tau_C$), keeps every off-happy-path transaction in its denominator, and counts a party that had an exit and did not take it as a failure, published with the value lost and its root-cause class. The protocol-attributable split decides whether a failure belongs to the corridor; the user-outcome series reports whether the corridor’s users were protected, offline clients included.

Bridge Safety:

Cross-chain bridges were, in 2021–22, the single biggest loss vector in the industry. Layer 5 imposes:

• No unclassified signer sets. A small permissioned signer set is admissible only as Class B or Class C at the haircuts below, disclosed as such in the profile, and never presented as trustless. A slogan such as “no magic multisigs” beside a table that admits a 5-of-9 at a 10% haircut is rhetoric the table contradicts; the classification replaces the slogan, and the haircuts below are set to match it.

• Light-client or proof-based validation where possible.

• Explicit trust classifications reflected in profiles and telemetry.

Bridge trust classification. Liquid’s federation is a set of named functionaries running hardware signing modules; it is not bonded in the sense of posting slashable collateral, and the earlier “bonded” label is withdrawn.

An atomic swap is not a bridge — no asset is represented on a foreign chain, so there is nothing to classify — and the PRK corridors of Chapter 23: Layer 5: Value & Settlement are classified as corridors, not under this table. They carry Class-A-equivalent trust (cryptographic only), which is the reason the kit prefers a corridor to a bridge wherever both exist for a pair.

Rule: Class D custodial bridges are excluded from SoV backing. Assets held via Class D bridges do not count toward collateral or reserve calculations.

VerifySettle: Settlement Telemetry

VerifySettle tracks:

• Success rates across corridors (p50/p95, by size bucket).

• Refund outcomes — how often refunds are exercised and their timing.

• Anonymity-set health — shielded pool sizes, churn, volume.

• Concentration metrics — top-N LPs, corridor operators, jurisdictional spread.

Corridor Health SLOs:

VerifySettle corridor health SLOs.

Anonymity is measured per asset, because the assets hide differently.

A single “anon_set $\geq 1000$” was unreachable for one leg and trivial for the other. Monero’s anonymity is per-output: a ring of 16 today (FCMP++, which would make the effective set the whole output set, is on testnet with no mainnet activation date set as of this writing), so the meaningful metric is ring size times decoy quality — the fraction of rings whose decoys are indistinguishable from the real spend under the published heuristic set. Zcash’s anonymity is pool-wide: the shielded pool’s size times its spend churn over the window, so a pool of a million notes with no spends is a museum, not an anonymity set. The thresholds are:

• XMR leg: ring size at protocol minimum (16) with $\geq 95\%$ of corridor rings passing the decoy-quality heuristic; Sev-1 if decoy quality falls below $80\%$ for 30 days. A “$\geq 1000$” set is not a Monero quantity until FCMP++ ships, at which point the metric is revised to effective set size.

• ZEC leg (when the corridor is admissible): shielded-pool spend churn $\geq 1000$ distinct shielded spends per day on the pool the corridor uses (for a corridor on the Orchard protocol, the Ironwood pool from NU6.3, after which the Orchard pool “can only be spent from (not added to)” [Hopwood 2026]), with corridor volume $\leq 10\%$ of that churn so corridor notes do not stand out; Sev-1 if churn falls below 500 for 30 days.

• BTC leg: the btc_link metric above; Bitcoin has no anonymity set and the corridor’s job is not to make its BTC outputs distinguishable from ordinary spends.

Layer-5 Stress Tests

Layer 5 earns the label “Value & Settlement” if it can navigate:

On-/off-ramp strangling.
Can users still move value between BTC and privacy assets without centralized exchanges in country $C$? Do non-custodial corridors maintain $\geq 95\%$ success with no protocol-attributable loss?

Corridor LP exit.
If a major liquidity provider disappears, do corridors collapse, or does routing adapt?

Regulatory attack on privacy.
Can lawful-privacy corridors (viewing keys + receipts) keep enough demand to sustain anonymity sets when shielded assets are labeled “high risk”?

Minimum Viable Layer-5 Corridor

Disclosure Scope Model:

This is easily mistaken for a viewing-key scope model, and a viewing key cannot deliver the four scopes it requires. A shared viewing key is knowledge: once given it cannot be revoked, it reads every note the address ever receives rather than a time window, and it reveals every amount rather than only those above a threshold; and hierarchical derivation, whatever it is called, has a root. The scopes are real requirements, and each is met by a different mechanism — only one of which is a viewing key.

Disclosure scope model, with the mechanism that delivers each scope. A scope not on this list is not offered, and a viewing key is the mechanism for exactly one row.

Key management: Users generate and control all disclosure material. There is no revocation of a shared viewing key — it is knowledge, and knowledge is not recalled — so the operative discipline is forward rotation: receiving addresses and their incoming viewing keys rotate per epoch, a disclosed key exposes past epochs only, and future epochs are dark to every past auditee by construction. Derivation is hierarchical from a spending-key root the user holds; that root is a master key for its own tree, which is why it is never disclosed and why per-epoch keys, not the root, are the unit of disclosure.

Minimum Viable Corridor Spec:

Minimum viable corridor requirements. Admission thresholds are deliberately tighter than the Sev-1 thresholds of Chapter 23: Layer 5: Value & Settlement: a corridor enters default routing above the target band and is removed from it at the Sev-1 line, so that the two events are separated by a margin rather than a coin flip. Setting admission equal to Sev-1 would list corridors at the edge of removal.

Corridors failing the admission thresholds are flagged as “experimental” and excluded from default PRK routing; a listed corridor that crosses a Sev-1 line is handled by the incident path of Chapter 25: Layer 6: Governance & Telemetry.

Builders touch modules, and underneath each module the system enforces primitives. Parts III and IV described the stack layer by layer; this chapter turns the view to modules and primitives.

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, the network mints 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 Chapter 22: 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 Chapter 22: Layer 4: Truth & Work and the open problem of Chapter 22: Layer 4: Truth & Work.

   This is the Duplex-style substrate: when proofs from this kit clear, the network mints 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 provides:

   • 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. Commitments to a model’s internal state have run in production. TOPLOC hashes intermediate activations into “258 bytes of storage per 32 new tokens” and is reported by its authors as robust across GPU types and algebraic reorderings [Ong et al. 2025]; the INTELLECT-2 training run had each inference worker generate a TOPLOC proof “for every generated sequence”, checked by “a trusted validator node” [Prime Intellect Team 2025]. TOPLOC’s authors name one blind spot: the method “is not capable of detecting speculative decoding”, in which a provider decodes with a cheaper model and uses the larger one only for prefill [Ong et al. 2025]. That is model substitution in partial form, and the harness carries it as a named test case; the deployed precedent is a sampling check, since INTELLECT-2 inspects the logit distribution, which becomes bimodal when a smaller model generates and the larger one only prefills [Prime Intellect Team 2025].

3. Canonical workload registry — The dictionary of standardized SKUs for useful work, published as Chapter 22: 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 available by default. 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 Chapter 23: 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 (Chapter 23: 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 (Chapter 23: 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 incentive the receipt answers has a price, and the open-weight floor sets it. Open-weight capability is close enough to the proprietary frontier to be economically consequential (Chapter 33: The Closed Sovereign Stack), so a closed model’s price carries a premium over what a near-substitute costs to serve, and that spread is the payoff to serving the cheaper model behind the premium label: the wider the spread, the larger the payoff, and the endpoint does not show which model answered. Substitution need not be whole, either; a cheap model can decode behind a large one, which is the speculative-decoding case the verified-inference harness carries as a test (Chapter 24: The Modular Stack). The receipt’s model hash, checked by the audit and backed by the prover’s stake, is what turns the spread from a payoff into a risk, because payment is released against that receipt and not against the label.

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 providers sell them against committed capacity, and holds them as prepaid service inventory. Anyone can audit the backing: the credits are reservations on registry workloads whose providers, 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 providers commit capacity, the DAO buys the credits.

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 obligor, the reservation 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 agent-to-agent case: delegation escrow. Replace the treasury committee with a software agent and the forward purchase with a task, and the same rail becomes the hop of Chapter 7: The Delegation Economy: Who Buys Verification. A specification enters: a registry workload, acceptance criteria, a deadline, an assurance tier. A receipt leaves. Between them sits the SLA escrow primitive of Chapter 24: The Modular Stack, with payment and the child’s slashable bond both denominated in the base asset, released on a verifying receipt and refunded on timeout. Three commitments distinguish this from the committee’s case. Windows nest: a parent’s refund window must outlast the longest chain of its children’s windows plus its own verification, or a parent can be slashed for a delay it could not have prevented; the joint-completion scenario of Chapter 22: Layer 4: Truth & Work is the test. Escrow does not flow down the tree: a parent is paid only on its own verifying receipt, so it funds its children’s escrows from its own balance before it is paid. Working capital in the base asset therefore scales with the subtree an agent delegates, which is the operational reason a delegating agent holds a reserve at all (Chapter 7: The Delegation Economy: Who Buys Verification), and the reason a template shared by many such agents is a concentration worth measuring. The principal is proven, not named: the receipt may carry the optional principal_chain context (Appendix A: Formal Model of Verification Asymmetry & VerifyPrice) and the agent’s principal binding (Chapter 20: Layer 3: Identity & Claims), which is what lets the Principal Map (Chapter 26: Extended Telemetry) say whether the hop crossed a trust perimeter and whether a person can still revoke the agent that issued it. This is an extension of the present application and not a fifth one: it exercises Layer 3 where the committee’s case does not, reports additionally to the Agency Preservation Board, and would show, if it failed, that delegation between strangers is not operable on receipts alone.

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. Part V climbs to Layer 6 – Governance & Telemetry, where neutrality and repression-resilience are kept falsifiable, not just promised.