§10. Work Credits: Reserved Service Claims

Jason St George. "§10. Work Credits: Reserved Service Claims" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v3.5. /v/3.5/read/part-ii/10-work-credits/

Work Credits: Reserved Service Claims

Every era that mechanizes work eventually writes claims on it. Grain receipts became banking; warehouse receipts became money-market funds; and in each case the instrument was born useful and lived or died on one question — did the claim stay tethered to the thing in the warehouse? The tether is everything. A receipt that outruns its warehouse is a promissory note wearing a receipt’s reputation, and the bill arrives the day everyone redeems at once. This chapter builds the tether before it builds the claim.

The triad supplies three capacities. Making them tradable without confusing service with money requires a unit of account for work: something that binds energy, hardware, delivery terms, and verification into a transferable typed claim.

Call these Work Credits (WC).

Informally:

A Work Credit is a typed, prepaid claim on reserved future service, owed by a specified provider or provider pool. Its issuance requires an admissible capacity commitment and an atomic reservation against outstanding obligations. Verified fulfillment extinguishes the claim and produces a receipt, which is evidence and creates no further obligation.

Key distinction: Work Credits are energy-priced, not energy-pegged. They are denominated in work, not in kWh. Energy enters through Facility Energy Receipts (FERs) and VerifyPrice, not through a one-dimensional peg. See §10: Work Credits: Reserved Service Claims for the full treatment.

Clarification. Throughout this section, “Work Credits” are generic, notional service claims, not product branding and not the base asset. “AI Money” and “proof money” survive only as historical shorthand for service-instrument design spaces; the analytical objects are typed compute, proof, and settlement claims. That separation — claim versus money — is stated once here and defended twice, at §10: Work Credits: Reserved Service Claims and §10: Work Credits: Reserved Service Claims; it is not repeated as a caveat at every mention.

Work Credits can be described along a few axes:

Definition: Work Receipts vs. Work Credits

A common source of confusion is conflating “proof that work was done” with “transferable claim on future capacity.” These are different financial objects. They split cleanly:

Work Receipt (WR)

A Work Receipt is a PIDL artifact proving that a specific unit of work was completed under attested conditions.

• Content: Claim hash, proof hash, workload ID, SLA tier, timestamps, hardware profile, prover signature.

• Properties: Copyable, verifiable by anyone, not scarce.

• Analogy: A receipt from a completed transaction. It proves the past but confers no future rights.

Work Receipts are not money. They are evidence.

Work Credit (WC)

A Work Credit is a transferable, typed claim on reserved future service, issued against an admissible capacity commitment and extinguished by the Work Receipt that verified delivery produces.

• Issuance: Sold when (a) a named provider or constituted pool has committed admissible capacity for the workload, tier, and window, and (b) that capacity is reserved against every outstanding claim on it in the same atomic step.

• Properties: Scarce (outstanding claims bounded by reserved capacity), transferable, fungible within workload, tier, and window.

• Rights: The service terms written in the claim: workload, quantity, tier, delivery window, substitution terms, and remedies.

Base asset and Work Credit separation:

Hierarchy rule: The base asset is the only object evaluated for monetary premium, and even then only conditionally. Work Credits are useful for service procurement and cost hedging and are explicitly not pitched as stores of value.

The Work Credit Lifecycle

A Work Credit lives through four steps, and one of them is indivisible:

There is no interval in which a valid sold claim exists while its capacity is unreserved. Four commitments make the lifecycle a contract rather than a slogan.

• The obligor is named. Each credit binds a provider or an expressly constituted provider pool. “The network” is not an answer unless the network’s collective obligation, funding, and loss allocation are themselves defined.

• The service is named. Workload, quantity, assurance tier, delivery window, location or substitution terms, and remedies are written in the credit. A substitution right states what may replace what.

• Reservation is against everything outstanding. The constraint is not how many credits were sold this epoch but whether every outstanding claim competing for the same future capacity remains feasible. Shared power, hardware, and delivery windows cannot be reserved independently for incompatible workloads, which is why the reservation limit is computed jointly (§14: Layer 0: Verifiable Machines & Energy).

