Appendix A. Formal Model of Verification Asymmetry & VerifyPrice

Jason St George. "Appendix A. Formal Model of Verification Asymmetry & VerifyPrice" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v2.0. /v/2.0/read/appendix/a-verifyprice-model/

Formal Model of Verification Asymmetry & VerifyPrice

Definition 1: VerifyPrice(W) and Verification Overhead

For each canonical workload $W$ (for example, a constraint system $\text{PROOF}_{2^{20}}$, a matrix multiplication size MATMUL_4096, or a verified-inference task INFER_LM_70B_256TOK), we care about two things:

1. How expensive it is to verify a purported result on a reference verifier, and

2. How that verification cost compares to producing the result from scratch.

VerifyPrice(W): verification profile

Fix a reference verifier and adversarial mix of inputs. From a sample of verification runs for workload $W$, we estimate:

• $p_{50,t}(W), p_{95,t}(W)$: median and 95th-percentile wall-clock verify time from “artifact received” to “accept/reject”;

• $p_{50,c}(W), p_{95,c}(W)$: corresponding median and 95th-percentile verify cost in a reference unit (e.g., USD of cloud compute);

• $\text{fail}(W)$: observed fraction of artifacts that fail verification (invalid, malformed, or timed out).

The VerifyPrice vector for $W$ is then:

ProduceProfile(W): production profile

Similarly, we can describe the prover’s cost to produce correct outputs for $W$. From a sample of production runs (or cost models) we estimate median and 95th-percentile produce time and cost:

Verification overhead $r(W)$

We define separate time- and cost-based overhead ratios:

For convenience, we can summarize these as a single scalar:

Implementation Note: VerifyPrice Telemetry Schema (Sketch)

The exact encoding of VerifyPrice is implementation-dependent, but for operational dashboards and APIs it helps to standardize a minimal JSON-style schema per canonical workload. A skeletal example:

{
  "workload_id": "PROOF_2^20",
  "window_start": "2025-06-01T00:00:00Z",
  "window_end":   "2025-06-07T00:00:00Z",

  "p50_verify_time_sec": 0.40,
  "p95_verify_time_sec": 0.90,

  "p50_cost_usd": 0.00030,
  "p95_cost_usd": 0.00055,

  "failure_rate": 0.0004,

  "r_time": 0.18,
  "r_cost": 0.21,
  "r_max": 0.21,

  "sample_size": 125000,
  "hardware_profiles": ["open_tee_v2", "gpu_cluster_Y_v1"]
}

This schema is not normative; it is illustrative. The key properties are:

• Each canonical workload (workload_id) has its own series of VerifyPrice snapshots over sliding windows.

• VerifyPrice is expressed both in time and cost percentiles, with the overhead ratio $r(W)$ reported explicitly.

• Enough context is included to interpret shifts (sample size, hardware profile mix, time window), but no user-identifying data is required.

Clients and observatories can compute VerifyPrice from raw receipts and emit them in this or a similar format. The important thing is that:

1. The mapping from receipts $\to$ VerifyPrice is public and reproducible, and

2. The resulting metrics are exposed in a way that any third party can verify and alert on.

A system that claims “cheap, public verification” but cannot produce machine-readable VerifyPrice series for its canonical workloads is, by construction, asking you to trust what it cannot or will not measure.

We say that $W$ is verification-asymmetric if $r(W) \ll 1$: checking honest work is much cheaper than re-doing it from scratch, both in time and cost.

A network (or facility) satisfies the VerifyPrice SLO for workload $W$ if, for a published target (e.g., $p_{95,t}(W) < 5$s, $p_{95,c}(W) < 10^{-3}$ USD), it maintains:

• $\text{fail}(W)$ below a small, explicit threshold, and

• $r(W) \leq 0.3$ (with a stretch goal $r(W) \leq 0.1$),

over adversarial mixes of inputs and artifacts.

Definition 2: Facility Energy Receipt (FER)

A Facility Energy Receipt (FER) is a signed, machine-readable summary of a site’s energy use and availability over a fixed time interval $\Delta t$. Each FER is identified by a unique hash fer_id and contains at least:

• facility_id: a stable identifier for the site or plant;

• interval_start, interval_end: timestamps delimiting the reporting window;

• energy_in_kwh: total electrical energy consumed at the site boundary over $\Delta t$;

• energy_it_kwh: energy delivered to IT loads (provers, routers, storage);

• heat_reused_kwh: energy captured and reused (for ERE metrics);

• pue, ere, wue: standard efficiency and water-use indicators over $\Delta t$;

• outages: a list of curtailment or outage events during $\Delta t$;

• carbon_intensity_kg_per_kwh: average emissions factor for supplied energy;

• signature: one or more digital signatures attesting to the report’s correctness.

FERs are produced at regular cadence (e.g., every 5 minutes or hour). Other receipts (e.g., PIDL receipts for proofs) can reference a FER via fer_id, allowing allocators, auditors, and protocols to reconstruct the energy context in which a unit of verified work was performed.

Definition 3: PIDL Receipt (Proof Interface Definition Language)

A PIDL receipt is the minimal, canonical record of a verified interaction in the Create/Compute $\to$ Prove $\to$ Settle $\to$ Verify loop. It binds together the claim, the evidence, and the operational context into a single, serializable object.

