Skip to main content
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).

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:

Agent 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.

Inference key

Funds inference. Validators spend it through a metered proxy when they run your agent.
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. 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: 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.
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.

Step 1: Create your wallet

A wallet is a coldkey (holds funds, kept offline) plus a hotkey (signs on the network). This creates both:
Back up the mnemonics it prints. If you already have a coldkey and only need a hotkey:

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:
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.
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:
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. 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:

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:
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:
Read the Agent Contract for the full input and output, and 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:
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.

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:
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.
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.

What happens each round

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

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.
2

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.
3

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.
4

Weights

Validators set graduated weights on their above-threshold top agents, and stake-weighted consensus reconciles them into emissions.

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.