§19. Layer 4: Truth & Work

Jason St George. "§19. Layer 4: Truth & Work" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v3.1. /v/3.1/read/part-iv/19-layer-4/

Layer 4: Truth & Work

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 Isn’t)

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 §19: 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:

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 §10: Work Credits: Energy-Anchored Claims 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 §10: Work Credits: Energy-Anchored Claims, 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.

§10: Work Credits: Energy-Anchored Claims 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. 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 §14: Layer 0: Verifiable Machines & Energy already discounts positions by how legible their substrate is, and §10: Work Credits: Energy-Anchored Claims 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 should therefore be indexed on modality $\times$ grade, and the two should not be collapsed. A later pass owes the joint table; this document should not pretend it is there yet.

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 (§23: 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” and only the first is currently instrumented.

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. An earlier draft quoted “two parts in ten thousand” here, which is $1/n$ and 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 (§19: 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 (§19: Layer 4: Truth & Work).

Canonical workloads matter economically:

• They become the SKUs for proof and compute markets.

• Work Credits are minted against 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 §19: Layer 4: Truth & Work; the definition template, the starter set (§19: Layer 4: Truth & Work), the constitutional SLO table (§19: Layer 4: Truth & Work), and the primitive catalog (§21: 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, and this document carried one through v3.0. 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):

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 §19: 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 §19: 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 §19: 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 v3.0 draft published one three-row table — Bronze/Silver/Gold at 60 s/10 s/2 s prove-side latency with $1\times$/$2\times$/$3\times$ verification — and it priced the wrong thing. “$3\times$ verification + audit” is replication: modality M3 in the taxonomy of §19: 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. The highest-fee tier as written therefore rested on the least monetary modality and rewarded provers for choosing it. Latency and assurance are separate goods with separate prices, and the tiers are now 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 §19: 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 (§19: 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

Three lists in the v3.0 draft named workloads — the template’s examples, the starter set, and the primitive catalog — and no two agreed on the identifiers. A registry that is quoted three ways is not a registry. §19: Layer 4: Truth & Work is now 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 doesn’t 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 can’t precompute offline or reuse stale work.

• Proof quality & anti-spam: junk proofs can’t 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 (§19: 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 minted against delivered, verified work) and do not by themselves secure consensus; the consensus role remains a conjecture in §19: 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 §21: The Modular Stack).

Verification type and typed service-claim eligibility.

Proof Factories and PaL

Most developers don’t 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 §19: Layer 4: Truth & Work,

The v3.0 draft restated it here as a different five-tuple and again in §23: Extended Telemetry as a six-tuple, each introduced as the definition; those were the harness’s inputs wearing the output’s name. What the harness records, per run, for workload $W$ on verifier class $V$, is the input view:

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’s wrong.

Physical VerifyPrice SLOs (Constitutional):

Constitutional VerifyPrice targets, banded by modality. The band is not decoration: M1 verification 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 §19: 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?”

We care about VerifyPrice 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 §19: Layer 4: Truth & Work’s SLO band; the measurement specification that produces its inputs is §19: Layer 4: Truth & Work.

What “Exogenous” Does and Does Not Cover

Exogeneity to token price is the property we need 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 (§4: Threat Model).

The consequence is that Red Line 1, the thesis’s hinge, is externally triggerable. This is monitored upstream via sovereign optionality (§14: Layer 0: Verifiable Machines & Energy) and Red Line 13 rather than left to be discovered at the hinge. §14: 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 §1: 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:

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

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 physical 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: §19: Layer 4: Truth & Work uses “Physical VerifyPrice SLOs” to mean the real-resource cost of verifying a proof or compute claim on reference hardware, as distinct from token-quoted metrics. This section introduces a related but distinct metric: 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 §14: 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 (§22: 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?

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 (§19: 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 §19: Layer 4: Truth & Work. Two target levels are distinct by design and must not be read as one: the constitutional floor (§19: 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 (§19: 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 (§19: 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; §19: 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 §19: 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 prover (reward)

• 20% burned (supply reduction)

• 10% to protocol treasury (security budget)

The 20% burn share here is a deliberately conservative variant of the 30–50% reference band in §6: The Triad and the Monetary Candidate: this worked example also funds a protocol treasury, so the three shares are set to sum to 100%. The reference band remains the design target; a 20% burn is the harder case for the value-capture claim, not the easier one.

Fee formula (reference):

New here? Start with the one-minute version.

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