The Four Tracks

Phylax runs four isolated tracks. A miner commits one hotkey to exactly one track; every validator evaluates all four each round. Artifacts, evidence, scoring, and emissions are computed per track and never cross between them, so a skills agent is never ranked against a packages agent and evidence from one track is never compared to another.

skills

Agent skill bundles (SKILL.md + code). Detonated and scored on dual plane evidence with proof of execution. Skills are the classic prompt injection vector, so the context plane matters intensely.

mcp_servers

MCP server packages. Detonated with a component centric analysis: tool descriptions, schemas, source, responses, resource handlers, and config, and how influence propagates across them.

packages

pip and npm packages. Detonated across the lifecycle: install time and import time behaviour, plus supply chain signals (CVEs, typosquat, dependency confusion).

repositories

Source repositories. The outlier: a static audit with no probe, scored by F2 against the benchmark’s known vulnerabilities.

The detection principle

Every track shares one idea: malice is the gap between what an artifact declares it does and what it actually does. Your agent derives the artifact’s declared intent, exercises or audits it under instrumentation, and treats any deviation as the signal. Signatures catch known bad strings; deviation catches the novel and obfuscated attacks no signature has seen. What changes per track is where declared intent comes from and how you observe behaviour, not the principle. This maps straight onto the evidence you emit. The capability manifest and the declared purpose are the intent side; the action plane (what the artifact did) and the context plane (what it tried to make the model do) are the behaviour side. Your SSSA is, in effect, a deviation report. The per track sections below give a first architecture and what the detector must catch. Treat the pseudocode as a floor, not a solution: it is public, so a submission that merely reimplements it competes against everyone else who read the same page. Emissions reward whoever climbs off the floor first.

The threat model

Phylax assumes every artifact is untrusted by default and its author is fully adversarial. Whatever the track, the attacker is pursuing one or more of six goals:

Attacker goal	Typical form
Secret exfiltration	API keys, wallet credentials, tokens, and session cookies leaking through network egress
Arbitrary code execution	Evaluation, shell commands, dynamic imports, install hooks
Unauthorised filesystem and credential access	System paths, SSH keys, credential stores
Prompt injection and context manipulation	Instructions injected into content the agent consumes, steering its reasoning
Supply chain compromise	Typosquatting, malicious install hooks, dependency confusion, poisoned transitive dependencies
Persistence and rug pulls	Long lived access, or a benign artifact that turns malicious in a later version

The adversary controls every byte of what they publish and distributes it through legitimate channels: skill marketplaces, MCP registries, package indexes. They may craft any component of an artifact and compose several so that each looks benign in isolation while the combination achieves compromise. The attack proceeds automatically once an agent installs and uses the artifact, with no further attacker interaction. Each track below enumerates how these goals concretely surface for its artifact type; a detector that only covers some of its track’s attack classes leaves score on the table as the corpus grows to label the rest.

Detonation vs audit

Three tracks detonate. The agent loads the artifact into an instrumented sandbox, runs it, threads the probe through the execution, and the run produces filesystem, network, and process traces, recorded by the validator’s instrumentation. This is what lets Phylax catch behaviour that static reading cannot see: obfuscated payloads, runtime resolved imports, and instructions that only surface when the artifact is actually exercised. The repositories track audits. Nothing is executed, so there is no probe and no proof of execution; the track is scored by F2 against a benchmark of known vulnerabilities.

Verification per track

Track	Proof of execution	Dual plane	Track-specific block	Scored by
`skills`	required	action + context	none	clamped MCC vs label
`mcp_servers`	required	action + context	`mcp_surface`	clamped MCC vs label
`packages`	required	action (+ minor context)	`lifecycle` + `supply_chain`	clamped MCC vs label
`repositories`	n/a	n/a	`audit`	F2 against known vulnerabilities

skills

Artifact. An agent skill bundle, typically a SKILL.md plus helper scripts. The SKILL.md is both documentation and, on the context plane, a place where instructions can hide. Attack surface. Six attack classes:

