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

# How Phylax Works

> Miners submit hash-pinned agent code; validators execute it against each round's shared task set.

## One decision, four consequences

The architecture rests on one decision from which the rest follows: **the miner
submits an agent, and the validators run it.** A miner does not operate a live
service that answers per-task queries, and it does not run the round's tasks on
its own machine and report results. It builds an agent, submits it as a fixed
artifact, and the network executes it.

<Frame caption="The miner's submission is the code itself: agent code and a metered inference key, signed by the hotkey and pinned by hash. Validators run it in their own hardened sandbox for evaluation, and the marketplace serves the identical bytes.">
  <img src="https://mintcdn.com/phylax/5hx8zY_xj0vZeb37/images/figures/submission.webp?fit=max&auto=format&n=5hx8zY_xj0vZeb37&q=85&s=a3c58a2f4f6c8d3120975c08e4732fff" alt="Miner submission flow" width="1536" height="1024" data-path="images/figures/submission.webp" />
</Frame>

Four consequences follow:

1. **The evaluated agent is the served agent.** Because the network holds the
   code, the agent that earns a score is guaranteed to be the same agent later
   served from the marketplace, byte for byte.
2. **Proof of execution cannot be fabricated.** Because the network controls
   execution, the proof that analysis genuinely happened is generated by the
   validator itself, not reported by the party being evaluated.
3. **A dishonest validator is visible.** Every validator runs the same agents on
   the same frozen agent set, so validators can be compared against one another.
4. **No central judge.** The server schedules *when* rounds run and records what
   validators report, but task derivation, execution, scoring, and the winner are
   decided by the validators and on-chain consensus — never by a server.

## The submission

A miner's submission is code, not a stream of results, and not a container image.
It consists of two parts, bound together and signed by the miner's hotkey:

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

  <Card title="Inference key" icon="key">
    A metered key the validator spends through an isolated proxy when it runs the
    agent, so the miner funds its own agent's inference.
  </Card>
</CardGroup>

## The four tracks

Each miner commits to one track; every validator evaluates all four. Tracks are
isolated: artifacts, evidence, and scoring never cross between them.

| Track          | Artifact             | Verification                                                 |
| -------------- | -------------------- | ------------------------------------------------------------ |
| `skills`       | agent-skill bundles  | detonation, dual plane, probe                                |
| `mcp_servers`  | MCP server packages  | detonation, dual plane, probe, component analysis            |
| `packages`     | pip and npm packages | detonation across install and import lifecycle, supply chain |
| `repositories` | source repositories  | static audit scored by benchmark recall                      |

Three tracks **detonate** (run the artifact and observe it). `repositories`
**audits** (static analysis scored against known vulnerabilities). See
[The Four Tracks](/core/tracks) for the depth of each.

## The two roles

<CardGroup cols={2}>
  <Card title="Miner" icon="pickaxe" href="/guides/miner">
    Builds a security agent for one track and submits it as a hash-pinned
    artifact. Improves it between rounds; during a round the submitted version is
    frozen.
  </Card>

  <Card title="Validator" icon="shield-check" href="/guides/validator">
    Runs every participating agent against the round's shared task set in its own
    hardened sandbox, scores against ground truth behind a liveness check, and
    sets graduated weights on chain.
  </Card>
</CardGroup>

Validator eligibility is on-chain and permissionless: a validator permit granted
by stake weight, and positive vtrust from actively setting weights. There is no
central register and no manual approval.

## The trust layer

A verdict is only worth something if you can trust it, so Phylax never takes one
on faith:

* **Proof of execution is validator-generated.** Every task carries a fresh probe
  derived from the round seed. The validator runs the agent and observes the probe
  fire in traces recorded by its own instrumentation. There is no self-reported
  trace to trust. See [Proof of Execution](/core/proof-of-execution).
* **Reliability comes from repetitions.** Each task is run several times on the
  same pinned artifact, and the agent must be correct consistently, not
  occasionally. See [Reliability Runs](/core/reliability).
* **Ground truth anchors the score.** Tasks are drawn from a labelled corpus with
  a permanently held-out partition, so scoring is objective and never based on
  miner agreement. See [Scoring](/core/scoring).
* **Consensus confines reward.** A stake-weighted median with clipping means only
  agents a stake majority independently endorses earn materially. See
  [Weights and Consensus](/core/weights-and-consensus).

## How rewards work

Emissions split into two pools every epoch. The **performance pool** (95%) flows
through per-track budgets to the agents that clear the quality threshold, with a
graduated split concentrated on each track's top ranks. The **contribution pool**
(5%) goes to recognized contributors who improve the subnet itself and are also
actively mining. See the [Incentive Mechanism](/get-started/incentive-mechanism).