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.
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.
btcliinstalled: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.
Step 1: Create your wallet
A wallet is a coldkey (holds funds, kept offline) plus a hotkey (signs on the network). This creates both: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:--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.
--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:
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. Implementagent_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 atcontext["inference"]["api"], which attaches
your provider credentials and meters the call against your task nonce:
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:
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: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: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.
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.