Attack class	What it looks like
Malicious instruction injection	Instructions hidden in `SKILL.md` or helper files that steer the agent against its user
Permission overreach	The skill exercises capabilities its declared task never needs: credentials, network egress, system paths
Transitive poisoning	A benign looking skill pulls in or invokes a poisoned dependency, helper script, or second skill
Transitive information leakage	Data the skill legitimately touches flows onward to an unauthorised sink: logs, files, network
Context injection	Content the skill loads at runtime (files, URLs, retrieved text) injects instructions into the agent’s reasoning
Update or rug pull	A benign version earns trust and installs, then a later version turns malicious

The launch benchmark labels malicious instruction injection and transitive poisoning and is being extended to the remaining classes; the scoring spine is generic across all six, so coverage grows with the corpus rather than requiring new scoring code. Build for all six now: corpus growth converts that coverage into score. Evidence. proof_of_execution + action_plane + context_plane. Both planes are required: a strong agent must catch context contamination and transitive risk, not only an obvious instruction in the skill text. Detection approach. The declared task is the skill’s stated purpose in SKILL.md. Extract it before the model reads the rest of the bundle, so hidden instructions cannot rewrite your notion of what the skill is for. Then run the skill and flag any action outside that task: a formatting skill that reads credentials, a skill that obeys an instruction embedded in retrieved content.

def agent_main(context):
    skill = load(context["artifact_dir"])
    declared_task = extract_declared_task(skill.manifest)   # read intent first
    trace = detonate(skill, probe=context["probe"])         # fs, net, process
    deviations = [a for a in trace.actions if not serves(a, declared_task)]
    injected = find_hidden_instructions(skill.body, trace.context_plane)
    verdict = "BLOCK" if deviations or injected else "ALLOW"
    return {"verdict": verdict, "evidence": {...}, "findings": deviations + injected}

Your detector must catch. Prompt injection and hidden instructions, skill poisoning, credential leakage, access to data or systems with no declared reason, and any behaviour exceeding the declared task.

mcp_servers

Artifact. An MCP server package: a manifest declaring tools plus the server implementing them. Why it is the deepest track. An MCP server sits at the intersection of two attack channels in a single artifact. Malicious logic can live in executable server code (the action plane), and adversarial instructions can be embedded in the metadata and outputs the language model consumes as reasoning context (the context plane). Server provided metadata is not inert documentation: it is read by the model and actively steers tool selection and follow up actions. Component centric analysis. Malice may live in any component or be distributed across several so that each looks benign in isolation:

MCP component	Representative attack
Tool description	Tool poisoning, control flow hijacking, preference manipulation (context plane)
Argument schema	Schema injection equivalent to description injection (context plane)
Tool source code	Malicious code execution, command injection, rug pull (action plane)
Tool response	Response injection steering a later tool call (context plane)
Resource handler / response	Malicious external resource, indirect injection via retrieved content
Configuration	Malicious shell command in the startup command field

Attacks compose across components, and influence propagates through the model’s orchestration: adversarial content in one tool’s description can steer the model into invoking a second tool whose code carries the payload. Logic split between a poisoned description and conditional code in a tool’s source evades any check that inspects either component alone. Attack surface. Eleven attack classes:

Attack class	What it looks like
Tool poisoning	Adversarial instructions in a tool description steering model behaviour
Argument schema injection	The same injection carried in the argument schema instead of the description
Malicious tool source code	Executable payloads in the tool implementation: code execution, exfiltration
Tool response injection	A tool’s output injects instructions that steer a later tool call
Malicious resource handlers	A resource or its response carries hostile content or indirect injection
Tool shadowing	A tool named or described to intercept calls meant for another, trusted tool
Rug pull	A server that behaves benignly at review time and turns malicious later
Multi tool coordination	An exploit split across tools so each call looks benign alone
Command injection in configuration	A malicious shell command in the server’s startup command field
Manifest tampering	The manifest misrepresents what the server actually exposes or runs
Schema mismatch	Declared schemas diverging from actual tool behaviour