• Failure resolves by terms. Verified delivery retires the claim. Cancellation, expiry, default, and refund follow stated terms, and a failed delivery becomes neither an open-ended promise nor an automatic claim on the base asset.

Delivered Verified Capacity supports the reservation limit; it does not guarantee performance. In the reference design, payment sits in the fulfilment and escrow arrangement of the claim until delivery rather than quietly financing construction. Where advance proceeds do finance capacity not yet built, that exposure is project finance, named and carried separately (§2: The World Forces New Monetary Primitives), and not concealed inside the ordinary Work Credit. The receipt that delivery produces is evidence of fulfilment and creates no further service obligation, which is the line between this section’s two objects.

Issuance mechanics for Work Credits:

For a canonical workload $W$ (e.g., “MatMul of size $n$ with error bound $\varepsilon$,” “provenance proof for content type $C$,” “corridor settlement of size $S$ with anonymity set $\geq A$”), define:

• $p(W)$: production cost (energy + hardware amortization + opex) to generate one unit and produce a valid proof.

• $v(W)$: verification cost.

• $r(W) = v(W) / p(W)$: verification asymmetry.

A Work Credit of type $W$, tier $T$ is sold only when:

• A named provider or pool commits admissible capacity for $W$ at $T$ over a stated window, with FER and FCR evidence behind it.

• Telemetry confirms that VerifyPrice($W$,$T$) and other SLOs (latency, failure rate, decentralization) are within bounds for that provider.

• The sale and the reservation happen together, and outstanding claims on the same capacity stay within the issuance envelope (see §10: Work Credits: Reserved Service Claims).

The credit represents only the service rights stated in its terms. A receipt attests historical work and a credit promises reserved future service; neither becomes the fee/staking medium or inherits the base asset’s conditional monetary candidacy.

Energy Anchoring

Like PoW, Work Credits are ultimately energy-anchored:

• The cost of honoring one more credit is bounded below by the energy and hardware required to produce work that passes the verification threshold.

• Where SHA-256 PoW has no buyer for its work, this work has one: it powers privacy settlements, proofs of provenance, and AI computation.

This anchoring gives Work Credits:

• Credible scarcity: A credit cannot be sold without an admissible capacity commitment, and it cannot be extinguished without real resources spent producing proofs and settling flows.

• Economic meaning: One credit corresponds to a service somebody was willing to pay for (anonymized payrolls, authentic media, verified inference).

And the cost of the same property.

The buyer that gives a Work Credit its economic meaning is also an attack surface the hash puzzle does not have. Nobody buys a SHA-256 output, so there is no buyer of the work to subsidize, mandate, or sanction — though miners themselves can be; demand for verified inference can be all three. The energy anchor is therefore a service-cost and provenance anchor, not a monetary one. Bitcoin’s monetary objectivity and a Work Credit’s link to real activity are different properties (§30: Objections & Responses).

Layer 0 Maturity and Economic Consequences

Work Credits are only as trustworthy as the hardware that produces them. A world where all proving runs on opaque, vendor-controlled hardware is different from one with diversified, partially open designs.

§14: Layer 0: Verifiable Machines & Energy (Part III) defines a Layer 0 maturity ladder with grades L0-A through L0-D. This section previews how those grades affect Work Credit economics:

How this affects issuance and pricing:

1. Tiered issuance caps: WC reserved on L0-A profiles may face stricter issuance limits than L0-C/D profiles. This prevents the system from becoming dependent on opaque hardware.

2. Market pricing: WC from different L0 grades can trade at different prices if markets distinguish them. Treasuries and institutions may pay premiums for L0-C/D-backed capacity.

3. Risk disclosure: Every Work Receipt includes the hardware profile (HID) used. Aggregated telemetry shows what fraction of total WC is backed by each grade.

4. Deprecation impact: If an L0-A profile is compromised (TEE backdoor discovered), WC reserved on that profile can be quarantined, discounted, moved to substitute capacity under their terms, refunded, or excluded from certain uses. This is the “bond downgrade” analog.

Why this matters for service-claim quality:

If 90% of Work Credits are reserved on L0-A hardware and a major TEE is compromised, claim quality and DVC take a hit—not because the cryptography failed, but because the service path depended on a common hardware assumption.

