Build a model-serving provider

Go beyond the one-command join: serve several models at different visibilities, sell subscriptions, publish a signed operator policy and earn certification.

tenzro join --provider gets one machine serving one model. A serious model-serving business needs more: several models with their own prices, some public and some reserved for counterparties, subscription keys for regular customers, an agent-facing MCP endpoint, and a public, signed statement of what you serve that callers can filter on. This tutorial builds that, step by step.

Prerequisites

A node with the ai role and a hardware-rooted identity. See Join the network as a provider.
TNZO for the provider bond.
A GPU is recommended. A public hostname helps if you sell subscriptions.
Your operator admin token exported as TENZRO_ADMIN_TOKEN for the admin commands below.

1. Profile the hardware and your identity

bash

tenzro hardware
tenzro node did-document

did-document shows your node's DID and every way of reaching it. The DID is derived from the node's TPM or Secure Enclave; it is the subject that bonds, policies, receipts and certifications all refer to.

2. Stake for the AI role

Stake is the collateral behind what you serve. Bond it for the ai role, in wei:

bash

tenzro stake bond --role ai --amount <AMOUNT_WEI>
tenzro stake info

If you later add compute or storage, bond those roles from the same account. Your node announces the models it serves on its own; there is no separate registration.

3. Serve several models at the right visibility

Each model has its own visibility:

Visibility	Announced	Who can call it
public (default)	yes	anyone, paying per request
`--gated`	yes, as access-required	callers your access policy names
`--private`	no	callers of this node only

bash

tenzro model download qwen3-8b
tenzro model download qwen3-30b-a3b

tenzro model serve qwen3-8b                 # public: open to the network
tenzro model serve qwen3-30b-a3b --gated    # reserved for subscribers

Every download is checked against the model's content-addressed manifest before it loads. Confirm what you are serving:

bash

tenzro provider models
tenzro model build-manifest --name qwen3-8b --path <MODEL_DIR>
tenzro trust verify-model-files --name qwen3-8b --path <MODEL_DIR>

<MODEL_DIR> is the directory on the node holding the model's files. build-manifest returns the manifest's BLAKE3 root, and tenzro_getModelProvenance with that root returns what independent observers reported for the same files.

4. Price the work

Set per-token prices on your default price card. Each --line is unit=price, here in wei (1 TNZO is 10^18 wei) because of --denom wei; without it, prices are in billionths of a US dollar. Add --model qwen3-8b to give one model its own card. Public callers pay per request, in TNZO or in stablecoins through x402 or MPP; settlement is metered per use.

bash

tenzro provider pricing set --denom wei \
  --line input_tokens=80000000000000 \
  --line output_tokens=240000000000000
tenzro provider pricing show

Compare your rates with the network before you settle on them. The compute price index, committed to consensus, gives a reference price per resource class. See Compute claims and price index.

5. Sell subscriptions through your access policy

Regular customers, and anyone using a --gated model, are named in your node's access policy by DID. Add a rule for the OpenAI-compatible surface, with a rate tier if you sell more than one plan:

toml

[[rules]]
surface = "openai"
class = "inference"
[rules.rule]
rule = "allow"
dids = ["did:tenzro:human:<customer-id>"]
orgs = []

bash

tenzro access set access.toml
tenzro access preview --surface openai --class inference --did did:tenzro:human:<customer-id>

The customer signs in once with a passkey or a hardware key and sends the access token with a fresh DPoP proof on each request. Usage is metered against their DID. Remove them from the policy to end the subscription, and withdraw live tokens with tenzro access revoke. See RPC access.

6. Expose an MCP endpoint for agents

Agents discover and call models through MCP. The node serves MCP on port 3001, bound to loopback by default. Expose it deliberately, behind your reverse proxy:

bash

tenzro-node --roles ai --data-dir ./data --mcp-addr 0.0.0.0:3001

Public read tools need no auth. Anything that spends money requires a signature from the paying account. See MCP server.

7. Publish a signed operator policy

Your operator policy is a machine-readable document, signed by your node's hardware key, that states what you serve and what you refuse. Routers and clients filter on it. It is also the only thing you can be slashed against: a provable breach of your own declared policy, shown by a signed receipt, slashes your bond. Nothing else in the policy exposes you.

json

{
  "type": ["TenzroOperatorPolicy"],
  "operator": "did:tenzro:machine:<your-node-id>",
  "sequence": 1,
  "validFrom": "2026-10-01T00:00:00Z",
  "validUntil": "2027-10-01T00:00:00Z",
  "serves": { "models": ["qwen3-8b", "qwen3-30b-a3b"] },
  "jurisdictions": ["EU"],
  "refuses": { "categories": ["malware-generation"], "unsafeFormats": true },
  "data": { "retentionDays": 0, "trainsOnInputs": false }
}

The full walk-through, including signing, publishing and updating a policy, is in Publish an operator policy and get certified.

8. Get certified

Certifications and ratings for operators and models are signed credentials that anyone can issue: an auditor, a standards body, a regulator, a customer or a community. No issuer is privileged by the network. Callers and routers choose the issuers they trust, and filter providers by the credentials those issuers have signed.

A certification for your operator names your DID as its subject. A certification for a model names the model's manifest root, so it covers exactly the weights you serve. Ask the issuers your customers rely on to review you, then confirm that the credentials resolve against your DID. See Credentials.

9. Monitor standing and revenue

bash

tenzro provider status --detailed
tenzro provider scorecard <YOUR_ADDRESS>
tenzro inference router-metrics
tenzro wallet balance

Your standing comes from your serving bond and the SLA verdicts validators record for you (tenzro reputation get). tenzro provider scorecard shows your standing on chain, the price cards you announced, and your settled count, value and p50/p95 latency over the last 24 hours and 7 days. Measured latency and hedges lost against you also feed routing; callers rank on what the network has measured.

Next steps

Serve a distributed MoE model for models too large for one machine.
Run confidential compute in a TEE to add attested inference.
Operator policies, Trust and provenance and Model serving.