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 v3.2. /v/3.2/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}}$, the matrix-multiplication SKU MATMUL_4096_FP32_FREIVALDS, 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:

Canonical form and its three views.

This five-field tuple is the canonical definition of VerifyPrice, and every variant tuple elsewhere in the thesis is a view of it, not a competing definition. There are three, and they are related by a single derivation:

1. Canonical (published) form: $(p_{50,t}, p_{95,t}, p_{50,c}, p_{95,c}, \text{fail})$, as above. Every SLO, red line, and phase gate that names VerifyPrice reads on this form and no other (§19: Layer 4: Truth & Work).

2. Input view: the per-run record $(t_{\text{run}}, e_{\text{run}}, m_{\text{run}}, b_{\text{run}}, \text{outcome}_{\text{run}})$ that the harness of §19: Layer 4: Truth & Work writes for every verification — wall-clock time, energy, peak memory, bytes transferred, and the pass/failure code — before any pricing or percentiling.

3. Cost-vector view: the same per-run record as §23: Extended Telemetry names it, $\text{CostVector}(W,V)_{\text{run}}$, and its front-matter form $c(W) = (t_{\mathrm{cpu}}, m_{\mathrm{peak}}, b_{\mathrm{net}}, e_{\mathrm{joules}}, c_{\mathrm{est}})$, which adds the priced per-run cost $c_{\mathrm{est}}$ as a field.

The derivation from views (ii) and (iii) to the canonical form is per run, then percentiled: each run’s cost is $c_{\text{run}} = (e_{\text{run}}/3.6\times10^{6})\, p_{\text{energy}} + t_{\text{run}}\, p_{\text{opp}}$ with both reference prices pinned and republished on change (§19: Layer 4: Truth & Work); $p_{50,c}$ and $p_{95,c}$ are then the percentiles of $c_{\text{run}}$ across the window, never recomputed from percentile inputs. Only time and energy are priced. Peak memory $m$ and bytes transferred $b$ are published, not priced: they appear in receipts and in views (ii) and (iii), they bound the reference machine a verifier must be (§19: Layer 4: Truth & Work), and they enter no cost percentile — a workload that fits the reference verifier’s memory and bandwidth pays nothing extra for them in $p_{\cdot,c}$, and one that does not fit is not a canonical workload on that tier. A dashboard may show any view, but all three must reconcile to the same underlying receipts.

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:

The denominator is an attack surface, and gets its own contract.

The verification numerator of $r(W)$ is produced under the multi-operator, signed-batch, adversarial-corpus regime of §19: Layer 4: Truth & Work; the production denominator has no equivalent protection as written, and it needs one, because a prover who inflates reported production cost drives $r(W)$ down and the network looks more verification-asymmetric than it is. The measurement contract for $\text{ProduceProfile}(W)$ is therefore the mirror of the numerator’s:

• Reference production cost model per workload. Production cost is estimated against a published reference model — pinned reference hardware, pinned kernel and stack versions, pinned energy price — exactly as the FP32 acceptance bound pins its reference kernel (§19: Layer 4: Truth & Work). Self-reported production cost may be published but does not enter $r(W)$.

• Independent estimation. At least two independent estimators (distinct from the prover being measured) produce the reference-model estimate; divergence above 5% triggers the same investigation protocol as verification measurements.

• Published derivation. The mapping from reference hardware, energy price, and runtime to estimated production cost is public and reproducible, so any observer can re-derive the denominator from its inputs.

• Asymmetry acknowledged. Where independent estimation is impossible for a workload, $r(W)$ is published as prover-favorable and unverified, and cannot by itself support a passing reading on chain link 3 (§6: The Triad and the Monetary Candidate).

The consequence for the SLO below is that a passing $r(W) \leq 0.3$ is a joint claim about both halves of the ratio: verification is cheap under the adversarial harness, and production cost is what the reference model says it is, not what the cheapest prover reports.

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:

{
  "schema_version": "verifyprice/1",
  "workload_id": "PROOF_2^20",
  "modality": "M1",
  "window_start": "2026-06-01T00:00:00Z",
  "window_end":   "2026-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.00035,
  "r_cost": 0.00050,
  "r_max": 0.00050,

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

This schema is not normative; it is illustrative. The figures are chosen to be consistent with the definitions: $\text{PROOF}_{2^{20}}$ is a succinct (M1) workload, so $r_{\max}$ sits inside the M1 band of $10^{-3}$ (§19: Layer 4: Truth & Work) — a verify time of $0.4$ s against a production time on the order of $20$ minutes gives $r_{\text{time}} \approx 3.5 \times 10^{-4}$, and the cost ratio is of the same order. A value of $r_{\max} \approx 0.2$, which an earlier draft of this example carried, would place a SNARK workload two orders of magnitude outside its band and is the kind of reading the modality check exists to catch. 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)$ within its modality band — $10^{-3}$ for succinct (M1), $10^{-2}$ for algebraic or probabilistic (M2) with the soundness parameter published, and no ratio target for replicated or attested verification (M3), which does not carry the monetary mechanism (§19: Layer 4: Truth & Work). The legacy aggregate ceiling $r(W) \leq 0.3$ is retained as a portfolio-level engineering floor and as the fallback for unbanded workloads; no monetary claim reads on it,

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 registry identifier (e.g., PROOF_$2^{20}$, MATMUL_4096_FP32_FREIVALDS; §19: Layer 4: Truth & Work);

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

