§19. Layer 4: Truth & Work

Jason St George. "§19. Layer 4: Truth & Work" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v2.0. /v/2.0/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.

Layer 4’s goal is simple:

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

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:

Canonical Workloads and Proof Types

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

• MatMul($n, k, m; \varepsilon$) – matrix multiplication at specified dimensions and error bounds.

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

• SLO tiers: latency and reliability classes (Bronze, Silver, Gold).

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.

Canonical Workload Definition Template

For a workload to become a tradable SKU (and eligible for Work Credit issuance), it must be defined with sufficient precision. The following template ensures standardization:

Canonical Workload Definition Template

WorkloadID: Unique identifier (e.g., MATMUL_4096_FP32, INFER_LM_70B_256TOK)

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 - A \cdot B\|_\infty \leq \varepsilon$.”

Public Inputs:

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

• Claimed result commitment (hash of $C$)

• Error bound $\varepsilon$

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

Verifier Complexity Class:

• Time: $O(\log n)$ for succinct proofs; $O(n)$ for non-succinct

• 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 (e.g., L0-B or higher)

• 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.1$\times$)

SLA Tiers:

SLA tiers for canonical workloads.

Example: MATMUL_4096_FP32

Example canonical workload: MATMUL_4096_FP32. The acceptance bound is relative, scaled by $\|A\|_\infty \|B\|_\infty$: FP32 accumulation over $k=4096$ terms typically incurs \sim$$10^{-4}–$10^{-3}$ relative rounding error with standard BLAS kernels, so an absolute bound of $10^{-5}$ would fail honest provers. The reference kernel ID pins the arithmetic order so heterogeneous provers produce comparable transcripts; see the determinism note in §19: Layer 4: Truth & Work.

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

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.

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.

Cost Vector Definition:

For each workload $W$ and verifier class $V$, VerifyPrice is a 5-tuple:

Where:

• $t_{50}, t_{95}$: median and 95th-percentile verification time (seconds)

• $e$: energy per verification (Joules, measured via hardware counters or watt-meter)

• $m$: peak memory (MB)

• $f$: failure rate (timeouts, invalid proof rejections, crashes)

USD cost is derived: $c = e \times p_{\text{energy}} + t_{95} \times p_{\text{opp}}$, where $p_{\text{energy}}$ is the reference energy price (USD 0.10/kWh) and $p_{\text{opp}}$ is opportunity cost (USD 0.001/s), both published quarterly.

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. The 70B-inference row is deliberately marked aspirational: current ZKML systems prove quantized transformer inference at small scale with substantial overhead, and no production system verifies a 70B-parameter forward pass on laptop-class hardware within seconds. Placing it in the constitutional set as though it were deliverable would trip Red Line 1 on publication day. It remains in the registry as the commercial destination; it is not a constitutional SLO until the maturity gate of §19: Layer 4: Truth & Work lifts for its component.

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:

Physical VerifyPrice SLOs (Constitutional)

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.

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.

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.

Token-Quoted VerifyPrice (Market Signal, Not Target)

Token-quoted VerifyPrice is a useful market signal, but not a constitutional target:

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 risk haircuts 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:

Canonical workload starter set. 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).

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 verification asymmetry is a conjecture, inference PoUW is pilot-stage, and pricing pristine collateral over either would define a AAA rating on an instrument whose proof system has not survived production. 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):

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