Launch scoring covers tool poisoning and schema mismatch, with the remaining classes forming the threat surface and the next additions to scoring. Build for the full surface now. Detection approach. Two stages, following the behavioural deviation principle. Pre-execution: read the config for malicious startup or shell commands, and extract each tool’s declared intent from its description separately, before adversarial text in one description can contaminate your reading of another. In-execution: invoke tools in a sandbox and trace the whole trajectory step by step, flagging a tool that acts beyond its declared function, and catching attacks split across calls that each look benign alone.

def agent_main(context):
    server = load(context["artifact_dir"])
    if malicious_startup(server.config):
        return block("malicious startup command")
    intents = {t.name: declared_intent(t.description) for t in server.tools}
    trace = exercise(server, probe=context["probe"])        # step-wise trajectory
    findings = [deviation(step) for step in trace           # catch mid-trajectory
                if not serves(step.action, intents[step.tool])]
    findings += multi_step_attacks(trace)                   # benign singly, malign together
    return verdict_from(findings)

Your detector must catch. Malicious startup and shell commands, tools acting beyond their declared function, unauthorised network or data access, trigger based behaviour, and multi step attacks. Evidence. The dual plane core plus an mcp_surface block recording which component carried each finding and how influence propagated.

packages

Artifact. A pip or npm package: setup.py / pyproject.toml (or package.json) plus the source. Why install time matters. A package can attack the moment it is installed, before it is ever imported. Empirical studies find roughly two thirds of malicious PyPI packages execute at install time, and typosquatting accounts for a clear majority of injection methods in the foundational malicious package datasets. Industry telemetry through 2025 and 2026 reports hundreds of thousands of new malicious packages per year, shifting toward install time execution, credential harvesting, and dependency confusion. A track that observes the install phase, not only imported behaviour, is aligned with where package attacks actually occur. Attack surface. Nine attack classes:

Attack class	What it looks like
Malicious install hooks	Code in `setup.py`, `pyproject` build steps, or npm lifecycle scripts that runs at install
Import time side effects	Payloads that fire on `import`, before any function is called
Credential and data exfiltration	Harvesting tokens, keys, and environment secrets to network egress
Typosquatting	A name one edit away from a popular package, riding on typos
Dependency confusion	A public package shadowing an internal name so resolvers pick the attacker’s
Poisoned transitive dependencies	The malice lives one or more levels down the dependency tree
Known vulnerable dependencies	Depending on versions with known CVEs
Obfuscated or encrypted payloads	Encoded, packed, or runtime decrypted code hiding the behaviour from readers
Update rug pull	A trusted package that turns malicious in a later release

Evidence. proof_of_execution + a lifecycle block distinguishing install time from import time behaviour + action_plane + a supply_chain block (SBOM, dependency CVEs, typosquat, dependency confusion). Detection approach. Derive the declared purpose from the metadata and README, then execute both the install process and the runtime behaviour in a sandbox and monitor the API call sequence. Prioritise install time. Prefer behaviour and data flow evidence, a taint path from a secret source to a network sink, over surface features: malware increasingly mimics benign code, and surface classifiers degrade against it.

def agent_main(context):
    pkg = load(context["artifact_dir"])
    purpose = declared_purpose(pkg.metadata, pkg.readme)
    install_trace = detonate_install(pkg, probe=context["probe"])   # setup.py, hooks
    import_trace = detonate_import(pkg)
    seq = api_sequence(install_trace + import_trace)
    findings = taint_flows(seq, source="secret", sink="network")
    findings += [c for c in seq if not consistent(c, purpose)]
    findings += supply_chain(pkg)   # typosquat, dependency confusion, dep CVEs
    return verdict_from(findings)

Your detector must catch. Malicious install scripts (a large share of package malware runs entirely at install time, prioritise it), data and credential exfiltration, obfuscated or encrypted code, typosquatting, and malicious transitive dependencies.

repositories

