Skip to content
Tenzro
Documentation menu
Build and operate

Run an RPC provider

Serve Tenzro Network to developers, agents and organisations: stake, expose your node, set its access policy, publish an operator 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 stake, 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: an access policy per surface and method class, hardware-bound sign-in, per-caller metering, private models and settlement are part of tenzro-node, not something you build in front of it.

How you get paid

CallerCredentialPays
AnyoneNonePer request, over HTTP 402 with x402 or MPP, in TNZO or stablecoins
Signed-in callerA DPoP-bound access token from a passkey or a machine's hardware keyPer use, from the caller's own account
RenterA stream escrow it opened to your accountStreamed by the hour from the rental's escrow

Metering runs for every caller, so you always know what each one 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. The node's identity, and your operator sign-in, are hardware keys. See Deployment.
  • Stake in TNZO for the rpc role. Stake is slashable while it unbonds.
  • 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 ai \
  --data-dir /var/lib/tenzro \
  --rpc-addr 0.0.0.0:8545 \
  --web-addr 0.0.0.0:8080 \
  --mcp-addr 0.0.0.0:3001 \
  --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.

2. Stake for the role

bash
tenzro stake bond --role rpc --amount <AMOUNT_WEI>
tenzro stake info

Bond ai, compute or storage too if you also serve those. See Operators and roles.

3. Decide who may use the node

Who may use the node at all is its access policy, per surface (RPC, MCP, A2A, Web API) and per method class: open, signed in, named DIDs, agents under terms, or closed. It never gates consensus and peer-to-peer traffic, or /health and /ready.

bash
# Sign in as the operator with this machine's hardware key
tenzro access sign-in

# Read and replace the policy
tenzro access show > access.toml
tenzro access set access.toml

# Check what a caller would be allowed before you ship a change
tenzro access preview --did did:tenzro:human:... --surface rpc --class owner

# Live tokens the node issued, and revoking one
tenzro access tokens
tenzro access revoke --jti <TOKEN_ID>

There are no admin tokens and no API keys. Admin methods need a DPoP-bound access token of the node's operator DID or an administrator the policy names. See RPC access.

4. 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 your policy admits
tenzro model serve <MODEL_ID> --private   # callers of this node only; never served off-node
tenzro schedule set --start 09:00 --end 21:00 --timezone UTC

Set prices:

bash
tenzro provider pricing set --input-price-wei <WEI> --output-price-wei <WEI>
tenzro provider pricing show

Control what the node advertises with tenzro visibility set <VISIBILITY>; tenzro visibility show reads it back.

5. Offer rentals

Renters get the use of your hardware for a term rather than answers from it. A renter opens a stream escrow to your bonded account, at a price agreed directly or in a task market a harness runs, and it streams to you by the hour while the validators' SLA probes find you available. See Compute rental.

6. Run it well

  • Watch /ready (height, lag behind the network tip, peers) and scrape /metrics.
  • Keep your access policy as narrow as your business needs; tenzro access preview shows the effect of a change before you make it.
  • 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.

Related: RPC access, API reference, Operator policies, Slashing.