Run an RPC provider

Serve Tenzro Network 1 to developers, agents and organisations: bond, expose your node, issue API keys, publish a policy and get paid per use.

An RPC provider serves the network to the people and machines that use it: JSON-RPC, the OpenAI-compatible model routes, MCP and A2A. Anyone can become one. There is no approval step and no allowlist; you bond, publish your policy and start serving. Providers range from a single well-connected machine in a homelab to independent data centres and neo-clouds running fleets for their own customers.

What makes a Tenzro RPC node different from a plain gateway is that the operator surface is built in: scoped API keys, per-tenant metering, rate tiers, private models, rentals and settlement are part of tenzro-node, not something you build in front of it.

How you get paid

Callers reach your node in three ways, and each pays differently.

Caller	Credential	Pays
User	None	Per request, over HTTP 402 with x402 or MPP, in TNZO or stablecoins
Subscriber	An API key you issue	On the terms you agreed, within the key's scopes and tier
Renter	A service key tied to a lease	Up front or prepaid, for raw capacity: compute, storage, memory

Metering runs for all three, so you always know what each tenant consumed. Per-use settlement is the default and settles on the chain. See SLA attestation and metering and Settlement.

Requirements

A machine that can run tenzro-node with a public address, good uplink and a TLS-terminating reverse proxy. There is no fixed hardware floor; size for the traffic you intend to carry.
A TPM 2.0 or Secure Enclave if the same node validates. See Deployment.
A bond in TNZO for the rpc provider type. Bonds are slashable and unbond over 7 days.
A signed operator policy stating what you serve and what you commit to. You are slashed only for a provable breach of your own policy, such as missed commitments that the network's SLA probes attest.

1. Run the node with RPC exposed

bash

tenzro-node \
  --roles fullnode,ai \
  --data-dir /var/lib/tenzro \
  --rpc-addr 0.0.0.0:8545 \
  --web-addr 0.0.0.0:8080 \
  --external-rpc-addr https://rpc.example.org \
  --trusted-proxy 10.0.0.2

--external-rpc-addr is the public URL peers and discovery advertise for your node.
--trusted-proxy names the reverse proxies whose X-Forwarded-For header the node will believe. Without it the header is ignored and the socket address is used, which is the safe default.
Set TENZRO_ADMIN_TOKEN in the node's environment from your secret store. It authorises every admin method on this node and nothing anywhere else.

Add --mcp-addr 0.0.0.0:3001 and --a2a-addr 0.0.0.0:3002 to serve MCP and A2A too.

2. Bond as a provider

bash

tenzro stake deposit <amount> --provider-type rpc
tenzro stake info

One stake covers every role your node takes. Add --provider-type model, compute or storage bonds if you also serve those.

3. Decide what you serve and to whom

Model access follows the model, not the machine:

bash

tenzro model serve <model-id>             # network: announced, anyone can call by paying
tenzro model serve <model-id> --gated     # not announced; only callers with a key you issued
tenzro model serve <model-id> --private   # callers of this node only; never served off-node
tenzro provider pricing set ...           # your prices
tenzro schedule ...                        # when your hardware is available

Control what your node advertises with tenzro visibility show|hide|publish. A private node is still reachable by the keys you issue; it just is not listed in discovery.

4. Issue API keys to customers

bash

tenzro admin api-key create \
  --label acme --subject did:tenzro:human:... \
  --scope inference --scope storage --scope database \
  --tier standard

Scopes decide what a key reaches, the tier decides its rate budget and whether it may write, and the class decides who may revoke it. Customers can list and revoke their own keys with tenzro key list-mine and tenzro key revoke-mine. See API keys.

storage and database keys make the key's subject the owner of their files and databases, each isolated per tenant. If you run a Canton participant, you can also offer mediated DAML ledger access with the canton scope; your customers never hold your upstream credentials. See Canton.

5. Offer rentals

Renters get confined use of your hardware for a term rather than answers from it:

bash

tenzro shell lease open ...     # issue a service key and open a lease
tenzro shell lease list
tenzro shell lease revoke ...   # ends the lease and its grants

The renter signs in with tenzro shell login and their passkey. A service key alone opens nothing; your lease must also name their wallet. See Compute rental.

6. Run it well

Watch /ready (height, lag behind the network tip, peers) and scrape /metrics.
Rate tiers protect you from any single key; -32005 tells callers when to retry.
Put the node behind a service key (tenzro admin service-key add) if it should serve only your own customers. Liveness probes and consensus traffic are never gated.
Keep the admin token off the public internet and rotate it if it leaks.
Keep your policy current. It is what callers read before they choose you, and the only standard you are held to.

Onboarding help

Operators of any background can join on their own with the steps above. Commercial partners such as Tenzro Labs help operators onboard and run fleets, and the Tenzro Foundation maintains the node software, documentation and tools. See Partners and Operators.