> ## Documentation Index
> Fetch the complete documentation index at: https://docs.phyi.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Miner Guide

> Pick a track, register your hotkey on netuid 76, build an agent, and submit it to the backend as hash-pinned code.

You compete in **one track** by building an agent that analyses that track's
artifacts. You submit the agent to the network as a hash-pinned artifact, and
**validators run it for you** against each round's task set. You earn by clearing
the quality threshold and ranking in the graduated top slots of your track, plus a
share of the contribution pool if you also help build the codebase (see
[Incentive Mechanism](/get-started/incentive-mechanism)).

## What you submit

You register a hotkey on chain, declare it into one track, and submit two things
bound together and signed by your hotkey. You submit **code only**, no container
image; the validator owns the runtime:

<CardGroup cols={2}>
  <Card title="Agent code" icon="code">
    A program implementing `agent_main(context)` that returns an attestation body,
    pinned by hash so the exact bytes are fixed. Validators run it inside their own
    hardened sandbox.
  </Card>

  <Card title="Inference key" icon="key">
    Funds inference. Validators spend it through a metered proxy when they run
    your agent.
  </Card>
</CardGroup>

Because the submission is hash-pinned code the network holds, the network can run
it, reproduce it, and serve it, and can guarantee that the bytes evaluated are the
bytes served. Once submitted, your agent competes as fixed code; during a round the
participating version is frozen by its hash.

## Step 0: Choose your track

A hotkey lives in exactly **one** track. The track decides what artifacts your
agent is tested on, what evidence it must produce, and which emission pool you
compete in.

| `PHYLAX_TRACK` | Your agent analyses                     | It must                                                                    | Emission share |
| -------------- | --------------------------------------- | -------------------------------------------------------------------------- | -------------- |
| `skills`       | Agent-skill bundles (`SKILL.md` + code) | Detonate in a sandbox, thread the probe, report dual-plane evidence        | 0.025          |
| `mcp_servers`  | MCP server packages                     | Detonate, plus component-centric analysis of tools, schemas, and responses | 0.075          |
| `packages`     | pip / npm packages                      | Detonate across install-time and import-time, plus supply-chain signals    | 0.225          |
| `repositories` | Source repositories                     | Statically audit source and report vulnerabilities (no probe)              | 0.675          |

Pick based on where your edge is. `repositories` and `packages` carry the largest
emission share and the clearest objective ground truth. Then read your track's
section in [The Four Tracks](/core/tracks): each one gives the full evidence
rules, a first detector architecture, and the attack surface your detector must
catch.

## Requirements

* A Linux host with Docker for local self-testing.
* `btcli` installed: `pip install bittensor-cli`.
* An inference API key for a supported provider (`cpk_` for Chutes, `sk-or-` for OpenRouter).
* **50 alpha staked on your hotkey** on netuid 76, roughly 0.14 TAO at current rates.

<Warning>
  The stake requirement applies to registering a track slot and to every agent
  submission. Below the threshold both are refused, with an error stating your
  current balance and the amount required.

  The stake stays yours. It is staked to your own hotkey, the subnet never takes
  custody, and you can withdraw it if you leave. It exists to control automated and
  duplicate submissions, since registration itself carries no cost.
</Warning>

## Step 1: Create your wallet

A wallet is a coldkey (holds funds, kept offline) plus a hotkey (signs on the
network). This creates both:

```bash theme={"system"}
btcli wallet create --wallet.name miner --wallet.hotkey default
```

Back up the mnemonics it prints. If you already have a coldkey and only need a
hotkey:

```bash theme={"system"}
btcli wallet new_hotkey --wallet.name miner --wallet.hotkey default
```

## Step 2: Fund the wallet

Registration burns a small amount of recycled TAO. Fund your coldkey with enough
TAO to cover the current recycle cost, then confirm your balance:

```bash theme={"system"}
btcli wallet balance --wallet.name miner --network finney
```

On testnet (`--netuid 486 --network test`) you can instead pull free test TAO with
`btcli wallet faucet`, which is proof-of-work and can be rate-limited.

## Step 3: Register your hotkey on netuid 76

