Every GPU operator sells the same two promises: the machine will be there when the customer needs it, and it will do the work it was paid for. In a hyperscale cloud, the customer trusts the provider to keep both promises and to report honestly when it does not. Independent GPU operators rarely start with that trust. An operator with a few hundred well-run GPUs competes against brands that customers already know, and the usual way to close that gap is a long sales cycle.
There is a faster route: make both promises verifiable by someone other than the operator, and tie payment to the verification. This article covers how that works and what it means for the operator's business.
How conventional SLAs work
The Amazon Compute SLA is a clear reference point. It commits to a region-level monthly uptime of 99.99% for instances across two or more availability zones, and 99.5% for a single instance. The remedy is a service credit against future bills of 10%, 30% or 100%, depending on how far uptime fell. To receive one, the customer opens a support case with dates, resource IDs and logs before the end of the second billing cycle after the incident, and the credit is described as the sole remedy. AWS also waives charges automatically for any single instance unavailable for more than six minutes in a clock hour.
The model works because the customer already trusts AWS's measurement. An independent operator offering the same terms asks the customer to trust its measurement of itself. For a buyer who has never heard of the operator, that is the whole problem.
Availability verified by independent probes
The alternative is to let independent parties measure availability and have their verdict drive payment.
The mechanism is simple to describe. Independent verifiers send each provider an unpredictable challenge at regular intervals, and the provider must sign the answer before a deadline. Each verifier reports, for each hour, whether the provider answered most of its probes in time. Once verifiers representing a supermajority of the network's stake have reported, the hour's verdict is fixed and cannot be changed.
Two rules stop the mechanism from being turned against an honest operator. Only the provider's registered hardware identity can answer a probe, so a third party cannot answer in its place, and cannot get it marked as failed by answering first. And every probe leaves a reasonable time to respond, so network jitter is not mistaken for absence.
Payment then follows the verdicts automatically. A renter locks the full term in escrow. Each hour judged available is released to the operator, each hour judged unavailable stays with the renter, and nobody has to file a claim. For a buyer, that is a stronger guarantee than a service credit. For an operator, a record of verified hours is a track record that any new buyer can check.
Output verified by re-execution or attestation
Availability is half the promise. The other half is that the work was done correctly: that the advertised model actually served the request, at the advertised precision, without shortcuts. A dishonest operator could substitute a smaller model or a heavier quantisation. Each verification method costs something and proves something different:
- Signed receipts. The serving machine signs a record of the model hash, the engine, an input commitment, an output hash and the billed units. This proves who served what and binds them to it, but on its own does not prove the output is correct.
- Optimistic re-execution. A sample of answers produced with deterministic sampling is re-run on a second, independent provider holding the same weights. A mismatch becomes a dispute that other parties judge by re-executing the request themselves. If the dispute is upheld, the operator's bond pays a refund and a penalty. This makes cheating unprofitable at the cost of occasional duplicate work.
- Logit commitments. A provider can commit to a compact hash of the top logits at each decoding step, an approach described in the TOPLOC paper. Anyone with the same weights can later recompute and compare them.
- Hardware attestation. On confidential-computing hardware, the receipt can include an attestation report showing which measured software stack ran. NVIDIA supports confidential computing on its Hopper, Blackwell and Rubin GPUs, alongside CPU technologies such as Intel TDX and AMD SEV-SNP.
The useful design choice is to let the buyer name the level a request needs, and to have providers refuse requests they cannot meet rather than quietly answering at a lower level.
Metering the operator cannot inflate
Billing is the third place where trust breaks down. An operator reports token counts, and the buyer cannot check them. The fix is to cap every billed unit by what actually crossed the wire. Output tokens are capped by the request's limit and the bytes returned, and prompt counts by the bytes sent. A provider then cannot over-report usage even if it wanted to. Honest operators lose nothing from the cap and gain a bill that every buyer can check against its own traffic.
Tail latency as part of the service level
Uptime is not the only service level buyers care about. As Dean and Barroso showed, tail latency often decides user experience, and an operator that is up but slow loses traffic. On an open network, routers can measure each provider's latency at their own boundary, hedge slow requests to a second provider and skip providers that stop sending health signals. Operators with a good tail win more routed traffic. That is a service level enforced by the market, without anyone writing a contract.
What this means for GPU operators
For independent operators, verifiable service levels turn a weakness into an advantage. A buyer no longer needs to know your brand. They need to see your verified hours, your dispute record and your receipts. Use the strongest verification your hardware supports, since confidential-computing nodes can serve buyers whose workloads others cannot. Price for the verification levels you offer. And treat your bond as part of what you sell: it is what makes your promise credible to a stranger.
Where Tenzro fits
Tenzro is an open network where machines sell AI compute and inference. It is live in preview, and governance decides the steps to testnet and mainnet. What is built:
- SLA probes and verdicts. Validators send each bonded provider a randomised challenge every ten minutes, with 30 seconds to answer. Only the provider's registered hardware identity can answer. An hour's verdict freezes once validators holding two thirds of bonded stake have attested it.
- Payment on verdicts. Compute rental is a streaming escrow released per period judged available. Compute claims bought ahead of time settle hour by hour on the same verdicts, with the writer's collateral covering missed hours.
- Verification levels. Requests can ask for
receipt,optimisticorteeverification. Providers that cannot meet the level refuse before doing any work. Optimistic faults are judged by bonded validators who re-execute the request on a provider other than the accused. - Receipts. Receipts are signed by a session key certified by the machine's hardware identity key. They cover the model hash, the engine, the machine, the input commitment, the output hash, the units and the sampling settings, and they can be verified without contacting the provider.
- Logit commitments. A verifiable chat response carries a TOPLOC-style hash commitment over the top-k logits of each decode step, and a node refuses a verifiable request it cannot commit to.
- Attestation. Intel TDX, AMD SEV-SNP, AWS Nitro and NVIDIA GPU confidential computing are supported, and the TDX and SEV-SNP paths have been exercised on real hardware.
- Bounded billing. Forwarded calls are billed from signed receipts and capped by what was sent and received.
Bonds and settlement are in TNZO, the network's unit for staking and settling work.
