Skip to content
Tenzro
← All tutorials
Tutorial · Operate

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.

Advanced60 min

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 Network 1 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. Post the bond and register

The compute bond is admission collateral, held in a vault derived from your provider DID. Check the minimum first, then post it and register as a model provider:

bash
tenzro provider bond params
tenzro provider bond post --did <your-did> --address <your-address> --amount <tnzo>
tenzro provider register --type model --did <your-did> --name "Example Inference" --max-concurrent 32

One bond covers every role on the node. If you later add compute or storage, register those types against the same DID.

3. Serve several models at the right visibility

Each model has its own visibility:

VisibilityAnnouncedWho can call it
public (default)yesanyone, paying per request
--gatednocallers holding an API key you issued
--privatenocallers 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 get-hash qwen3-8b

4. Price the work

Set per-token prices in wei (1 TNZO is 10^18 wei). Public callers pay per request, in TNZO or in stablecoins through x402 or MPP; settlement is metered per use.

bash
tenzro provider pricing set \
  --input-price-wei 80000000000000 \
  --output-price-wei 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 with API keys

Regular customers, and anyone using a --gated model, reach you with an API key you issue. Bind each key to the customer's DID so usage is attributable:

bash
tenzro admin api-key create \
  --label customer-a \
  --subject did:tenzro:human:<customer-id> \
  --scope inference \
  --tier standard

tenzro admin api-key list

The customer sends the key in the X-Tenzro-Api-Key header on the OpenAI-compatible routes. Revoke it at any time with tenzro admin api-key revoke. See API keys.

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 reputation and revenue

bash
tenzro provider status --detailed
tenzro provider capacity
tenzro inference router-metrics
tenzro wallet balance

Reputation comes from what paying callers experienced. Measured capacity, tail latency and hedges lost against you all feed routing. Keep your advertised capacity honest; callers rank on what the network has measured.

Next steps