Providing inference
A provider runs the Katara node on a machine with a supported GPU, serves one or more approved bundles, and is paid in USDC for every reply it completes. There is no stake and no minimum commitment.
What you need
Section titled “What you need”- Apple Silicon today: a Mac with an M2 Pro, M2 Max, M2 Ultra, M3 Pro, M3 Max or any M4 chip and at least 24 GB of unified memory for the 8B bundle. Base M1, M2 and M3 chips are outside the bundle’s profile. Larger bundles state their own minimum.
- NVIDIA on Linux: a GPU with compute capability 8.0 or better, which means Ampere and after, and enough video memory for the bundle. Docker and the NVIDIA container toolkit, since the runtime ships as a container.
- A wallet on Katara (created in the portal) to register with and be paid to.
- A public HTTPS address the router can reach. Machines behind carrier-grade NAT need a tunnel; see Networking.
Hardware compatibility has the full tables: every supported chip and card, and which bundles each one can serve.
How it works
Section titled “How it works”- The node detects your hardware and shows which approved bundles it can run.
- You pick a bundle. The node fetches the pinned weights and checks every hash.
- You register once in the portal: your payout address, the node’s signing key, and its address.
- The node publishes signed price offers. The router sends you jobs when your offer wins.
- Each completed job returns a signed receipt. Katara settles it on chain and pays your address, less Katara’s fee: 2%, plus a fixed 0.012 USDC (0.018 with
upto) on a reply paid per request with x402.
A node serves one of the two networks: Live, paid in USDC on Avalanche C-Chain, or Test, paid in test USDC on Avalanche Fuji. Registration and settlement happen on the network it serves. Running a node has the commands.
Validation
Section titled “Validation”Validators send known prompts through the normal job path at intervals and score your answers. A provider that fails or stalls stops being picked for a few minutes, then gets tried again. Scores are kept per bundle and profile, so trouble with one does not follow you to another, and a tuple nobody has scored yet is not held against you.
Nothing beyond that happens on its own. Registration is withdrawn by hand, for serving something other than the pinned bundle or for forged receipts, not for a machine that turns out to be slow.
Your wallet key never touches the node. The node signs offers and receipts with a separate service key that you register alongside your wallet; rotate it from the portal at any time.
What The Node Reports
Section titled “What The Node Reports”The node describes the machine it runs on. It sends that description when it connects and every six hours after, signed with the same service key that signs your offers. The gateway will not accept offers from a node that has not sent one, so this is part of running a provider rather than an option in a config file.
What goes in it:
- The chip or graphics card, memory, compute capability, and core counts.
- The bundle and profile being served, and whether the machine met the profile.
- What the startup benchmark measured: first-token latency and tokens per second.
- Identifiers that distinguish one machine from another, so that a single machine cannot quietly register as several providers.
What never goes in it: prompts, replies, or anything about who is asking. The node does not keep those and does not send them.
A machine that fails its own checks reports that too, and then exits without serving. Those results are the most useful ones we get: they are how the hardware requirements in Hardware compatibility are set, and they are the reason a chip that works can be added to a bundle’s list.
Read Running a node next.