At a minimum, a PIDL receipt contains:

• receipt_id: a unique identifier (e.g., a hash of the serialized payload);

• claim_id: an identifier or hash of the claim being attested;

• workload_id: a canonical tag for the workload type and parameters (e.g., PROOF_$2^{20}$, MATMUL_4096);

• proof_ref: a hash or pointer to the proof or transcript artifact;

• sla_tier: the service class under which the work was promised (e.g., Bronze/Silver/Gold);

• verify_time_sec, verify_cost_unit: measured time and cost for verification;

• result: an outcome flag (e.g., accept, reject, timeout);

• optional context: hardware_profile, fer_id, settlement_txid, policy/jurisdiction tags;

• signatures: digital signatures from the prover, verifier, and (if applicable) broker or router.

PIDL receipts are designed to be portable and composable: they can be embedded in blocks, stored off-chain with only their hashes committed on-chain, included in higher-level proofs, or presented to auditors and counterparties.

Definition 4: VerifyReach(N, R)

Reachability and path diversity for independent verifiers in network $N$ and region $R$.

For a given network configuration $N$, client region $R$, and a target time budget $T$ (e.g., “within 30 seconds”), VerifyReach summarizes how reliably an honest client can reach at least one honest verifier within $T$ seconds over multiple transport classes.

The VerifyReach KPI for network $N$ in region $R$ is the vector:

Where:

• $p_{50,\text{conn}}$, $p_{95,\text{conn}}$: median and 95th-percentile time-to-first-connection;

• $\text{succ}_1$: 1-path reachability rate;

• $\text{succ}_2$: multi-path reachability rate (resilience to single-path blocking);

• $\text{fail}_{\text{mix}}$: distribution over connection failure causes.

Example SLOs:

• $\text{succ}_1(N,R) \geq 0.98$ and $\text{succ}_2(N,R) \geq 0.90$ for major regions;

• $p_{95,\text{conn}}(N,R)$ under a few seconds or tens of seconds (depending on transport mix).

Definition 5: VerifySettle(C)

Time, reliability, and privacy quality of non-custodial settlement on a corridor $C$.

For a given settlement corridor $C$ (e.g., BTC$\leftrightarrow$XMR atomic swaps), VerifySettle($C$) summarizes whether non-custodial settlement actually clears under its advertised SLOs.

The VerifySettle KPI is:

Where:

• $s(C)$ (success): fraction of settlements that complete as intended within the SLA window;

• $r_{\text{safe}}(C)$ (refund-safe): fraction of failed attempts where all funds return safely;

• $f_{\text{mix}}(C)$ (failure mix): distribution of failure causes;

• $a(C)$ (anonset): summary of anonymity-set size and churn.

A corridor satisfies its VerifySettle SLO if:

• $\text{success}(C) \geq \text{target}$ (e.g., 0.95), and

• $\text{refund\_safe}(C) = 1.0$ over adversarial mixes,

with no hidden custodian or discretionary freeze paths.

Definition 6: Repression Wedge

The repression wedge is the realized real return on rate-capped instruments when nominal yields are held below inflation:

A negative $r_{\text{real},t}$ indicates that holders of capped instruments are being taxed in real terms via financial repression rather than explicit default.

Definition 7: Liquidation Effect

The liquidation effect measures the effective “tax” on bondholders from negative real rates (after Reinhart–Sbrancia):

Advanced economies saw negative real rates $\sim$1/2 the time, with average savings $\sim$1–5% of GDP/yr during 1945–1980.

Definition 8: Physical VerifyPrice

Physical VerifyPrice extends VerifyPrice(W) (Definition 1) from proof/compute claims to the physical infrastructure claims (FCRs, Appendix A: Formal Model of Verification Asymmetry & VerifyPrice) that back them. For a facility profile $F$, it is the vector

where $p_{\cdot,t}^{\text{FCR}}$ and $p_{\cdot,c}^{\text{FCR}}$ are time and cost percentiles to independently verify $F$’s FCR claims (energy profile, outage/curtailment history, hardware-profile integrity, jurisdictional routing), (F) is the fraction of third-party audit challenges that resolve without dispute, and (F) is the count of unresolved claim mismatches. A Work Credit is high-assurance only if VerifyPrice(W), PhysicalVerifyPrice(F), and the relevant DVC bound clear their respective SLOs; none of those conditions makes the credit monetary. See §19: Layer 4: Truth & Work, §14: Layer 0: Verifiable Machines & Energy.

Definition 9: VerifyFlow

VerifyFlow is the market-realization counterpart to VerifyPrice, VerifyReach, and VerifySettle. Where those three measure whether the stack supplies triad capacity under adversarial conditions, VerifyFlow measures the external financial representation and price-transmission state of the native monetary object. It is a pair of vectors, one per wrapper and one per asset:

Component definitions appear in §23: Extended Telemetry; the estimating equations and their measurement contract appear in Appendix H: Formal Model of Market Realization, Wrapper Flows, and Price Capture. VerifyFlow is explicitly not a protocol SLO: no VerifyFlow value falsifies the monetary thesis by itself. Its function is to determine whether observed price carries any information about native adoption (§10: Work Credits: Energy-Anchored Claims).

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