Registering on-chain
There's no sign-up and no approval. You become an operator by writing two kinds of record to the on-chain registry — an operator record and one or more node records — and locking the required stake. After that, clients discover you automatically by reading the registry and probing your endpoint.
You write these records yourself from the operator dashboard, signing with your cold owner wallet, before you bring the node online — the node software doesn't register itself; it's configured with the resulting operator and node ids afterward and stamps them onto the tickets it signs. This page explains what the records contain and what each field commits you to, so you understand what you're publishing.
The operator record
Your operator record is your cold, top-level identity. One per operator, keyed by an operator id. It holds:
| Field | What it holds |
|---|---|
| Owner address | The Algorand address that receives your payouts. This is the account that accumulates revenue; keep it secure and separate from your hot signing keys. |
| Status | Active or evicted. The status flips to evicted only through the admin moderation action (evictOperator), which tombstones the record and slashes a configurable percentage of your staked USDC (the remainder stays reclaimable); an admin can later reinstate it, though already-slashed funds aren't restored. Voluntarily deregistering doesn't change this field — it removes the record entirely and returns your remaining stake. |
| An optional name | You can link an NFD (Algorand name) so your operator shows a human-readable name instead of a bare address (see Your name and avatar). It's optional; many operators run nameless. |
| Stake and rolled-up metrics | Your locked USDC stake plus network-maintained aggregates (tickets opened and settled, average latency and throughput, total revenue). You don't write the metrics; the protocol does, as you serve. |
The node record
Each node you run gets its own record under your operator, keyed by the pair (operator id, node id). This is the hot, per-endpoint identity clients actually route to. It holds:
| Field | What it holds |
|---|---|
| Signing address | The node's Algorand key. It signs your tickets and receipts and authorizes your escrow opens and settlements. It must be online and protected (see Encryption & keys). |
| Base URL | The public HTTPS endpoint clients reach this node at, including for relaying. It must be reachable from the open internet. |
| Status | Active. (A node record exists only while active; removing it deletes the record rather than flipping a flag.) |
| Staging flag | Set it to hold the node out of normal routing while you test (see Health & compatibility). Settable by the operator's owner or the node's own signing key while the operator is active. |
| Per-node metrics | Network-maintained latency and throughput averages, and ticket counts. Written by the protocol, not by you. |
The operator/node split, and why it matters
Registering an operator once and then attaching nodes to it lets you:
- Run many machines under one identity and one payout address. Add a node record per machine; they all settle to the same owner address.
- Replace or upgrade a node without disturbing your operator identity, stake, or reputation.
- Contain key risk. A node's signing key is a hot key; if one is compromised, the exposure is that node and its in-flight tickets — not your operator owner address or your whole fleet.
Clients route to nodes, keyed by (operator id, node id). Performance and
reachability are per node; stake, payouts, and reputation are per operator.
One node id = one running process. Never put a node behind a load balancer.
A node id is a single on-chain identity bound to a single hot signing key, and
the node keeps its admission state (in-flight reserve tickets) and its settlement
ledger in that one process. Running two or more instances for the same node
id — behind an L4/L7 load balancer, a Kubernetes Deployment with replicas > 1,
an autoscaler, or an active/active pair — does not work and corrupts
accounting: the instances double-admit tickets, race each other to settle the
same work on-chain, and strand receipts on whichever instance didn't serve the
request. There is no shared-state mode.
To scale, register more nodes, not more replicas. Each machine or replica gets its own node id, its own signing key, and its own base URL under the same operator. Clients already load-balance across your nodes by price and measured performance — that is the network's horizontal-scaling mechanism. A single TLS-terminating reverse proxy in front of one node is fine (it's just a TLS front door, not a fan-out); a load balancer that distributes requests across multiple instances of the same node id is not.
Running that single instance as a one-replica Kubernetes workload is fine. If you
do: give it a grace period long enough to cover the node's shutdown drain, split
its probes — readiness on /healthz, liveness on /livez — and set
server.private_listen to ":9091", since the default binds loopback and a
kubelet probe dials the Pod IP. Miss any of those and your own cluster kills
in-flight paid work. See Graceful shutdown.
Your name and avatar
Linking an NFD is how you get a face on the network. Wherever the app names the operator behind a model — in a model's details, on the ⓘ beside an answer a user received from you, and in their starred operators — your NFD name appears in place of your shortened payout address, with the NFD's avatar beside it, and the name links out to your NFD profile on NFDomains. The operator dashboard shows the same name and avatar in the operator directory and on your operator's detail page.
You link it when you register your operator, or later by updating it: type the
name (myoperator.algo) into the dashboard's NFD field and it resolves the
app id for you, refusing to save unless the connected wallet owns that NFD.
There's an advanced option to enter the app id directly if you'd rather.
The avatar is whatever the NFD itself carries, so you change it on NFDomains, not here — set (or update) the avatar on your NFD and the app picks it up on its own; there's nothing to re-register. An NFD without an avatar simply shows the name.
Coming online
To bring a node into service:
- Register (or reuse) your operator record and lock the operator-level stake.
- Register a node record with its signing address and base URL. Your first node is covered by the operator-level stake (no extra USDC); each additional node locks an incremental per-node stake.
- Stand up the endpoint so it answers the details probe and the inference routes (see Serving models & pricing and the endpoint reference).
- Advertise a valid, signed encryption recipient so clients will seal requests to you (see Encryption & keys).
Once the node is reachable, compatible, and advertising a valid recipient, clients pick it up on their next probe — typically within a minute (see Health & compatibility). Start with the node staged if you want to verify it end-to-end before taking real traffic.
Going offline
- Temporary maintenance: just take the node down. Clients detect it's unreachable, route around it, and back off their probe cadence until it returns. No deregistration needed.
- Retiring a node: deregister the node record to recover its stake and stop clients from trying it.
- Winding down entirely: deregister your nodes and then your operator, in good standing, to recover your stake.
Registration, staging, and deregistration are done from the operator dashboard by connecting your owner wallet — they're not node CLI commands (see what's not in the CLI). This page covers what the records mean; the quick start walks the first registration end to end.