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.
Bedrock Mantle accepts models listed in the fixed network-selected registry binding snapshot
in `us-east-1`; it requires the `bedrock-mantle-model-bindings-v1` approved image feature and
the selected binding's row revision. The measured adapter validates the raw provider response
identity, then canonicalizes the response model before releasing content. Its request checks
keep the 20 MiB body limit and require a strict duplicate-key-free top-level JSON object, the
bound model id and optional boolean `stream`. It rewrites only the model and lets Bedrock
validate every other body field. It forwards one optional validated `anthropic-beta` header
unchanged; other buyer headers are not forwarded. The adapter supplies the worker credential
and fixed protocol headers. Older images and unadmitted models remain
unavailable. 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. Chutes `-TEE` requests pass through an in-image verifier which admits the Chutes instance on verified TDX, GPU and measurement evidence and encrypts each request end to end to its attested key. KubeTEE chat requests pass through an in-image verifier which attests each upstream TLS connection before forwarding on it. Pinned to digest. At startup the entrypoint mints the data-plane RA-TLS certificate (one-shot), then runs the attestation server, optional NEAR, Chutes, KubeTEE and Bedrock Mantle adapters, and the 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 Phala CLI 1.1.19 or newer** (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
```

gmcli validates the SS58 checksum and reads the hotkey's UID directly from Substrate
at a finalized block. This does not invoke btcli or download the full metagraph.
An absent hotkey or failed chain lookup stops registration with an explanatory error.

**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 subnet membership directly through Substrate, and — when the hotkey isn't registered ye