By making L0 grade explicit and tying it to economic consequences, the system:

• Creates incentives to invest in open hardware.

• Bounds the impact of hardware compromises.

• Gives users and allocators the information to price risk appropriately.

This is covered in detail in §14: Layer 0: Verifiable Machines & Energy (Part III). The key point for Part II: hardware trust is not binary; it is graded, measured, and priced — and because it is priced, the service claim’s quality is legible without anyone having to take the word “typed” on faith.

Robots, AI, and the Demand for Work Money

In a robot- and AI-heavy economy the demand story for Work Credits becomes almost embarrassingly straightforward.

Consider a warehouse or factory where most of the physical activity is carried out by robots, and most of the planning and oversight is handled by models. The day-to-day budget splits into:

• Energy to power robots and data centers.

• Compute to run models and generate proofs.

• Privacy and settlement to pay workers, suppliers, tax authorities, and investors without leaking trade secrets or exposing everyone’s graph.

Each of those budgets expresses itself as a recurring need for receipts:

• Proof of correct inference for high-stakes decisions.

• Proof of compliance and risk calculations for regulators and insurers.

• Privately settled wages and vendor payments with lawful audit trails.

Today that flow is mediated through cloud bills, payroll files, bank wires, and audit PDFs. In the stack described here, it can be mediated through Work Credits and receipts. The robots and services are paid in typed claims; in exchange they produce receipts that can be verified cheaply and settled over privacy rails. High turnover can make the claims useful working balances. It does not establish reserve demand for them or for the base asset.

This is one concrete way to discipline remarks like “money will just be energy.” Energy, compute, and hardware are inputs; Work Credits denominate future access to verifiable, robot-mediated output. They do not become joules, reserve assets, or monetary anchors by denomination.

Why Work Credits Remain Service Claims

A claim can be honest and still not be money. Scarcity, transferability, public verification, censorship resistance, and recurring demand are together enough to make a Work Credit a high-quality commodity or forward service claim; none of them, singly or jointly, is enough to make it savings. The reason is physical rather than rhetorical: the credit stays exposed to workload basis, location, hardware, SLA, expiry, delivery, and common-cause risk, and a promise of future service may carry duration. It is a warehouse receipt with a date on it, and a savings instrument has to survive the day the warehouse is the problem. DVC and the evidence artifacts determine whether the claim is fulfillable; the Native Monetary Buyer Map determines whether the separate base asset has a holder constituency capable of bearing loss. Two different questions, two different instruments, and neither answer transfers.

Monetary Role

Work Credits sit at the junction between base capacity and service contracting:

• For operators, they are revenue in kind: miners/provers/routers earn credits by contributing triad capacity.

• For users, they can be pre-paid capacity: hold credits to secure future access to specified triad services, or trade expected scarcity.

Their service value depends on:

• Demand for specific workloads: Work Credits tied to high-value workloads (e.g., compliance proofs, LLM inference) may command higher premia.

• Governance & telemetry honesty: If VerifyPrice and decentralization metrics are falsified or gamed, the link between credits and real work weakens.

• Regime pressure and deliverability: Differential demand may rise as substitutes weaken, while DVC may fall; the Pressure–Capacity Corridor prevents a monotonic crisis claim.

In portfolio terms, Work Credits are typed service or capacity exposure. LP and staking positions are the equity-like or derivative layer; the base asset is evaluated separately.

Issuance: Tying Credits to Real Capacity

There are many possible issuance schemes; what matters here is not choosing a particular curve, but enforcing two principles:

1. Issuance is legible.

2. Issuance is constrained by real capacity.

One extreme is the Bitcoin model: a fixed schedule, regardless of demand, with the understanding that price will equilibrate. The other extreme is a pure capacity-linked model, and it is the one the reference design takes: a Work Credit is a capacity reservation, sold when committed capacity is reserved and retired when the service is delivered, inside an issuance envelope set by stress-adjusted DVC.

In such a system, adding a new proving cluster, plant, or corridor is not just a marketing slide; it is an event that expands the envelope of Work Credits the system can credibly support. The converse is also true: if plant retires or corridors die and are not replaced, the reservations against them must move to substitute capacity under their terms or default, and any sales that continued on autopilot would show up as VerifyPrice drift, SLA breaches, and deteriorating energy metrics. The governance layer’s job is not to guarantee any particular price, but to keep issuance and capacity in rough proportion and to make any departures visible.