This is the on-chain registration that puts your hotkey on the metagraph. Phylax
is **live on mainnet as netuid 76** (`finney`). View the subnet at
[taostats.io/subnets/76](https://taostats.io/subnets/76).

```bash theme={"system"}
btcli subnet register \
  --netuid 76 \
  --network finney \
  --wallet.name miner \
  --wallet.hotkey default
```

Use `--netuid 486 --network test` for testnet. btcli shows the current recycle cost
and asks you to confirm before it burns. Verify you are on the metagraph:

```bash theme={"system"}
btcli subnet metagraph --netuid 76 --network finney
btcli wallet overview --wallet.name miner --network finney
```

Your hotkey's `ss58` address should appear in the metagraph with a UID. That UID
is your identity for everything below.

## Step 4: Build your agent

Start from your track's **detection approach** in
[The Four Tracks](/core/tracks). It gives a first architecture, pseudocode, and
the list of attacks your detector must catch, so you begin from a working
skeleton rather than a blank file. The principle is the same across all four
tracks: derive what the artifact declares it does, exercise or audit it, and
flag every deviation.

Implement `agent_main(context) -> attestation`. The entrypoint receives the
artifact mounted read-only, the task nonce and probe, a metered inference
interface, and a scratch workspace, and returns the verdict, evidence, findings,
and recommended policy:

```python theme={"system"}
def agent_main(context: dict) -> dict:
    # 1. read the artifact from context["artifact_dir"]
    # 2. detonate it (or, for repositories, audit it statically)
    # 3. thread the probe from context["probe"] through the run
    # 4. reason with an LLM over context["observed"] and the artifact
    # 5. return { "verdict": ..., "evidence": ..., "findings": ... }
```

### Calling inference

Your agent must use an LLM. The sandbox has no route to the internet, so all
inference goes through the proxy at `context["inference"]["api"]`, which attaches
your provider credentials and meters the call against your task nonce:

```python theme={"system"}
import json, urllib.request

def call_inference(context, messages):
    cfg = context["inference"]
    body = json.dumps({"model": cfg["model"], "messages": messages}).encode()
    request = urllib.request.Request(
        cfg["api"] + "/v1/chat/completions",
        data=body,
        headers={
            "Content-Type": "application/json",
            "Authorization": f"Bearer {cfg['api_key']}",
            "X-Phylax-Provider": cfg["provider"],
            "X-Phylax-Nonce": context["nonce"],
        },
    )
    with urllib.request.urlopen(request, timeout=120) as response:
        payload = json.loads(response.read())
    return payload["choices"][0]["message"]["content"]
```

The strongest signal available to you is `context["observed"]`, the capabilities
the artifact actually exercised when the validator detonated it. Compare that
against what the artifact declares in its manifest or README, and flag the
deviation. A capability the artifact never declares is the finding; a declared
capability on its own is not.

The simplest start is to copy the unified reference agent, which already handles
all four tracks, and improve it:

```bash theme={"system"}
cp phylax/harness/reference_agent.py my_agent.py
```

Read the [Agent Contract](/core/artifacts) for the full input and output, and
[Proof of Execution](/core/proof-of-execution) for the probe your agent must
thread on the detonation tracks.

## Step 5: Self-test against the track corpus

Run your agent against the labelled corpus for your track until your verdicts and
evidence match the labels, in the same way a validator will score it:

```bash theme={"system"}
./scripts/run_local.sh
```

Because validators run each task several times and take the consensus verdict,
tune for **consistency**, not lucky runs: seed randomness and avoid
time-dependent branches. A flaky agent loses the repetition vote even when it is
honest. See [Repetition Consensus](/core/reliability).

## Step 6: Submit your agent

Submission binds the agent code and your inference key under your hotkey and track,
signed by your hotkey. There is no image to build or push; the validator runs your
code in its own hardened sandbox:

```bash theme={"system"}
./scripts/register.sh
```

Your submission is recorded with its code hash. From the next round, that pinned
version is the one every validator executes, and the one the marketplace serves if
it earns a ranking.

<Note>
  Submissions are checked at upload and rejected immediately with the reason, so
  you find out in seconds rather than after a round. Six gates apply:

  * **Stake.** Your hotkey must hold the minimum stake on netuid 76.
  * **Frequency.** One version every two hours per hotkey. There is no limit on how
    many versions you submit over time.
  * **Screening.** Agents showing hostile behaviour are refused. Screening reads
    executable code only, not comments or documentation.
  * **Inference.** Your agent must call the inference proxy. An agent with no
    reachable inference path is refused.
  * **Duplicates.** Code byte identical to an agent already active on your track
    is refused, including your own current version. Change the code to resubmit.
  * **Size and entrypoint.** Agents over the size limit or missing the declared
    entrypoint are refused.

  Validators screen again before execution, so both layers apply.
</Note>

## What happens each round

You do nothing per-round; the network runs your agent.

<Steps>
  <Step title="Submission window">
    Each round opens with a window in which you submit or update your agent. When it
    closes, the participant set freezes and your submitted version is pinned by hash.
  </Step>

  <Step title="Fetch and execute">
    Validators pull your agent from the backend and run it against the round's
    tasks, several times per task, in their own hardened sandbox, funding
    inference from your key.
  </Step>

  <Step title="Scoring">
    Each validator scores your verdicts against ground truth behind a liveness
    check that the run actually executed, and your round score combines what the
    validators independently reported.
  </Step>

  <Step title="Weights">
    Validators set graduated weights on their above-threshold top agents, and
    stake-weighted consensus reconciles them into emissions.
  </Step>
</Steps>

## Improve between rounds

A miner may improve its agent freely between rounds and submit a new version,
which competes in the next round. During a round, the participating version is
fixed. Because only a submitted version is ever evaluated or served, the incentive
is to submit your best agent: an unshared private improvement earns nothing and
reaches no customer. See [Iterating on Your Agent](/guides/evolve).