SSSA Schema

The Signed Skill and Supply chain Safety Attestation is the commodity the subnet produces: a standardised, content-addressed, machine-verifiable document that records a verdict, the evidence behind it, and the recommended enforcement policy, signed and written on chain. It is one shared envelope with a track-specific evidence block and a findings list.

Envelope (every track)

{
  "track": "skills | mcp_servers | packages | repositories",
  "artifact": { "name": "", "version": "", "bundle_hash": "sha256:…", "nonce": "" },
  "verdict":  { "decision": "ALLOW | WARN | BLOCK", "risk_score": 0, "confidence": 0.0, "summary": "" },
  "evidence": { },
  "findings": [ ],
  "attestation": {
    "agent_hash": "sha256:…",
    "miner_hotkey": "",
    "validator_hotkey": "",
    "signature": "ed25519:…",
    "canonical_hash": "sha256:…"
  }
}

Field	Type	Meaning
`track`	enum	One of the four tracks.
`artifact.name` / `version`	string	Identity of the analysed artifact.
`artifact.bundle_hash`	`sha256:`	Content hash of the analysed artifact.
`artifact.nonce`	string	The task nonce, derived from the round seed.
`verdict.decision`	enum	`ALLOW`, `WARN`, or `BLOCK`.
`verdict.risk_score`	0-100	The agent’s risk estimate.
`verdict.confidence`	0.0-1.0	The agent’s confidence.
`verdict.summary`	string	One-line human-readable rationale.
`evidence`	object	Track-specific, described below.
`findings`	array	The discrete issues found.
`attestation`	object	Agent hash, both hotkeys, signature, canonical hash.

Two signatures

Two signatures bind an SSSA to the parties behind it:

At submission time, the miner’s hotkey signs the agent artifact, which binds agent_hash to miner_hotkey in the on-chain submission record.
At evaluation time, the validator that executed the run assembles the SSSA, the attestation body the agent produced together with the proof-of-execution material the validator itself generated, and signs its canonical hash.

Attribution to the miner flows through the pinned agent_hash; authenticity of the run flows through the executing validator’s signature. Because validators, not miners, observe execution, it is the validator’s signature that vouches for the run.

Canonical hash and verification

Let the signed content be the SSSA with the attestation block removed. The canonicalisation applies Unicode NFC normalisation, sorts all object keys lexicographically, and removes insignificant whitespace:

C(m)  = sortkeys( NFC( serialize(m) ) )
h     = SHA256( C( sssa minus attestation ) )
sig   = Sign( validator_hotkey, h )

Any party recomputes h from the published SSSA by the same canonicalisation and checks the signature against the validator’s on-chain hotkey public key. The verifier additionally checks agent_hash against the round’s pinned submission record, which the miner signed at submission, to confirm which miner’s agent produced the verdict. Because the signed content includes the evidence and the findings, and NFC normalisation removes the composed-versus-decomposed ambiguity for non-ASCII text, the hash is stable across machines and verification succeeds offline, independently of any server. This is the formal basis for the claim that an SSSA is verifiable by anyone without trusting Phylax.

The finding object

Every finding shares a common shape; the allowed category and plane values differ by track.

{ "category": "", "severity": "LOW | MED | HIGH | CRIT",
  "plane": "action | context | protocol", "component": "", "title": "", "evidence_ref": "" }

Track	Allowed `category` values
`skills`	`instruction_injection`, `permission_overreach`, `transitive_poisoning`, `transitive_leakage`, `context_injection`, `rug_pull`
`mcp_servers`	the skills set plus `tool_poisoning`, `manifest_tamper`, `tool_shadow`, `schema_mismatch`; `component` names which MCP component carried it
`packages`	supply-chain categories, each with a phase of `install`, `import`, or `runtime`
`repositories`	the `vulnerabilities` list is the findings (see below)

evidence: skills

{
  "proof_of_execution": {
    "probe_evidence": { "file_write": "…", "dns_lookup": "…", "process_echo": "…", "canary": "…" },
    "traces": {
      "filesystem": { "hash": "sha256:…", "events": [ { "path": "…", "op": "write" } ] },
      "network":    { "hash": "sha256:…", "events": [ { "domain": "…", "proto": "dns" } ] },
      "process":    { "hash": "sha256:…", "events": [ { "cmd": "echo", "args": ["…"] } ] }
    }
  },
  "action_plane":  { "capabilities": [ { "capability": "POST_WEB", "group": "network", "protection": "dangerous", "evidence_ref": "…" } ] },
  "context_plane": { "injected_instructions": [ { "type": "instruction_injection", "excerpt": "…", "location": "…" } ] },
  "capability_manifest": ["POST_WEB", "READ_SECRET"]
}

The traces are recorded by the validator’s instrumentation during the run; capability names must come from the canonical taxonomy and be valid for the track.

evidence: mcp_servers

The dual-plane core plus an mcp_surface block:

"mcp_surface": {
  "exposed_tools": [ { "name": "", "declared_schema": {}, "observed_behavior": "", "schema_mismatch": false } ],
  "manifest_integrity": { "tampered": false },
  "tool_poisoning": [ { "tool": "", "excerpt": "" } ],
  "cross_component": [ { "path": "description -> tool_call", "note": "" } ]
}

evidence: packages

{
  "proof_of_execution": { "…": "…" },
  "lifecycle": {
    "install_time": { "hook_executed": false, "capabilities": [] },
    "import_time":  { "side_effects": false, "capabilities": [] }
  },
  "action_plane": { "capabilities": [] },
  "supply_chain": {
    "sbom_hash": "sha256:…",
    "dependencies": [ { "name": "", "version": "", "cves": [] } ],
    "typosquat": false,
    "dependency_confusion": false
  }
}

evidence: repositories

No probe and no dual plane. An audit block plus a vulnerabilities list, which is the findings:

{
  "audit": { "files_analysed": 0, "lines_analysed": 0, "coverage": "" },
  "vulnerabilities": [
    { "cwe": "CWE-89", "file": "src/db.py", "line": 42,
      "severity": "HIGH", "remediation": "use parameterised queries" }
  ]
}

Get Started

Setup

System

Tracks

Verification

Incentives

Reference

Envelope (every track)

Two signatures

Canonical hash and verification

The finding object

evidence: skills

evidence: mcp_servers

evidence: packages

evidence: repositories

​Envelope (every track)

​Two signatures

​Canonical hash and verification

​The finding object

​evidence: skills

​evidence: mcp_servers

​evidence: packages

​evidence: repositories

Envelope (every track)

Two signatures

Canonical hash and verification

The finding object

evidence: skills

evidence: mcp_servers

evidence: packages

evidence: repositories