From an allocator’s perspective this yields a familiar pattern: Work Credits look like prepaid claims on the output of a portfolio of infrastructure (proving farms, AI chains, privacy corridors, and plants) rather than a purely arbitrary balance sheet. The difference from conventional “infra tokens” is the insistence on receipts and KPIs: if claimed capacity and observable behavior diverge, the discrepancy is not a rumor; it is a datapoint.

The Supply Balance Equation

Here is the question that kills most “energy-backed” tokens in the cradle: why does demand not simply expand supply, neutralizing scarcity? The mechanism sounds self-defeating. If Work Credits are sold whenever a customer wants service, then every new customer who arrives creates new supply to serve them. The token is busy, the network grows, and the scarcity — the very thing that was supposed to make holding worthwhile — evaporates into its own success. Demand, on this reading, is not a source of scarcity but an exhaust valve for it.

That is not a bug in the design. It is the design, correctly read. Work Credits are sold against reserved capacity and retired on delivery, so supply growing with demand is not leakage; it is the claim staying honest. A service claim whose supply could not grow to meet service demand would be a shortage instrument, not a savings instrument — and neither of those is a reserve asset. The interesting quantity is therefore not gross issuance but what remains after the service is delivered, and that is a balance, not a schedule.

The answer lies in the net supply dynamics. It can be written as a balance equation:

Lost or forgotten wallets do not leave the outstanding count — the units still exist on-chain — so they are not a term in this identity; the effective (circulating) supply additionally nets them out.

For Work Credit supply to remain aligned with deliverable service, the design must ensure:

Read that as a solvency test, not a scarcity test. It is the warehouse being asked to show that every receipt outstanding corresponds to something physically present and deliverable. It places no ceiling on how many receipts a busy system writes; it places a ceiling on how many can be outstanding at once, and the ceiling moves only when the physical world moves. That distinction carries the whole chapter:

• During growth: Work Credit issuance may grow with independently verified DVC and contracted demand.

• At maturity: Claims retire through delivery, expiry, or cancellation under published terms. Scarcity can affect service price without making the claim a reserve asset.

What prevents runaway issuance?

The same four doors, in the order an operator would try them:

1. DVC envelope: Total WC outstanding for each workload, tier, and horizon is capped by haircut stress-adjusted DVC.

2. Capacity evidence: The envelope expands only when FERs, FCRs, hardware profiles, and scenario flow support additional deliverable service.

3. Contract retirement: Delivery, expiry, cancellation, and default rules remove or impair claims explicitly.

4. Governance friction: Changes to service-claim rules require supermajority and are visible in dashboards before activation.

Telemetry that detects supply risk:

• Inflation rate: Issuance / circulating supply. Should decline over time.

• Retirement rate: retirements / issued. Should track delivered service and expiry terms.

• Net supply change: $\Delta$Supply per epoch. Positive during growth, flat or negative at maturity.

• Issuance vs. capacity: If issuance grows faster than verified capacity, this signals potential dilution.

If these metrics drift outside healthy ranges, it becomes visible in dashboards—holders and operators can respond before the SoV thesis is undermined. A system that sells against a warehouse cannot hide a shrinking warehouse; the drift shows up in the issuance numbers before anyone has to allege anything.

Energy-Priced, Not Energy-Pegged

In popular discourse one often hears that “money will just be energy,” especially in the context of robotics and AI. As shorthand, this is attractive: robots and data centers run on electricity, so why not quote everything in kWh and be done with it? The problem is that not all kilowatt-hours are created equal. Time of day, grid node, reliability, carbon intensity, and siting constraints all affect their economic and political meaning. A winter-peaking kWh on a stressed urban grid is not the same as a curtailed hydro kWh in a remote valley. Pretending otherwise smuggles a lot of hidden politics and risk into the unit of account.

The discipline in this thesis is to admit that complexity and route around it with receipts.

Energy is measured and wrapped into Facility Energy Receipts (FERs), which record, for each facility and time window:

