How Tenzro distributes compute
How work reaches independent providers on Tenzro Network: the provider registry and heartbeats, routing, failover and session continuity, sharded expert models, rented capacity, and what each mechanism does and does not claim.
Tenzro Network is an economy for distributed compute and decentralized AI, open to machines of every size, from home nodes to data centers. It runs alongside the centralized economy for these workloads, and centralized data centers remain both supply and customers. It routes work across machines that already exist. Operators are both supply and customers: the same account that serves work can buy it. Work goes to the hardware that can do it, chosen by price, latency, standing and the filters a caller sets. This page describes the mechanisms that exist today. It makes no claim about cost, latency or capacity, and it does not describe a network that replaces any other infrastructure.
Inference is one kind of compute
The network carries several kinds of work from independent providers, each with its own role and bond (see Operators and roles):
- Model inference in every modality, metered per use. See Model serving.
- Rented capacity: a renter opens a stream escrow to a compute provider, which accrues per epoch and pays only for epochs that validators judged the provider available. See Compute rental. Capacity bought ahead is a compute claim, settled on the same verdicts.
- Storage held for others, settled hour by hour on possession proofs. See Decentralized storage.
- Confidential execution with attestation. See Trusted execution environments.
- Agent sandboxes: an OpenShell sandbox runs an agent under Terms its controller approved, with its model calls routed to Tenzro serving nodes. See OpenShell.
A provider's schedule and capacity are expressed as registry entries in the protocol registry; finding a provider and agreeing a price happens in an application layer over the public RPC, and the chain holds the money and the verdicts.
Provider registry and heartbeats
A node that serves models registers each one with the network. Its announcements on the tenzro/models and tenzro/providers gossip topics are signed by the node's key and carry its price card and a SHA-256 of the weights it serves. Every serving node also gossips a signed heartbeat every 2 seconds with the live load of each model. A provider whose heartbeats stop for three intervals (6 seconds) is down; the next clean heartbeat restores it. Callers read the registry with tenzro_listProviders and price a request across providers with tenzro_quoteInference.
Routing
The router picks a provider by one of five strategies (lowest price, lowest latency, highest reputation, random, or a weighted score, which is the default), composed with extra filters; a caller can also require a trust tier. Standing is read from consensus state: zero without a live serving bond, otherwise a bonded part plus an availability part from validators' SLA verdicts. Every node ranks a provider the same way.
Failover and session continuity
Once a primary is chosen, the router can hedge: if the primary has not answered by a delay derived from its observed tail latency, the same request goes to the next-best provider and the first answer wins. Both failing, it retries further down the list. A multi-turn chat can ask for continuity (standby or hot_successor) with a jurisdiction pin; the network then assigns a successor in that jurisdiction that holds the session's cache and takes the next turn if the primary's heartbeats stop. These are mechanisms of the node and router; no failover time or success rate is stated here.
Models too large for one machine
A model that fits on one provider is served by that provider. For larger mixture-of-experts models, providers declare which expert weights they hold, and a dispatch planner sends each token's selected experts to their holders, each of which is settled for the work it did. On a local network segment, cluster-willing providers can pool into a pipeline for a model that does not fit one machine. See Distributed MoE and LAN clustering. These mechanisms are designed for large models and have not been measured end to end by us (the largest model served across machines has no recorded measurement). Training across clusters is not claimed here.
Small devices
The same codebase builds for small boards. A light node holds identity, makes payments, runs agents and storage, follows the chain and forwards inference calls to providers; it refuses the ai, compute and tee roles. The orchestration role of small devices and requests that cross tiers within one paid request are designed for, not yet measured on the launched network, so they are not claimed. The three measurements the charter requires before tier claims go public (a light build joining and being paid for work, the largest model served across machines, and one request crossing tiers, settled and paid) have not been recorded. See Supported hardware.
Local AI and sovereignty
What the code supports:
- Run models on hardware you control. Visibility (
public,gated,private) decides who may use a model; a private model is never announced or served off the node. See Operator policies and the access modes in Model serving. - Say where a provider is. A provider declares a coarse region (a country code or a continent-level region, never anything finer) and a jurisdiction. A caller reads them from the provider list, and a continuity session can be pinned to one jurisdiction.
- Keep keys in hardware. Account and node keys sit in a TPM 2.0, a Secure Enclave or a passkey, never in a file.
- Check what happened. Metered work yields signed receipts that anyone can verify against chain state.
What it does not guarantee: a region or jurisdiction field is a declaration by the operator, not an audit. It is not a statement of legal compliance in any jurisdiction, and the network does not give one. Where data may lawfully go is for you and your counsel to decide. A TEE narrows who can read data while it is processed; it does not remove trust in the platform vendor.
Not claimed
No cost, latency, capacity or availability figure, no comparison with other infrastructure, and nothing earned by holding hardware or by being listed. Payment follows paid, verified use.