Compute rental
Rent capacity by the epoch: SLA-attested availability, streaming payment and billing on the chain's verdict, in TNZO or stablecoins.
A node with idle CPU or GPU capacity can rent it out by the epoch. The renter books a term, the provider proves in every epoch that the capacity was available and met its SLA, and payment streams to the provider one epoch at a time. The chain, not the provider and not the renter, decides whether each epoch is paid.
One bond, many roles
Compute rental is not a separate business with its own collateral. A node that serves AI already declares the capability, and renting out capacity rides the same role and the same bond. One node can serve inference, rent capacity and hold data at once, and one bond covers all of those obligations.
The network tracks everything a provider owes against that bond. Booking fails if the bond cannot cover a new rental on top of the provider's existing rentals, compute claims and storage deals. If the bond shrinks, through a withdrawal or a slash, the network rechecks coverage and sheds obligations until what remains fits.
To become a compute provider, run the node with the compute role and bond for it, declaring the accelerator classes you pledge:
tenzro-node --roles compute
tenzro stake deposit <amount> --provider-type compute --accelerator consumerThe bond stays slashable while a withdrawal cools down, so a provider cannot exit ahead of a dispute over work it already served.
The rental lifecycle
Quote
Before booking, a renter can ask a provider what a term will cost at its current rate:
curl -s https://rpc.tenzro.xyz \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tenzro_quoteRental","params":{"term":"weekly","periods":1,"price_per_hour":<price_per_hour_wei>}}'The result gives the duration, the total price and how many slots the node has for sale. Compare it with the compute price index, the network's reference price built from metered usage.
Fund
Rentals bill against a prepaid balance. Depositing moves TNZO out of the renter's account once into a key-less prepaid vault; each epoch draws from that balance, and the unspent remainder can be withdrawn at any time.
tenzro escrow prepaid-deposit --renter 0xRENTER --amount <wei>
tenzro escrow prepaid-balance --renter 0xRENTER
tenzro escrow prepaid-withdraw --renter 0xRENTER --amount <wei>Renters who price in dollars can pay in stablecoins; see Stablecoin payments.
Book
Booking locks the renter's exposure for the whole term, the per-epoch price times the number of epochs, and registers the provider's obligation against its bond. Nothing is paid to the provider yet.
tenzro node compute book-rental --renter 0xRENTER --total-epochs 24Settle each epoch on the chain's verdict
In every epoch the provider submits an availability proof, and the network checks it against the SLA the provider attested. The chain returns one of three outcomes:
| Outcome | What happens |
|---|---|
settled | The proof passed. One epoch's slice moves from the renter's prepaid balance to the provider. |
missed | The proof was missing or failed. No value moves, the renter keeps that slice, and the miss counts against the provider's SLA. |
closed | The term ended, the provider's bond no longer covers the rental, or misses crossed the threshold. The unearned remainder returns to the renter. |
tenzro node compute settle-epoch --rental-id <rental_id>
tenzro node compute rental --rental-id <rental_id>Because billing follows the chain's verdict, a renter never has to trust the provider's own report of uptime, and a provider never has to chase a renter for payment. See SLA attestation and metering.
Pricing
The provider chooses how its per-epoch rate is set:
- Fixed. A flat rate per epoch.
- Network-dynamic. The rate follows utilisation through an EIP-1559-style controller over a smoothed signal. When demand runs above target the rate rises; below target it falls. Each step is bounded, and the rate stays between a floor and a ceiling the provider sets.
tenzro node compute set-pricing --capacity <epoch_slots> --min-rate <wei> --max-rate <wei>
tenzro node compute statusPricing stays linear in the term. A discount for a longer commitment is a decision the provider makes explicitly. Renters always see the effective rate before they book.
Interactive access
A rental can include a shell on the hardware. There is no handed-out SSH key and no inbound port. Three things must hold before a session opens:
- A service key, issued by the operator for the lease, says which lease.
- A passkey sign-in against the renter's Tenzro wallet says who the renter is.
- The lease's authorised-wallet list says whether that wallet may use that lease.
A service key on its own reaches nothing: a leaked key is not a compromise, because the holder's wallet is not on the list. Revoking the lease ends every outstanding session grant at once. Every session leaves a receipt naming the wallet that actually signed in.
# Operator: open a lease tied to a rental
tenzro shell lease open --service-key <key> --wallet 0xRENTER \
--renter-did did:tenzro:human:... --rental-id <rental_id> --gpu 0 --term-hours 24
tenzro shell lease list
tenzro shell lease revoke --lease-id <lease_id>
# Renter: sign in with your passkey
tenzro shell login --service-key $TENZRO_SERVICE_KEY --account 0xYOUR_WALLETA lease scopes the session to named accelerators, a core count and a memory ceiling. Outbound internet is off unless the operator allows it, and the operator's local networks stay unreachable either way.
Confinement is required
A node with no confinement backend refuses every interactive session instead of running it on the host. A renter's shell runs inside a virtual machine boundary, with GPU passthrough so accelerators still work. The operator supplies the launcher, because passing a GPU through a VM boundary depends on the host.
One rule is absolute: a node offering the TEE provider role cannot rent out a shell on the same enclave. A renter with a shell could read what the enclave holds, and its attestation would stop meaning what a relying party takes it to mean. The node refuses the lease.
Access classes
| Method | Class |
|---|---|
tenzro_quoteRental, tenzro_computeStatus, tenzro_computeRental, tenzro_computeGetRental, tenzro_prepaidBalance | open |
tenzro_computeBookRental, tenzro_prepaidDeposit, tenzro_prepaidWithdraw, tenzro_requestShellSession | owner (signed by the paying account) |
tenzro_computeSettleEpoch | owner (signed by the provider) |
tenzro_computeSetPricing, tenzro_openAccessLease, tenzro_revokeAccessLease, tenzro_listAccessLeases | admin (operator only) |
See RPC access.
SDK
The tenzro-sdk package exposes a compute client:
import { TenzroClient } from "tenzro-sdk";
const client = new TenzroClient({ endpoint: "https://rpc.tenzro.xyz" });
const rental = await client.compute.bookRental("0xRENTER", 24);
const status = await client.compute.status();
console.log(rental.rental_id, status.effective_rate_wei);Prepaid balances are managed through client.settlement (prepaidDeposit, prepaidWithdraw, prepaidBalance).
Related
- Compute claims and the price index to reserve capacity ahead of time.
- Decentralised storage, which shares the same bond and coverage.
- Settlement for how epoch payments move.