Skip to content
Tenzro
Documentation menu
Machine Economy

Compute claims and the price index

Reserve capacity by hardware class, region, delivery window and SLA, priced against a compute index committed to consensus.

Network 1 turns compute capacity into something you can reserve ahead of time and price against a shared reference. Two pieces do this: the compute price index, a price that every node agrees on, and compute claims, standard reservations of capacity that a provider must deliver and the chain meters.

The compute price index

The compute price index is the network's reference price for compute. It has three properties.

It is built from metered usage. The index is computed from work that was delivered and settled on the network: rental epochs that passed their availability proof, inference that was metered and paid, capacity that was attested. Quotes that nobody paid for, and prices a provider advertises but never fills, do not move it.

It is committed to consensus. Validators agree on the index as part of consensus under Tenzro DAG Consensus (TDC), our post-quantum consensus protocol. Every node, light client and bridge that follows the chain reads the same value, and a finality certificate proves which value was in force at a given height.

It is broken down by what is being priced. A single number would hide the difference between an integrated GPU and a data-centre accelerator. The index is published per hardware class and region, so a buyer compares like with like.

What the index is used for

  • Quoting. Buyers and agents use it as a reference before booking a rental or reserving a claim, and can see how far a provider's rate sits from it.
  • Dynamic pricing. A provider on network-dynamic pricing tracks utilisation; the index lets it see where the wider market is.
  • Agent discovery. An agent choosing between providers can weigh price against latency, reliability and trust credentials without trusting any provider's self-reported numbers.

Compute claims

A compute claim is a standard reservation of capacity. Every claim is keyed by the same four terms, so two claims with the same terms describe the same product.

TermWhat it fixes
Hardware classThe accelerator class delivered: integrated, consumer, workstation or datacentre
RegionWhere the capacity runs, for latency and data-residency requirements
Delivery windowThe epochs in which the capacity must be available
SLAThe service level the provider commits to, attested and checked in every epoch

Because the terms are standard, a buyer does not negotiate a bespoke contract with each provider, and a provider can offer the same claim to many buyers.

Who sells claims

A compute provider sells claims against capacity it has pledged. The provider posts a bond for the compute role and declares the accelerator classes it pledges; the same bond covers its rentals, storage and claims together, and the network refuses a new obligation that the bond cannot cover on top of everything the provider already owes.

bash
tenzro stake deposit <amount> --provider-type compute \
  --accelerator datacentre --accelerator datacentre

Repeat --accelerator once per card. The provider's signed policy states the SLA it offers; see Operator policies.

Reserving capacity

A buyer reserves a claim in three steps.

  1. Choose the terms. Pick the hardware class, region, delivery window and SLA, and compare offers against the price index.
  2. Fund it. Payment for the whole window is locked from the buyer's account when the claim is reserved. It is not paid to the provider up front.
  3. Take delivery. When the window opens, the reserved capacity is available to the buyer, as a rental, as a confined shell session, or as inference and training jobs routed to it.

Paying for capacity

A claim is paid the same way every metered service on Network 1 is paid: one epoch at a time, on the chain's verdict.

  • In each epoch of the delivery window, the provider must prove the capacity was available and met the SLA. Delivery is metered and backed by the provider's signed receipts and, where the SLA requires it, TEE attestation.
  • An epoch that passes releases one epoch's share of the locked payment to the provider.
  • An epoch that fails releases nothing. The buyer keeps that share, and the miss counts against the provider's SLA.
  • Enough misses close the claim, return the unearned remainder to the buyer, and feed the provider's slashing record.

Settlement happens in TNZO or in the stablecoin the parties settle in. See SLA attestation and metering for how delivery is checked and Settlement for how value moves.

Why delivery is provable

The hard part of selling compute ahead of time is proving it was delivered. On Network 1 the proof is part of the protocol:

  • Availability is checked in every epoch, by the network rather than by either party.
  • Operator keys are rooted in hardware, so a receipt is signed by the machine that did the work.
  • TEE attestation is verified per vendor (Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA confidential GPUs) when the SLA asks for confidential execution.
  • Finality certificates are portable, so the record of what was delivered can be checked by a light client or another chain.

The same metered, attested deliveries that pay providers are the inputs to the price index. The index and the claims describe one market.