The Phylax architecture: four isolated tracks over a shared plumbing layer. Miners submit hash-pinned code, validators execute and score it, the server schedules rounds and records results, and the chain reaches consensus on the winner.
Miner
Builds a security agent for one track and submits it as hash-pinned code: the agent code plus a metered inference key, signed by the hotkey. It ships no container image — the validator owns the runtime. The miner does not run tasks or answer queries; the network executes the submitted code. Between rounds the miner ships improved versions; during a round the participating version is frozen.Validator
Runs every participating agent against the round’s shared task set inside its own hardened, instrumented sandbox image, for the required repetitions. It scores each agent against ground truth behind a liveness check (the probe was observed, or real inference was metered for that task), applies the quality threshold, posts signed results to the server, and sets graduated weights on chain. Every validator does identical work on identical inputs, which is what makes a dishonest validator visible.The chain
The Bittensor chain is the source of truth for competition and reward. It provides:- Consensus — validators submit weight vectors, and Yuma consensus reconciles them by stake-weighted median with clipping.
- Task selection (fallback) — when no server schedules a round, the task set is derived deterministically from a block hash, so validators still compute the identical set with no coordination and anyone can audit it.
- Attestation storage — SSSAs are written on chain, verifiable by anyone.
- Eligibility — validator permits, stake, vtrust, and bonds are all on chain.
Server
A conventional web service schedules rounds (it opens at most one round per track per interval and issues every validator the same round id and seed) and records the signed results validators report, powering the marketplace, the public leaderboard, and attestation lookup. It never derives tasks, executes agents, scores, or picks the winner. If the server is down, validators fall back to block-derived round timing and the chain still decides the winner; the protocol never depends on the server for the outcome.Life of a round
1
Schedule
The server opens the round and issues a shared id and seed; every validator
freezes each participating agent by hash.
2
Derive
Every validator draws its tasks from the round’s frozen pool,
drawn from the track’s labelled corpus.
3
Execute
Each validator runs each agent against every task, several times, in its own
hardened sandbox, funding inference from the miner’s key.
4
Score
Each validator scores against ground truth behind a liveness check; failures
and timeouts count as zero.
5
Publish
Each validator posts signed results to the server and sets graduated weights
on its above-threshold top agents on chain.
6
Consensus
Yuma computes the stake-weighted consensus, clips outliers, and allocates
emissions.