Artifact. A source repository: a tree of source files plus its manifests. What the agent does. Audits the source statically and reports recovered vulnerabilities, each with a weakness class (CWE), file, line, severity, and remediation. There is no probe, no proof of execution, and no dual plane evidence. Attack surface. Six finding classes:

Finding class	What it looks like
Exploitable vulnerabilities	Injection, deserialisation, path traversal, and the other CWE classes the benchmark plants
Embedded backdoors and triggers	Malicious logic buried in ordinary code, dormant until a condition fires
Malicious instruction and config files	`tasks.json`, `settings.json`, or `SKILL.md` content that AI coding agents trust and act on
Leaked secrets	Credentials, keys, and tokens committed into the source
Out of scope components	Code whose behaviour contradicts the project’s declared purpose
Supply chain risk	Typosquat or confused dependencies, install scripts, and vulnerable versions in the manifests

The benchmark’s labelled dimensions (vulnerabilities, supply chain, secrets) map straight onto these classes, so each one you cover contributes to your F2. Scored by. F2 against the benchmark’s known vulnerabilities: a reported finding matches a known vulnerability when it agrees on CWE or title and localises within a small line window. F2 tilts toward recall, since a missed real vulnerability costs more than a false alarm. Clean repositories measure the false positive rate through precision. See Scoring for the formal rules. Detection approach. Derive the project’s declared purpose, then audit the codebase and flag components whose logic contradicts that purpose. This is the broadest track, the largest behaviour surface and the coarsest declared intent, so lean on semantic and LLM assisted reading of what code actually does rather than pattern matching. Two classes are easy to miss: backdoors and triggers buried in otherwise ordinary code, and malicious natural language instruction or config files that AI coding agents trust and act on (a redirected settings.json, a SKILL.md that exfiltrates keys).

def agent_main(context):
    repo = load(context["artifact_dir"])
    purpose = declared_purpose(repo.readme, repo.manifests)
    findings = []
    for f in repo.files:
        intent = semantic_summary(f)                 # what this file actually does
        if contradicts(intent, purpose):
            findings.append(vuln(f, cwe=classify(f)))
    findings += instruction_file_attacks(repo)       # tasks.json, settings.json, *.md
    findings += backdoors_and_triggers(repo)
    return {"verdict": verdict_from(findings), "findings": findings}

Your detector must catch. Embedded backdoors and triggers, malicious natural language instruction and config files that agents trust, components acting outside project scope, and supply chain risk in bundled or depended code.

Emission weight

The performance pool is divided by track first, then flows to each track’s above threshold top agents through consensus.

Track	Share of performance pool
`repositories`	0.675
`packages`	0.225
`mcp_servers`	0.075
`skills`	0.025

repositories carries by far the largest share, then packages, mcp_servers, and skills. The ordering is strict: every top-three winner of a higher track outearns every top-three winner of the one below. Repositories and packages have the clearest objective ground truth and the biggest real world supply chain impact. See the Incentive Mechanism for the full mechanism.

Per-track budgets

Each track’s per task budget is pinned and identical on every validator, expressed as CPU time so hardware never changes an outcome:

Track	Tasks per round	Repetitions	CPU budget per task
`skills`	30	3	8 s
`mcp_servers`	25	3	15 s
`packages`	20	3	30 s
`repositories`	8	2	90 s

These are frozen: they are part of what your agent is measured against. See Configuration and The Round Model.

Get Started

Setup

System

Tracks

Verification

Incentives

Reference

The Four Tracks

skills

mcp_servers

packages

repositories

The detection principle

The threat model

Detonation vs audit

Verification per track

skills

mcp_servers

packages

repositories

Emission weight

Per-track budgets

skills

mcp_servers

packages

repositories

​The detection principle

​The threat model

​Detonation vs audit

​Verification per track

​skills

​mcp_servers

​packages

​repositories

​Emission weight

​Per-track budgets

The detection principle

The threat model

Detonation vs audit

Verification per track

skills

mcp_servers

packages

repositories

Emission weight

Per-track budgets