Compute rental.

Compute rental is not a separate role with its own bond. A node that serves AI already declares the capability; renting out compute rides the same serving role and the same stake. One node can serve inference and rent capacity at once, and a single stake covers both — accounted through one shared coverage tracker.

A consumer books capacity for a fixed term. Booking locks the consumer's exposure (price_per_epoch × total_epochs) and registers the provider's obligation against its stake. Booking fails if the stake cannot cover the new obligation on top of everything else the node owes — storage included.

book_rental(renter, provider, asset_id, price_per_epoch, total_epochs)

Each epoch the provider settles with an availability proof. The outcome is one of three: Settled (the proof was valid; one slice moved), Missed (no proof; no value moved and the consumer keeps the slice), or Closed (term reached, coverage lost, or the miss threshold crossed).

settle_epoch(rental_id, proof_valid) -> EpochOutcome

A rental is not paid up front. The consumer locks the full term, but value releases one epoch-slice at a time as the provider proves availability. Unspent term stays the consumer's until it is earned.

Both compute rental and per-byte storage bill against a renter's prepaid TNZO balance rather than debiting the on-chain account every epoch. A deposit debits the renter's real balance once and credits the prepaid ledger; each epoch streams a slice out of that ledger to the provider, or refunds it on a miss. A withdraw returns the unspent remainder. Every deposit, stream, and refund writes through to CF_SETTLEMENTS and hydrates on restart, so a locked deposit and any accrued provider credit survive a node restart mid-term.

# RPC
tenzro_prepaidDeposit
tenzro_prepaidWithdraw
tenzro_prepaidBalance

The provider chooses how its rate is set. Fixed names a flat rate per epoch. Network-dynamic tracks utilization through an EIP-1559-style controller over a smoothed signal — denominator 8 (per-step move bounded ±12.5%), 50% target, smoothing window 4. Consumers see the effective rate before they book.

The invariant is uniform across the network: the consumer pays from their TNZO balance; the provider earns into theirs. There is no separate settlement path for compute — it uses the same balances the rest of the network settles against.

Renting compute can include a shell on the hardware. The model is GCP OS Login + IAP and AWS SSM Session Manager rather than a handed-out SSH key: no inbound port, no long-lived credential on the node, and revocation in one action.

Three things must hold, and each answers a different question. A service key — issued by the operator, or minted automatically from the rental deposit — says which lease. A passkey ceremony against the renter's Tenzro wallet, in the browser-launch flow the wallet already runs, says who they are. The lease's authorized-wallet list says whether that wallet may use that lease.

A service key on its own reaches nothing. That is the point: a leaked key is not a compromise, because the thief's wallet is not on the operator's list. The ceremony yields a single-use grant valid for two minutes; revoking the lease kills every outstanding grant in the same action.

Every session leaves a receipt naming the wallet that actually verified — not the lease, which may authorize several — so an operator can say who was on their machine and when.

# renter
tenzro shell login --service-key $TENZRO_SERVICE_KEY --account 0xYOUR_WALLET

# operator
tenzro shell lease open --service-key <key> --wallet 0xRENTER \
  --renter-did did:tenzro:human:... --gpu 0 --term-hours 24
tenzro shell lease revoke --lease-id lease-...

A node with no confinement backend refuses every interactive session rather than running it on the host, and refuses at the first step — before the renter is sent to a browser.

A container namespace is not a defensible boundary against someone with a shell: they are in the same kernel as the operator's validator key, the node's RocksDB, and any other tenant's slice. A VM boundary is, and VFIO passthrough is what keeps GPU access working through it. Because the boundary is what makes the feature safe rather than an enhancement to it, its absence has to mean refusal.

The operator supplies the launcher, because getting a GPU through a VM boundary is host-specific — IOMMU groups, vfio-pci binding, whether the device supports MIG and at what granularity. A DGX Spark's partitioning options are not an H100's.

One hard rule: a node advertising the TEE-provider role cannot rent out a shell on the same enclave. A renter with a shell can read whatever the enclave holds, so its measurement would stop meaning to a relying party what they take it to mean. The node refuses the lease rather than letting an operator quietly sell both.

# RPC
tenzro_computeBookRental
tenzro_computeSettleEpoch
tenzro_computeGetRental
tenzro_computeSetPricing
tenzro_computeStatus

# CLI
tenzro node compute status
tenzro node compute book-rental --asset <id> --epochs <n>
tenzro node compute settle-epoch --rental <id>
tenzro node compute set-pricing --mode <fixed|dynamic>

# Interactive access — RPC
tenzro_requestShellSession      # renter: start the passkey sign-in
tenzro_openAccessLease          # operator (admin-gated)
tenzro_revokeAccessLease
tenzro_getAccessLease
tenzro_listAccessLeases

# Interactive access — CLI
tenzro shell login
tenzro shell lease {open,revoke,list}