
The validator's evaluation pipeline for one round: screening, sandboxed execution with the liveness check, ground-truth scoring, results posting, threshold and graduated weight setting, and on-chain consensus.
All four tracks, every round
There is no track to choose. Every validator evaluates every track each round (skills, mcp_servers, packages, repositories), so the per track emission shares are enforced inside each validator’s own weight vector and no track can go uncovered. Miners still commit to a single track; validators cover them all. See The Four Tracks.Eligibility
Chain eligibility is permissionless. You need both:- a validator permit, granted by stake weight, and
- positive vtrust, which proves you are actively setting weights.
Requirements
- A Linux host with Docker and
docker compose. The validator executes untrusted miner agents, so the Docker jail is mandatory: agents run only inside it, and if the jail is unavailable execution does not proceed. btcliinstalled:pip install bittensor-cli.- A Bittensor wallet with enough stake to hold a permit.
- Capacity for a full four track pass per round. Each sandbox run is pinned at 2 GB memory and 1 CPU, so N agents in parallel need roughly N × 2 GB RAM. The floor specification is 16 vCPU / 32 GB RAM / 100 GB disk. See The Round Model.
- Outbound access to
ghcr.io(the public validator, proxy, and sandbox images), toapi.phyi.dev(round scheduling, agent fetch, results), and to the chain endpointwss://entrypoint-finney.opentensor.ai:443. - An accurate system clock (NTP): every request to the backend is signed with a timestamp the server verifies, so a drifting clock fails authentication.
- The four labelled corpora ship inside the validator image; nothing to download. A validator abstains from any round where a track’s corpus is missing rather than submit a partial result.
Authorization is layered: the chain grants the validator permit purely by stake
(the top hotkeys by stake, recomputed every epoch, about 72 minutes), vtrust
accrues from actually setting weights, and the backend independently verifies
your request signature, your permit, and that your IP is registered in the
operator managed allowlist. Registering your IP and hotkey with the Phylax team
is a required onboarding step. Until both the permit and the registration land,
the validator logs a single warning per state and keeps retrying; it recovers on
its own once authorized.
Step 1: Create your wallet
--network test.
Step 2: Register on netuid 76
Put 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. Verify you landed on the metagraph:
Step 3: Stake for a permit
A validator permit is granted by stake weight. Add stake to your hotkey:Step 4: Install and configure
.env. The corpus ships with the subnet and weights go on chain; the
validator polls the server for round scheduling and posts results back to it.
Without a server it falls back to block-derived round timing, so it can still run
end to end for local development.
The installer writes a complete validator only .env: the backend identity is
pinned, the proxy token is generated, and the docker group id is detected.
There is nothing to fill in (PHYLAX_VALIDATOR_LABEL is optional).
ghcr.io/praxi-labs/phylax-agent, the hardened image Phylax publishes; every
miner’s untrusted code runs inside it, never inside a miner supplied image) and
the inference proxy address (http://phylax-proxy:8900, the sandbox’s only
egress, so every agent LLM call is metered). Neither is an env choice.
The three values the installer filled, and what they are:
PHYLAX_SERVER_HOTKEY pins the backend’s on chain identity so your validator refuses an impostor that tries to feed it fake rounds or agents. It is a fixed public value that every validator uses. The installer pins it; verify it anytime:
PHYLAX_PROXY_ADMIN_TOKEN is a secret shared only by your own validator and proxy containers. Your validator uses it to read per task inference metering from the proxy. No one issues it; the installer generates it. Regenerate anytime:
DOCKER_GID is your host’s docker group id. The validator launches sandbox containers by talking to the docker socket, so it must belong to that group. The installer detects it:
Step 5: Run
Confirm it’s healthy
The logs should show the validator connect and begin polling:submission wait while miners are
still submitting, or task execution once the window closes. Quick checks:
docker compose psshows the validator, proxy, and watchtower allUp.btcli wallet overview --wallet.name validator --network finneyconfirms your hotkey is on netuid 76 with a validator permit, and shows your vtrust once you set weights.curl -s https://api.phyi.dev/v1/server-identityreturns the same hotkey you put inPHYLAX_SERVER_HOTKEY.
image pull failed, the sandbox image is unreachable (see the note above) and the validator abstains rather than evaluate outside the jail. A docker socket permission error means a wrong DOCKER_GID.
Staying current
Auto-updates are part of the validator deploy, not an add-on. Watchtower runs by default and watches the validator and proxy containers; when a new image is published it pulls it and restarts that container in place, one at a time, so every validator moves to the same build without manualdocker compose pull. It polls
hourly by default (WATCHTOWER_POLL_INTERVAL, in seconds).
The sandbox image (phylax-agent) updates on its own, separately from
Watchtower: the executor runs docker pull on PHYLAX_SANDBOX_IMAGE before every
agent run, so with PHYLAX_SANDBOX_DIGEST unset it always resolves the latest
build. Pin the digest only when you want a frozen, reproducible sandbox.
The validator host must be able to pull
phylax-validator, phylax-proxy, and
phylax-agent from ghcr.io. These are public, so no login is needed — but if a
run fails with image pull failed, the sandbox image is unreachable and no
evaluation can proceed.What the validator does each round
The validator polls the server (/v1/rounds/next); when a round is due the server
returns its id and the frozen participant set, and the validator draws its tasks
for that round. Without a server, a block-derived fallback keeps local development
running.
1
Freeze and derive
When the round opens, read the participating agents pinned by hash, and draw
this round’s tasks from the frozen pool. The draw is deterministic and
reproducible.
2
Screen
Reject agents that are malformed, oversized, missing the entrypoint, or
showing abuse patterns, before they consume evaluation resources.
3
Execute
Run each pinned agent against every task,
r times, reduced to one verdict
by repetition consensus, inside your own hardened sandbox image
(cap-drop=ALL, no-new-privileges, non-root, internal network), each run
bounded by the per-task CPU budget and funded from the miner’s inference key
through the metered proxy.4
Score
Tally each agent’s task verdicts against ground truth over the whole task
set: clamped MCC on the behavioural tracks, F2 on repositories. A
behavioural run counts only if the validator observed its liveness probe.
See Scoring.
5
Publish and set weights
Post signed per-agent results and attestations to the server
(
/v1/rounds/results); it records them for the leaderboard and marketplace but
never decides the winner. Then apply the quality threshold, assign graduated
weights to your top-ranked eligible agents, and submit your vector on chain.