Join Network 1 as a provider

Turn a home GPU, a homelab or a data centre into a Network 1 provider: install the node, root its identity in hardware, join, publish a policy and get paid.

Any machine can earn on Tenzro Network 1. A desktop with one GPU, a rack of second-hand servers in a homelab and a data centre with thousands of accelerators all join the same way: run the node, let it root its identity in the machine's hardware, and join as a provider. The network sends paid inference, rental and storage demand to you, and settlement lands in your wallet.

This tutorial takes one machine from install to serving a model and receiving payment. Everything the one-command join does automatically can also be done step by step, and the later steps show how.

Prerequisites

A Linux (glibc 2.31 or newer) or macOS 12+ machine, x86-64 or ARM64. A GPU is optional; CPU-only machines can serve smaller models.
A TPM 2.0 or a Secure Enclave on the machine, or a passkey on your phone or laptop to authorise it (see step 2).
TNZO in a wallet to post your provider bond. Create a passkey wallet in the Console if you do not have one.
Outbound internet access. A public IP is optional.

1. Install the node and the CLI

Tenzro ships two binaries: tenzro-node, which runs every role, and tenzro, the command-line client. Download them for your platform from Downloads, or build both from source:

bash

git clone https://github.com/tenzro/tenzro-network.git
cd tenzro-network
cargo build --release -p tenzro-node -p tenzro-cli
# binaries: ./target/release/tenzro-node and ./target/release/tenzro

To use a GPU, build with the backend that matches it. With no backend feature the node runs on CPU; Apple Silicon picks up Metal automatically.

bash

cargo build --release -p tenzro-node -p tenzro-cli --features tenzro-node/cuda    # NVIDIA
cargo build --release -p tenzro-node -p tenzro-cli --features tenzro-node/rocm    # AMD
cargo build --release -p tenzro-node -p tenzro-cli --features tenzro-node/vulkan  # most other GPUs

Check the install:

bash

tenzro-node --version
tenzro hardware

tenzro hardware prints the CPU, memory, accelerators and TEE capability the node will advertise. See Hardware discovery for what it detects.

2. Root the node's identity in hardware

On Network 1 a node has no key file. Its identity is derived from the machine's TPM 2.0 or Secure Enclave the first time it starts, and every signing key is derived from that hardware root on demand. The node's DID (did:tenzro:machine:...) is bound to the machine that produced it.

On a machine with a TPM 2.0 or Secure Enclave there is nothing to do: the next step roots the identity automatically.

Homelab boxes often have no TPM. Authorise them from something that does, either your own passkey or another machine you run that has a TPM. The machine generates its key, you approve it, and it runs as a delegated identity under your control:

bash

# on the machine being enrolled: name who may authorise it
tenzro node enroll begin --data-dir ./data --controllers set.json

# approve it with your passkey in the browser, then install the result
tenzro node enroll complete --data-dir ./data --assertion response.json

tenzro node enroll status --data-dir ./data

The authorisation expires after a set period; enroll status shows when, and you renew it the same way. Name more than one controller in set.json so the machine can still be administered when one of them is offline. See Hardware-rooted keys for the full model.

3. Start the node

Start the node with the roles you want to offer. ai serves models; you can add compute and storage now or later, and one bond covers every role on the node.

bash

tenzro-node --roles ai --data-dir ./data

With no --genesis or --boot-nodes flags the node finds Network 1 through its bootstrap peers and verifies the chain against the built-in Network 1 genesis. On first start it detects the hardware and roots its identity. Check that it is up:

bash

tenzro node status
tenzro node peers

Expected output includes the node state, the roles you started it with and a peer count above zero.

Run the node as a service (systemd on Linux, launchd on macOS) so it comes back after a reboot. Its identity is re-derived from the same hardware on every start. When you upgrade, replace the binary and keep the data directory.

4. Join as a provider

In a second terminal, run the one-command join against your local node:

bash

tenzro join --provider

This does five things in order:

Creates your provider identity and wallet, both rooted in the node's hardware.
Posts the compute bond from your wallet. The bond is admission collateral held in a vault derived from your provider DID; nobody holds a key to it.
Registers you as a model provider with default per-token pricing.
Downloads the largest catalog model that fits the machine, verified by hash against its manifest.
Starts serving it and announces your capacity to the network.

If the machine has a TEE, its attestation is enrolled at the same time. To drive a node you run elsewhere, add --rpc http://<your-node>:8545.

5. Publish your operator policy

Before real demand arrives, publish a signed operator policy. It states, in a machine-readable document signed by your node's hardware key, which models you serve, which jurisdictions you serve, what you refuse and how you handle data. Routers and clients filter on it, and you can only be slashed for a provable breach of what you declared.

A minimal policy looks like this:

json

{
  "type": ["TenzroOperatorPolicy"],
  "operator": "did:tenzro:machine:<your-node-id>",
  "sequence": 1,
  "serves": { "models": ["qwen3-4b"] },
  "jurisdictions": null,
  "data": { "retentionDays": 0, "trainsOnInputs": false }
}

Writing, signing and publishing a policy, and collecting certifications from issuers, is covered step by step in Publish an operator policy and get certified.

6. Watch demand arrive

Your node advertises its capacity automatically, and the router places requests with you based on price, latency, reputation and the trust filters callers apply.

bash

tenzro provider status --detailed
tenzro provider capacity

provider capacity lists what you advertise next to the throughput the network has measured for you, with tail latency and a reputation-adjusted figure. Callers rank on measured behaviour, so an honest advertisement pays.

7. Get paid

Inference is settled per use by default: each request is metered and paid in TNZO or in stablecoins through x402 or MPP, and the proceeds land in your provider wallet.

bash

tenzro wallet balance
tenzro provider pricing show

Tune pricing at any time. Prices are in wei per unit (1 TNZO is 10^18 wei):

bash

tenzro provider pricing set \
  --input-price-wei 100000000000000 \
  --output-price-wei 200000000000000

To receive stablecoins into a regulated wallet, see Stablecoin payments.

8. Grow or leave

Serve more models, add roles or increase your bond:

bash

tenzro model serve qwen3-8b
tenzro provider bond increase --did <your-did> --address <your-address> --amount 500

Leaving is two-phase. withdraw starts a cooldown during which the bond stays slashable for work you already served; finalize returns it once the cooldown ends. bond params shows the node's minimum and the cooldown length.

bash

tenzro provider bond params
tenzro provider bond withdraw --did <your-did> --address <your-address>
# after the cooldown
tenzro provider bond finalize --did <your-did> --address <your-address>

Next steps

Build a model-serving provider: several models, gated access and certification.
Sell compute with compute claims: rent out idle capacity.
Run a validator node: secure the network with the same machine.
Operators and roles and Operator policies.