SayGM

# gm-miner

Miner image and CLI for the [gm](https://saygm.com) Bittensor subnet (netuid 28 mainnet, 482
testnet). Buyers point an existing OpenAI / Anthropic / Gemini SDK at the gm gateway and get
identical behavior; miners supply upstream API capacity and earn the spread. The gateway runs
inside an Intel TDX TEE so neither operators nor host machines see buyer content or miners'
upstream keys.

You bring your own provider API keys (Anthropic, OpenAI, Google, Chutes, Z.ai, Moonshot,
DeepInfra, KubeTEE, Engy, Moonmath, NEAR AI Cloud, or Bedrock/Foundry/Azure transport backends
behind the existing Anthropic/OpenAI routes) and your own funded
[Phala Cloud](https://cloud.phala.network) account. Transport capability is not registry
admission: Azure OpenAI chat completions and Foundry Messages are qualified only when the
image's `upstream-model-hop` feature and the registry's `upstream-model-echo` capability are
both present. Azure Responses is unqualified because its echo is the deployment name, and
Bedrock inference is disabled: requests return 421 with a slot header and 400 without one. Direct
Anthropic/OpenAI routes use verified key slots enforced by the miner runtime. The `gmcli` tool
handles the full operator lifecycle from your laptop.

| Path | Description |
|---|---|
| `image/` | Miner container image with eleven provider routes (Anthropic / OpenAI / Gemini / Chutes / Z.ai / Moonshot / DeepInfra / KubeTEE / Engy / Moonmath / NEAR) and an optional `benchmark` route to a synthetic upstream. Anthropic can target direct Anthropic, AWS Bedrock, or Microsoft Foundry; OpenAI can target direct OpenAI or Azure OpenAI. NEAR requests pass through an in-image verifier which attests the exact upstream TLS connection before forwarding. Pinned to digest. At startup the entrypoint mints the data-plane RA-TLS certificate (one-shot), then runs the attestation server, optional NEAR verifier, and Envoy data plane. |
| `cli/` | `gmcli` CLI (Rust + clap). Operator commands handle login, image registration, products, and prices. The image also uses its hidden `slot-env` command to derive upstream key slots inside the TEE. |
| `dstack/` | Docker Compose template for the miner workload; `gmcli deploy` renders it and submits it to Phala Cloud. |
| `docs/` | Operator-facing docs including reproducibility caveats. |

## Quick start

Three steps to a running miner.

1. **Install the Phala CLI** (the miner deploys to Phala Cloud) and have a funded account:

   ```sh
   npm i -g phala
   phala auth login          # or set PHALA_API_KEY
   ```

   A new miner needs a funded Phala Cloud account — sign up at <https://cloud.phala.network> and
   create an API key (Dashboard → API Keys).

2. **Install gmcli:**

   ```sh
   curl --proto '=https' --tlsv1.2 -LsSf \
     https://github.com/taostat/gm-miner/releases/latest/download/gmcli-installer.sh | sh
   ```

   The installer places the binary in `~/.cargo/bin` (or `CARGO_HOME`) and ensures that
   directory is on your `PATH`. To install a specific version, replace `latest/download` with
   `download/<tag>`, e.g. `https://github.com/taostat/gm-miner/releases/download/v0.1.0/gmcli-installer.sh`.

   To upgrade later:

   ```sh
   gmcli update
   ```

   That replaces the binary in place with the latest release and needs no login. Nothing warns
   you when your CLI is behind, so a documented command that reports `unrecognized subcommand`
   usually means an upgrade is due rather than a missing feature; `gmcli --version` confirms
   what you are on.

3. **Run the guided onboarding:**

   ```sh
   gmcli --network testnet init   # testnet (netuid 482)
   gmcli init                     # mainnet (netuid 28, default)
   ```

   `gmcli init` walks you through hotkey → login → provider keys → deploy → declare products,
   detecting and skipping anything already done. That's it.

## Manual setup (advanced)

Prefer to run each step yourself? `gmcli init` just orchestrates these:

### 1. Register your hotkey

Your miner earns emissions under a Bittensor hotkey. Record it with `gmcli register-hotkey`.

**Bring-your-own (no btcli needed):** if you already registered the hotkey elsewhere (a browser
wallet, Bittensor explorer, or another machine), pass the ss58 address directly:

```sh
gmcli register-hotkey --hotkey-ss58 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
```

**Assisted flow (requires btcli):** if you have not registered yet, omit `--hotkey-ss58` and
pass the btcli wallet and hotkey name. gmcli resolves the hotkey's ss58 from your local btcli
wallet, checks the subnet metagraph, and — when the hotkey isn't registered yet — prints the
exact `btcli subnet register` command for you to run. gmcli never signs an on-chain extrinsic
or touches your wallet keys; you run any wallet-signing command yourself:

```sh
gmcli register-hotkey --wallet miner --hotkey default
```

btcli is only needed for these read-only wallet/metagraph lookups in the assisted flow. The
bring-your-own path (`--hotkey-ss58`) has no btcli dependency.

### 2. Log in

Authenticate with Taostats (device-code OAuth). The browser opens automatically; pass
`--no-browser` to print the URL instead:

```sh
gmcli login
gmcli --network testnet login   # testnet
```

Credentials are stored in `~/.gmcli/config.json`.

### 3. Set your provider API keys

Your provider API keys (Anthropic, OpenAI, Google, Chutes, Z.ai, Moonshot, DeepInfra, KubeTEE,
Engy, Moonmath, NEAR) are baked into the miner container at
deploy time and stay inside the TEE — gm never sees them. Set the keys for whichever providers you
intend to serve:

```sh
gmcli set-api-keys --anthropic sk-ant-...
gmcli set-api-keys --openai sk-... --google AIza...
gmcli set-api-keys --chutes cpk-...
gmcli set-api-keys --zai zai-...
gmcli set-api-keys --moonshot sk-...
gmcli set-api-keys --deepinfra ...
gmcli set-api-keys --kubetee sk-...
gmcli set-api-keys --engy sk-...
gmcli set-api-keys --moonmath sk-...
gmcli set-api-keys --near near-...
```

Each flag replaces t