• sla_tier: the latency tier under which the work was promised (Bronze/Silver/Gold) and assurance_tier: the modality-indexed assurance tier (Replicated, Replicated+audit, Probabilistic, Succinct; §19: Layer 4: Truth & Work) — a quote names one of each;

• 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$: fraction of vantage points reaching an honest verifier via the primary transport within 30 s;

• $\text{succ}_2$: fraction reaching one via any transport, fallbacks included, within 60 s — so $\text{succ}_2 \geq \text{succ}_1$ by construction, and the gap between them is what the fallback ladder buys;

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

SLOs, as §15: Layer 1: Reachability sets them (this definition carries no second set):

• $\text{succ}_1(N,R) \geq 0.95$ and $\text{succ}_2(N,R) \geq 0.99$ in uncensored regions; $\geq 0.70$ and $\geq 0.85$ in known-censored regions, measured over the ASNs sampled inside them;

• $p_{95,\text{conn}}(N,R)$ per transport class, because a single figure across classes hides the class that is failing: direct encrypted (BIP-324 [Mehta et al. 2023], QUIC/TLS) $\leq 3$ s; mimicry (look-like-TLS, domain-front-free decoy routing) $\leq 8$ s; onion / I2P $\leq 20$ s; rendezvous and refraction (Snowflake-class WebRTC, Conjure-class [Frolov et al. 2019]) $\leq 45$ s. Each is measured from first packet to an authenticated verifier session, and the class mix that produced the aggregate is published with it. The reference set is Appendix F: Communications Resilience Mechanisms.

The failure-cause distribution $\text{fail}_{\text{mix}}$ is likewise reported per transport class, over a fixed taxonomy — DNS failure, TCP/QUIC reset, TLS/handshake failure, timeout with no response, active-probe detection, and application-layer block — so that “unreachable” is never published as a single number.

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 off-happy-path transactions in which every party had a unilateral no-loss exit within the corridor’s bounded $\tau_C$ — its own leg refunded or the counterparty’s leg claimed (§20: Layer 5: Value & Settlement); computed on the protocol-attributable denominator (user-environment failures classified and excluded) for the SLO, and on the overall denominator for Red Line 2 and the Phase I gate;

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

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

Notation: $s(C)$ and $r_{\text{safe}}(C)$ are the mathematical symbols; where the body and the boards write success(C) and refund_safe(C) (§20: Layer 5: Value & Settlement, Red Line 2), those are the same two fields under their dashboard names, and nothing else is meant by either spelling.

A corridor satisfies its VerifySettle SLO if:

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

• $r_{\text{safe}}(C) \geq 0.999$ on the protocol-attributable denominator over adversarial mixes, with zero protocol-attributable losses (any such loss is Sev-1; §20: Layer 5: Value & Settlement), and $\geq 0.995$ overall,

with no hidden custodian or discretionary freeze paths. A hard $1.0$ over every failure class, which earlier versions of this definition required, is a figure no corridor with humans on it can hold and was met only by corridors nobody used.

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. The construction follows Reinhart and Sbrancia [Reinhart & Sbrancia 2015], whose annual liquidation effect is the real saving to the sovereign in a year when the real rate on its domestic debt is negative, expressed as a share of GDP:

Reinhart and Sbrancia report that advanced economies saw negative real rates in roughly half of the years over 1945–1980, with the annual liquidation effect averaging on the order of 1–5% of GDP per year across the economies in their sample; those are their figures, quoted here as the historical scale of the mechanism, and no red line reads on them.

Definition 8: Physical VerifyPrice

Two series, two names.

Earlier versions used “Physical VerifyPrice” in two senses. From v3.2 the constitutional SLO — the verification-cost series of Definition 1 measured in real resources on reference hardware, exogenous to token price, the series Red Line 1 reads — is the Real-Resource VerifyPrice SLO (§19: Layer 4: Truth & Work). Physical VerifyPrice names only this definition: the cost of auditing the physical-infrastructure claims behind a unit of verified work, the series Red Line 10 reads. The two are not merged, because a network can verify proofs cheaply while its facilities are opaque, and the converse. §19: Layer 4: Truth & Work and the glossary carry the same distinction.

The claims being audited.

A Facility Capacity Receipt (FCR, §14: Layer 0: Verifiable Machines & Energy) is a signed, auditable receipt that extends the Facility Energy Receipt of Definition 2 with grid, cooling, redundancy, hardware-diversity, jurisdictional, and infrastructure-resilience claims; it is the object whose fields Sovereign Optionality and Delivered Verified Capacity aggregate. Physical VerifyPrice extends VerifyPrice(W) (Definition 1) from proof/compute claims to these FCR claims. 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), $\text{ChallengeSuccess}(F)$ is the fraction of third-party audit challenges that resolve without dispute, and $\text{OpenDiscrepancies}(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).

New here? Start with the one-minute version.

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