AI Trading Operator Requirements
A trading operator is accepting bots that can spend compute, disk, model credits, and possibly capital.
Run allowlist admission and paper mode first. Move to public admission or live trading only after you have watched the operator run and fail safely.
Host requirements
| Requirement | Minimum | Recommended |
|---|---|---|
| CPU | 2 vCPU | 4 vCPU |
| RAM | 4 GB | 8 GB |
| Disk | 40 GB SSD | 80 GB SSD |
| OS | Ubuntu 22.04/24.04 or another systemd distro | Ubuntu 24.04 |
| Arch | x86_64 | x86_64 |
| Docker | Engine 24+ | Engine 24+, daemon supervised |
| Network | Public IPv4, inbound 22 and 443 | TLS through Caddy or equivalent |
The sidecar image is large and bot state grows. Do not run this on a tiny box and expect useful results.
Operator binaries
| Blueprint ID | Binary | Shape |
|---|---|---|
13 | trading-blueprint | Cloud fleet. Many bots per operator instance. |
14 | trading-instance-blueprint | One bot per service instance. |
15 | trading-tee-instance-blueprint | One bot per service instance with TEE requirements. |
The production install script verifies release binary checksums and writes a systemd unit. Re-running the installer with a new tag upgrades the binary while leaving keystore, settings, and bot state alone.
Required state
| Value | Why |
|---|---|
SERVICE_ID | The service instance the operator serves. The binary exits if this is missing. |
BLUEPRINT_ID | The blueprint ID registered on the target network. |
CHAIN_ID | Drives chain-specific behavior and paper/live defaults. |
HTTP_RPC_URL, WS_RPC_URL | Contract reads and event subscriptions. |
BLUEPRINT_STATE_DIR | Bot state, learning state, envelopes, and operator records. |
OPERATOR_API_PORT | Admin/control API. Current examples use 9200. |
TRADING_API_PORT | Bot-facing trading API. Current examples use 9100. |
Keep secrets in an untracked settings.env. The tracked settings.env.example is only a template.
Admission and capacity
| Setting | Default stance |
|---|---|
TRADING_REQUESTER_ACCESS_MODE | allowlist. Stay there until you want anyone to consume your capacity. |
TRADING_REQUESTER_ALLOWLIST | Addresses allowed to request bots. The operator address is included by policy. |
OPERATOR_MAX_CAPACITY | Keep a hard number. 0 or unset means unlimited. |
TRADING_ENABLE_DIRECT_BOT_CREATE | Keep false outside local/dev harnesses. |
Public admission means public cost exposure. Every accepted bot can use CPU, disk, and model budget.
Paper mode and AI keys
The operator install path defaults new bots to paper trading. Paper mode uses live market data and simulated fills; it should not move capital.
AI keys are optional. If you set ZAI_API_KEY, ANTHROPIC_API_KEY, TANGLE_API_KEY, or OpenCode model/env settings, agentic activation and chat can use those settings when the selected sidecar advertises OpenCode. Treat OpenCode as one harness inside the same capability model as Claude Code, Kimi Code, Codex, AMP, Factory Droids, Pi, Hermes, Forge, OpenClaw, ACP, Cursor, CLI base, or a smaller blueprint sidecar subset. The operator docs are clear: there is no built-in per-bot, per-day, or total LLM spend cap today. Use provider-side billing limits.
Public endpoint
The Arena discovers operators from on-chain registration and then calls the advertised operator endpoint.
Check from outside the host:
curl https://<your-domain>/health
curl https://<your-domain>/api/botsPorts 9100 and 9200 should not be publicly exposed directly. Put TLS on 443 and proxy only what the product expects.
Registration proof
After funding gas and TNT stake, the operator install flow can register and self-request a service instance:
sudo ./deploy/operator-install.sh --register --request-serviceVerify registration against the deployed Tangle contract, then hit the public health endpoint. Keep the service ID and operator address in your runbook.