Join the network as a provider

A provider is a node that serves paid work to others and answers for it with a bond. Anyone who bonds for a role can serve it; there is no list to be added to. Tenzro is an economy for distributed compute, with AI inference, rented compute, storage and data as roles of one network, open to machines of every size, from home nodes to data centers, and it runs alongside the centralized economy for these workloads. Payment follows paid, verified use: nothing is paid for being listed or for holding hardware.

This page covers the AI provider (model inference), the compute provider (rented capacity), the storage provider (data held for others) and confidential execution in a trusted execution environment (TEE), and how one operator combines them. Validators have their own page: Run a validator node.

What you can provide

The amounts are governed parameters; tenzro_getNetworkParams returns the values in force. Withdrawing a role stake takes stake.unbonding_ms (7 days at genesis), during which it stays slashable; a compute bond has its own cooldown (compute_bond.withdraw_cooldown_ms, 7 days at genesis).

Data providers

The protocol does not define a separate data-provider role. What an operator can do today with data:

• Hold data for others as a storage provider. A buyer opens a storage claim for an object; validators check each hour that you can still return it, and the claim pays hour by hour only for hours found available. See Decentralized storage.
• Publish entries to the registry, which is open: units of metered work, service types, price cards, apps and datasets are generic registry entries behind a governed bond, so a new kind of entry needs no node change. A registry entry names and prices a service; it is not a payment for holding data.
• Run an application beside the node, over its public RPC, MCP and A2A surfaces, that serves your own data or tools. A tenant file API, a search service or a knowledge endpoint is application-layer software (the harness), not a protocol role. Its pricing and access are yours, and you settle through the same payment rails.

Nothing is paid for holding data or for being listed. Payment follows a buyer's paid use. A dataset marketplace with its own settlement is not part of the launched network.

Security with TEEs

There is no separate security-provider role in the protocol. Confidential execution is a capability of the tee role: a node with Intel TDX, AMD SEV-SNP or AWS Nitro, or an NVIDIA GPU in confidential-computing mode inside such a confidential VM, bonds the role and attests its work. See Trusted execution environments for what is verified and by whom. A TPM and Secure Boot alone do not satisfy a confidential-compute requirement and cannot take the role.

A TEE reduces trust; it does not remove it. An attestation proves which software ran on which platform at which security level, with the platform vendor's keys as the root of that proof. It does not prove the software is bug-free, and a flaw found in a platform weakens the evidence from that platform. Confidential work needs the tee role bond; AI inference at the Verified and Confidential trust tiers needs a bonded provider.

Easy path