• kWh in,

• kWh delivered to IT,

• heat reused,

• PUE/ERE/WUE,

• water use,

• carbon intensity,

• and outages/curtailments.

On top of that, the thesis measures verified work per kWh:

• $\eta_{\text{vFLOP}}$ for FLOPs,

• proofs-per-kWh for proof workloads,

• swaps-per-kWh for settlement.

VerifyPrice then tells us how much it costs, in time and money, for an independent verifier to check that a given amount of work was done.

The result is an implicit conversion path:

energy $\to$ FERs $\to$ verified work (proofs/FLOPs/swaps) $\to$ receipts $\to$ Work Credits

The design never pretends that one Work Credit is one kilowatt-hour; instead it makes it easy for anyone to estimate, at any given time, how many kilowatt-hours of which quality and where in the world sit behind a portfolio of Work Credits, via the receipts.

Pricing in energy then becomes an inference problem for markets:

• Work Credits are implicitly energy-priced because their production and redemption depend on energy-intensive workloads whose cost curves are public.

• FERs and VerifyPrice make those curves legible without forcing a brittle kWh peg.

What distinguishes Work Credits from naive “energy tokens” is precisely this separation:

• The unit of account is denominated in work, not in kWh.

• Energy enters through FERs, $\eta_{\text{vFLOP}}$, and VerifyPrice, not through a one-dimensional peg.

Markets, regulators, and builders can look at those receipts and say, with some confidence, “a Work Credit currently corresponds to about this much capacity, with this energy and carbon profile, under these SLAs.” That is enough to make the asset priceable and analyzable without forcing it into a crude energy standard.

Why Work Credits Are Typed Service Claims, Not Presumed Money

It is equally easy to make the opposite error: to observe that Work Credits are scarce, transferable, and tied to necessary workloads, then promote them from service claims into money by vocabulary. This thesis does not make that move. A Work Credit is a typed claim on capacity or service whose quality depends on workload, location, hardware, SLA, delivery window, and the stressed path that can actually fulfill it. That case was made at §10: Work Credits: Reserved Service Claims; this section asks the harder question it left open. What would have to be true — not said, not branded, but observable — for a Work Credit to cross from service claim into money?

Four things, each visible in telemetry before it is visible in price:

1. Issuance is constrained by stress-deliverable capacity, not nameplate capacity.

   FERs, FCRs, and Delivered Verified Capacity bound claims by the service that survives scenario-specific binding constraints. Gross installed hardware, energy procurement, or benign-state output is insufficient.

2. Demand can be budgeted without being monetary.

   Proofs, inference, settlement, and related workloads may sit on recurring OPEX lines. That supports a service market. It does not establish reserve demand, long holding periods, self-custody, loss-bearing capacity, or countercyclical accumulation.

3. Verification makes the claim legible, not monetary.

   A PIDL receipt can make fulfillment cheap to check and FCR/FER artifacts can make provenance auditable. Evidence reduces information asymmetry; it does not erase delivery, basis, counterparty, or temporal risk.

4. The claim must not absorb project duration by implication.

   A prepaid capacity claim, a claim on future service, and a project note are different instruments. If a Work Credit promises par, redemption, a coupon, or emergency support against construction failure, it has become duration-bearing credit and must be labeled and underwritten as such.

So what would the crossing actually look like? Not a marketing decision and not a milestone on a roadmap, but a change in holding behavior that the dashboards can see: holding periods lengthening rather than claims being redeemed at term, balances retained through drawdowns instead of recycled into service, and — the tell that would settle it — buyers acquiring the asset while the service it claims is cheap and available, which is the signature of savings rather than procurement. None of that is a design property. It is holder behavior, and it is exactly what the Native Monetary Buyer Map watches for on the base asset (§23: Extended Telemetry). Until those series move, Work Credits belong beside capacity vouchers and service contracts, not beside the base monetary candidate. They may trade at a premium for scarce delivery rights and may serve as collateral where their terms permit. Those are properties of typed service claims. Monetary treatment remains a separate empirical question answered, if at all, by the holder-side mechanism and buyer map (§10b: Why Hold the Base Asset?).

New here? Start with the one-minute version.

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