SSSA Schema - Phylax

What an SSSA Is

A Signed Skill Safety Attestation (SSSA) is the document a miner returns from a dispatch. It carries the analysis verdict, the supporting evidence, the recommended runtime policy, and a signature over the whole thing.

SSSA = {
  schema_version: "1.0",
  skill: { ... },
  analysis: { ... },
  evidence: { ... },
  policy: { ... },
  signature: { ... },
}

The full SSSA must serialise to JSON, hash to a stable canonical value, and verify against the miner’s hotkey signature.

Top Level

Field	Type	Description
`schema_version`	string	Always `"1.0"` for the current schema
`skill`	object	Skill identification block
`analysis`	object	Verdict, risk, findings, capabilities
`evidence`	object	Trace hashes, sandbox manifest, LLM evidence
`policy`	object	Recommended enforcement policy
`signature`	object	Miner hotkey signature over canonical bytes

`skill`

Field	Type	Description
`skill_type`	enum	One of `rag_knowledge`, `declarative`, `executable_python`, `executable_script`, `mcp_server`, `agent_composition`
`bundle_sha256`	hex string	SHA-256 of the bundle bytes the miner received
`nonce`	hex string	The nonce the validator dispatched

The validator verifies that skill_type matches the dispatched task type and that bundle_sha256 matches the dispatched bundle.

`analysis`

Field	Type	Description
`verdict`	enum	`ALLOW`, `BLOCK`, or `REVIEW`
`risk_score`	float	[0.0, 1.0]
`findings`	list of objects	Detected risks
`capabilities`	list of strings	Declared capabilities (file_io, network, exec, env_read, etc.)
`dependencies`	list of objects	SBOM with CVE annotations

`analysis.findings[i]`

Field	Type	Description
`id`	string	Stable identifier within the SSSA
`category`	enum	One of `prompt_injection`, `secrets_exposure`, `excessive_capability`, `dependency_cve`, `tool_poisoning`, `transitive_risk`, `canary_match`, `other`
`severity`	enum	`low`, `medium`, `high`, `critical`
`description`	string	Human readable summary
`evidence_ref`	string	Reference into evidence block

The validator’s consensus uses canonical finding keys derived from (category, severity, evidence_ref hash) to match findings across miners. See Consensus.

`analysis.dependencies[i]`

Field	Type	Description
`package`	string	Package identifier (e.g. `requests`)
`version`	string	Resolved version
`cves`	list of strings	CVE IDs flagged for this version

`evidence`

Field	Type	Description
`trace_hashes`	object	Per file SHA-256 of normalised trace JSONL
`sandbox_manifest`	object	Image digest, runtime config
`probe_evidence`	object	Echo of the probe events the miner observed
`llm_evidence`	object	Optional. LLM enrichment, if used
`static_evidence`	object	Optional. Pre detonation static analysis results

`evidence.trace_hashes`

For runtime types, the miner must populate hashes for the relevant trace JSONL files.

File	Required for
`fs.jsonl`	All runtime types
`network.jsonl`	All runtime types
`process.jsonl`	All runtime types
`secrets.jsonl`	All runtime types
`mcp_io.jsonl`	`mcp_server` only
`taint.jsonl`	`executable_script` only
`cascade.jsonl`	`agent_composition` only

Each hash is the SHA-256 of the file content with normalisation applied: records sorted by ts, keys sorted within each record, no whitespace, no trailing newline.

`evidence.sandbox_manifest`

Field	Type	Description
`image_uri`	string	Registry URI of the sandbox image
`digest`	string	`sha256:...` digest
`runtime_config`	object	Capabilities dropped, network mode, resource limits

The digest must equal the image_hash the miner declared at registration. The validator checks this immediately on synapse receipt.

`evidence.probe_evidence`

Field	Type	Description
`file_path`	string	The file path derived from the nonce
`file_content`	string	The file content derived from the nonce
`dns_host`	string	The DNS host derived from the nonce
`process_echo`	string	The process echo string derived from the nonce

The validator independently derives the same four values from the nonce and verifies they match.

`evidence.llm_evidence` (optional)