1. Install Tenzro: the MSI on Windows, the pkg on macOS, or one command on Linux, Raspberry Pi and Jetson (curl -fsSL https://downloads.tenzro.com/install.sh | sh). The deb and rpm packages are on Downloads too. See Install and first run.
2. Run tenzro and choose "Provide compute". The guide checks the machine (memory, graphics, hardware key, network), shows the exact command before it runs each step, and sets up your keys. A machine with no TPM, such as a Raspberry Pi, can keep its keys in another machine's TPM.
3. Bond for the role with tenzro join --provider once the account holds the TNZO the bond needs (tenzro sponsor check shows whether a sponsorship covers it).

The requirements and the manual steps follow, for operators who install by hand or script the setup.

Requirements

• Archive and operating system: any release archive in Supported hardware. A GPU is needed only for models above the CPU tier: the CPU build serves models of 6 GiB of weights or less and refuses a larger one. Use the CUDA build on NVIDIA machines and the Metal build on Apple silicon.
• Model fit: the node reads the machine's memory and accelerators and decides what loads. Run tenzro hardware and tenzro model list. By default 16 GiB is held back for the operating system and the node (--reserve-gb), always-resident models use up to 60% of what remains (--resident-ceiling-gb), and image and video pipelines load per job under their own ceiling (--on-demand-ceiling-gb).
• Identity hardware: a TPM 2.0 (Linux, Windows) or a Secure Enclave (Mac), or another machine's TPM through a key holder, as for validators. There is no software-key mode. See Hardware-rooted keys.
• Network: outbound UDP 9001 and outbound TCP 443. The node asks for no inbound port; direct reachability is optional and improves paths. A provider announces itself over the network's gossip, so no public address is needed. tenzro-node doctor reports how peers reach you.
• Storage capacity and bandwidth: a storage provider needs disk for every object it pledges plus the chain database, and enough upstream bandwidth to return chunks to validators' possession challenges. The code sets no minimum; pledge only what you hold. Past 90% disk use the node refuses non-essential data (model downloads, uploads).
• Funds: TNZO for the bonds above plus gas, in the operator account. tenzro join --provider stops and says so when the balance is below the bond.
• Models: serving inference is a commercial act. The node refuses NonCommercial-tier models unless started with --accept-non-commercial, and custom-license families (for example --accept-license gemma) until you have accepted their terms.

1. Download and verify

Download the archive and the signature files from Downloads, then:

cosign verify-blob --key tenzro-release.pub --insecure-ignore-tlog=true --signature SHA256SUMS.sig SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing
tar -xzf tenzro-node-linux-aarch64-cuda.tar.gz   # use the archive you downloaded
sudo install -m 0755 bin/tenzro-node bin/tenzro /usr/local/bin/
tenzro-node hardware

On a Linux CUDA archive keep lib/ beside bin/. tenzro-node hardware prints build:, gpus:, onnx: and startup:, and exits non-zero if the node would refuse to start. See Verify your download.

2. Provision the hardware key

On Linux, once per machine, as the user that will run the node:

tenzro-node tpm provision

On a machine without a TPM, such as a Raspberry Pi, the key lives in another machine's TPM: that machine runs tenzro-node tpm serve, this one runs tenzro-node tpm key-holder, and a passkey grant approves it (tenzro-node tpm grant-request, tenzro-node tpm grant-install). Start the node with --tpm-key-holder <socket> --tpm-label <label>. A reboot of the key-holder machine needs a new grant. A Pi runs the light build, which refuses the ai, compute and tee roles; it can follow the chain but cannot serve models.

3. Join as a provider

The guided setup detects the hardware, creates the identity and wallet, posts the bonds, registers you as a provider with default pricing, writes a service unit and starts it:

tenzro setup --path network --mode provide --apply

--mode provide selects the AI provider role. Add roles with --roles, for example --roles ai,storage. tenzro join --provider is the same provider flow against a node you already run: it checks the wallet holds the compute bond, posts it, bonds the ai role from the same wallet, registers default per-token pricing, then downloads and serves the largest catalog model that fits the machine. Fund the wallet first.

A node configured with a bonded role it has not bonded refuses to boot, and a runtime role change to one is refused. Check bonds with:

tenzro stake info --address <operator-account>
tenzro provider bond params

4. Serve models

To choose the model yourself:

tenzro model download qwen3-4b          # peer-first, BLAKE3-verified, falls back to Hugging Face
tenzro model serve qwen3-4b --public    # announce it
tenzro chat qwen3-4b                    # try your local copy

Visibility sets who can use a model: --public (announced; anyone by paying your price, 0 is free), --gated (announced as access-required; only callers your access policy names), --private (not announced; this node's own callers only). With none of them the model follows the node's visibility (tenzro visibility show). Private is about discovery, not access. See Model serving.

If a model does not fit one machine, the node forms a cluster from cluster-willing providers on the local network segment; --force-single refuses that.

5. Pricing

Pricing is yours; the network sets no price. A rate card prices units of metered work, such as input_tokens and output_tokens, in billionths of a dollar (settled in TNZO at the chain's rate) or in wei.

tenzro provider pricing show
tenzro provider pricing set --model qwen3-4b --denom wei \
  --line input_tokens=100000000000000 \
  --line output_tokens=200000000000000 --post

--post records the card on chain so receipts and disputes can name it. A call whose billable work the card does not price is refused rather than served free.

6. How you are announced, checked and paid

• Announcement: each model announcement is signed by the node's key on the tenzro/models and tenzro/providers gossip topics and carries your rate card and a SHA-256 of the served weights, so a caller can detect weight substitution before routing to you.
• Heartbeat: every serving node gossips a signed heartbeat on tenzro/providers every 2 seconds, with the live load of each model. A provider whose heartbeats stop for three intervals (6 seconds) is treated as down.
• Routing: callers choose by price, latency, reputation or a weighted score. Your standing is read from consensus state: zero without a live serving bond, otherwise a bonded part plus an availability part from validators' SLA verdicts.
• Availability checks: validators probe each SLA-checked bond (did:tenzro:role:<role>:<account>) and attest each hourly epoch. When two thirds of bonded stake agree on an unavailable verdict, the governed penalty is taken from the bond into the insurance pool.
• Settlement: inference is metered and paid per use in TNZO, or in stablecoins over x402 or MPP, to your wallet. Rentals are stream escrows released against hourly verdicts. Storage claims pay hour by hour for hours in which possession was proven. See Settlement.

tenzro provider status --detailed
tenzro provider list
tenzro provider scorecard <your-address>
tenzro wallet balance

When a provider goes offline

Once your heartbeats stop, selection, hedging and failover skip you, and the next clean heartbeat restores you at once. A request in flight is hedged to the next-best provider after a short delay. A multi-turn session that asked for continuity (standby or hot_successor) has a successor in the same jurisdiction that holds its cache and takes the next turn. Hours in which validators find your bond unavailable carry the penalty above. Nothing here is a promise of uptime: it is how the network treats an absent provider.

7. Combine roles on one account

One operator account, one hardware identity and one wallet can serve several roles: start the node with --roles ai,storage, or add tee on a machine with the hardware. Each bonded role is checked separately against the account's bond for that role, so fund every role you start. The resources are shared: model weights and the chain database compete with stored objects for disk, and models compete with the node's own services for memory under the ceilings above. Sizing the combination is yours; the node refuses non-essential data near a full disk and refuses a model it cannot hold.

For storage, bond the role and store objects with the node:

tenzro stake bond --role storage --amount 400 --terabytes 4
tenzro node storage store --object-id <id> --owner <address> --file <path>
tenzro node storage status

Objects carry an access policy (public, owner_only, did_allowlist or capability_required) and can be sealed with encryption at rest.

Operations

• Service: run under systemd (Linux) or launchd (macOS) with restart on failure, as in the unit on the validator page with --roles ai in place of --roles validator. The same hardware returns the same identity after a reboot; never run two nodes from one identity. Replace the binary and keep the data directory when you upgrade.
• GPU health: tenzro-node hardware re-runs the startup check. A CUDA build refuses to start with no usable GPU or driver. The CUDA runtime and driver come from the machine.
• Ports and firewall: nothing inbound is required; keep the RPC (8545), web (8080), MCP (3001) and A2A (3002) listeners on loopback. To serve RPC publicly you need the rpc role and your own TLS reverse proxy with --external-rpc-addr.
• Monitoring: curl http://127.0.0.1:8080/ready, /status and /metrics (including tenzro_inference_requests_total and tenzro_settlements_total). Watch tenzro provider list for your models' state and load, and the disk watermarks (prune at 75%, refuse non-essential data at 90%).
• Backups: keys are in hardware and cannot be backed up. tenzro-node backup --dest <dir> copies the newest epoch snapshot. Credentials and wallet records live in the data directory.
• Corrupt chain database: follow the recovery steps on the validator page; peers return the chain state.
• Policy: publish a signed operator policy so routers and clients can filter on what you serve and refuse. You can be slashed only for a provable breach of what you declared. See Operator policies.

Resource management

Every control below is a flag or configuration key of the node; defaults are those of the node reference. Nothing here is a measured efficiency claim.

Not found in the node reference: a network bandwidth cap, a CPU cap, or a GPU selection or GPU memory limit flag. Cap those with the service manager (for example CPUQuota= and MemoryMax= in the systemd unit); the repository documents no such limits for production units, only for its test harness. An idle chain makes no empty blocks; with no transactions the leader mints on a long heartbeat (10 minutes by default), and the cost of idle consensus rounds has not been measured here.

To see utilization, read /metrics on the web port (8080, loopback) and /status. tenzro_livenessStats runs one sweep of identity liveness TTLs and is not a utilization gauge.

For a provider, capacity is declared per node (ProviderCapacity: max_concurrent_requests, requests_per_second, max_batch_size), and each heartbeat reports, per model, its state (cold, warming, warm, evicting), requests in flight against the most it admits, and the queue of requests waiting on a warm-up. A provider's schedule and capacity are registry entries in the protocol registry. Models are loaded with tenzro model serve and unloaded with tenzro model stop; a load the memory ceilings cannot hold is refused. A standby replica ([standby] enabled = true, models, fee_per_hour) stages models in host memory without device memory. See tenzro provider list for the load of each model.

Leaving

Stop the node, then unbond. Unbonding starts a period during which the stake stays slashable for work already served.

tenzro stake unbond --role ai --amount 1000
# after the period
tenzro stake withdraw --role ai
tenzro provider bond withdraw --did <your-did> --address <your-address>
# after the cooldown
tenzro provider bond finalize --did <your-did> --address <your-address>

Known limits

• Whether the order of bonding and first start differs for a first-time provider is covered by tenzro setup; the manual order is not documented here.
• Tests of TEE verification that need real hardware (an NVIDIA GPU with its driver, a reachable Intel attestation service) are ignored in CI. The verifiers are tested against vendor-published evidence from an Intel TDX quote, an AMD SEV-SNP report and an NVIDIA H100.
• Nothing on this page is a measured result on this network: no throughput, latency, uptime or earnings figure is stated or implied.
• ROCm, Vulkan and non-NVIDIA GPUs are built from source and not run by us; see Supported hardware.

Next steps

• Model serving, Compute rental and Decentralized storage.
• Trusted execution environments, Operators and roles and Operator policies.
• Serve a model on Tenzro for a single-model walk-through.