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. Clients then discover you by reading the registry and probing your endpoint.

You write these records from the operator dashboard at operator.zerosignal.ai, signing with your cold owner wallet, before you bring the node online. The node doesn't register itself. You configure it with the resulting operator and node ids, and it stamps them onto the tickets it signs. Every action on this page happens on the dashboard: adding yourself as an operator, adding and updating nodes, setting the staging flag, and deregistering. None of them is a node CLI command (see what's not in the CLI). The quick start walks the first registration end to end.

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. Keep it secure and separate from your hot signing keys.
Status	Active or evicted. Only the admin moderation action (evictOperator) sets evicted: it tombstones the record and slashes a configurable percentage of your staked USDC (the remainder stays reclaimable). An admin can later reinstate the record, but 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). An NFD is also what the node uses to publish DNS and obtain a TLS certificate, so if you want built-in HTTPS, which account owns it matters: see Which account signs the DNS writes.
Stake and rolled-up metrics	Your locked USDC stake plus aggregates the protocol maintains as you serve: tickets opened and settled, average latency and throughput, total revenue.

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 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, and it carries the port, which must be the port server.listen binds, since DNS resolves only a name. Max 248 bytes. The node can keep this field current as your address or port changes; see Reaching your node.
Status	Active. A node record exists only while active; removing it deletes the record rather than flipping a flag.
Staging flag	Holds 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	Latency and throughput averages and ticket counts, written by the protocol, not by you.

The operator/node split, and why it matters

Operators and nodes covers what the split is for. It also lets you:

• 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.

danger

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, signing key, and base URL under the same operator. Clients already spread load across your nodes by price and measured performance. A single TLS-terminating reverse proxy in front of one node is fine; a load balancer across multiple instances of the same node id is not.

A one-replica Kubernetes workload is fine too. Set server.private_listen to ":9091", since the default binds loopback and a kubelet probe dials the Pod IP, and set the grace period and probes as in Graceful shutdown.

Your name and avatar

A linked NFD shows your name and avatar in place of your address in:

• a model's details,
• the ⓘ beside an answer a user received from you,
• a user's starred operators,
• the operator dashboard's operator directory and your operator's detail page.

In the chat app the name links to your NFD profile on NFDomains.

You link it when you register your operator, or later by updating it: type the name (myoperator.algo) into the dashboard's NFD field. The dashboard resolves the app id and refuses to save unless the connected wallet owns that NFD. An advanced option lets you enter the app id directly.

What shows depends on your setup. With no linked NFD, the chat app falls back to looking up your owner address in the NFD registry:

Your setup	Chat app shows	Operator dashboard shows
Linked NFD	The linked name, which always wins over the address lookup. If it stops resolving (deleted, expired), the shortened address, never a different name.	The linked name
Unlinked, but an NFD is verified against your owner address	That NFD's name	No name: it reads only the linked app id
Neither	Your shortened address	No name

Link one explicitly to choose which name shows (you own several, or the one you want isn't the primary for your address), or to show the name on the operator dashboard.

The avatar comes from the NFD itself, so you change it on NFDomains. The app picks up the change with nothing to re-register. An NFD without an avatar shows just the name.

warning

You can link an NFD only while your cold owner wallet owns it, and the node doesn't hold that key. A node running tls.mode: acme against an NFD the owner wallet still holds starts fine, then fails on the first certificate renewal. Read Which account signs the DNS writes for the ways out, including moving the NFD to the signing address afterwards, before you link one.

Coming online

To bring a node into service, connect your owner wallet on the dashboard, then:

1. Register (or reuse) your operator record and lock the operator-level stake.
2. Register a node record with its signing address and base URL. If the node will manage that URL, your best guess is fine; it reconciles it on first boot. Your first node is covered by the operator-level stake (no extra USDC); each additional node locks an incremental per-node stake.
3. Stand up the endpoint so it answers the details probe and the inference routes (see Serving models & pricing and the endpoint reference).
4. 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, active clients pick it up within about five minutes (see Health & compatibility). A new node record starts out of staging. To verify the node end to end before it takes real traffic, set its staging flag on the dashboard before you start it.

Going offline

• Temporary maintenance: take the node down. Clients detect it's unreachable, route around it, and probe it less often 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.