Field	Type	Description
`model_id`	string	LLM identifier
`allowed_use`	enum	`finding_enrichment`, `mitre_owasp_mapping`, or `cve_explanation`
`prompt_hash`	hex string	Hash of the prompt sent to the LLM
`response_hash`	hex string	Hash of the LLM response

The validator rejects any other value in allowed_use. LLMs cannot be used to produce verdicts, findings categories, or policies. They can only enrich already produced findings with human readable text.

`policy`

The recommended runtime enforcement policy.

Field	Type	Description
`version`	string	Policy schema version, currently `"1.0"`
`default_action`	enum	`allow`, `deny`
`rules`	list of objects	Per resource rules

`policy.rules[i]`

Field	Type	Description
`resource`	enum	`file_io`, `network`, `process`, `env_read`, `secrets_read`, `mcp_tool`
`action`	enum	`allow`, `deny`, `prompt`
`pattern`	string	Match pattern (path glob, hostname pattern, etc.)
`reason`	string	Human readable reason

π scoring compares the miner’s policy to the task’s expected_policy, weighted as F-β with β = 0.5.

`signature`

Field	Type	Description
`signer_hotkey`	ss58 string	Miner hotkey ss58
`signature`	base64 string	Sr25519 signature over canonical bytes
`canonical_hash`	hex string	SHA-256 of the canonical JSON bytes that were signed

Canonical JSON: all keys sorted alphabetically at every level, no whitespace, UTF-8 NFC normalised. The signature covers every other top level field except signature itself.

Validator Side Checks

On receiving a SSSA the validator runs:

Check	Failure
Schema parse	Submission scored zero, reputation flagged invalid
`skill.skill_type` matches task	Scored zero, reputation violation
`skill.bundle_sha256` matches dispatched bundle	Scored zero, reputation violation
`skill.nonce` matches dispatched nonce	Scored zero, reputation violation
`sandbox_manifest.digest` matches registered image hash (primaries, runtime)	Scored zero, reputation violation
Trace hashes consistent (primaries, runtime)	Scored zero, reputation violation
Probe evidence matches nonce derived values	Scored zero, reputation invalid
`llm_evidence.allowed_use` is in the allowed set (if present)	Scored zero, reputation violation
Signature verifies against miner hotkey	Discarded, reputation invalid

Example: Minimal `declarative` SSSA

{
  "schema_version": "1.0",
  "skill": {
    "skill_type": "declarative",
    "bundle_sha256": "ab12...",
    "nonce": "f4e2..."
  },
  "analysis": {
    "verdict": "BLOCK",
    "risk_score": 0.82,
    "findings": [
      {
        "id": "f-1",
        "category": "prompt_injection",
        "severity": "high",
        "description": "Detected hidden role override at line 14",
        "evidence_ref": "static#span-14"
      }
    ],
    "capabilities": [],
    "dependencies": []
  },
  "evidence": {
    "trace_hashes": {},
    "sandbox_manifest": {},
    "probe_evidence": {
      "file_path": "/tmp/phylax/probe-f4e2.txt",
      "file_content": "f4e2probe",
      "dns_host": "f4e2.probe.phylax.local",
      "process_echo": "f4e2probe-echo"
    },
    "static_evidence": {
      "spans": [{"id": "span-14", "line": 14, "snippet": "..."}]
    }
  },
  "policy": {
    "version": "1.0",
    "default_action": "deny",
    "rules": []
  },
  "signature": {
    "signer_hotkey": "5GrwvaEF...",
    "signature": "aGVsbG8...",
    "canonical_hash": "9c0a..."
  }
}

What’s Next

Scoring

Per axis formulas using the SSSA fields.

Consensus

How findings, capabilities, and dependencies are compared across miners.

Probe Events

How probe evidence is derived from the nonce.

Protocol Reference

The synapse fields carrying the SSSA.

​What an SSSA Is

​Top Level

​skill

​analysis

​analysis.findings[i]

​analysis.dependencies[i]

​evidence

​evidence.trace_hashes

​evidence.sandbox_manifest

​evidence.probe_evidence

​evidence.llm_evidence (optional)

​policy

​policy.rules[i]

​signature

​Validator Side Checks

​Example: Minimal declarative SSSA

​What’s Next