Everything the protocol produces is content-addressable: named by the SHA-256 of its canonical bytes. You can't mutate a verdict without mutating its id — and every id eventually rolls up into an onchain Merkle root.

Verdict storage

Each verdict lives at verdicts/window_<id>/<validator_hotkey>/<completion_id>.json, HMAC signed by the validator, with a canonical JSON envelope (sort_keys + fixed separators). A verifier reconstructs the canonical bytes, recomputes the signature, and rejects anything that doesn't match.

Checkpoint storage

Training checkpoints publish as delta bundles: per-tensor int8-quantized diffs + per-shard SHA-256 + a binary Merkle tree over the shard hashes. The root goes onchain; anyone can download the shards, re-verify individually, and reconstruct the target state bit-exactly.

Onchain commitment

Per-window Merkle roots are committed via commit_policy_metadata on the Bittensor chain. A deep reorg would rewrite history — mitigated by confirmation-count policies at the caller level.

Auditor flow

An external auditor's job is mechanical:

1. Read the onchain Merkle root for a window.
2. Download the verdict bundle from R2.
3. Recompute the Merkle tree + per-shard SHA.
4. Match. Or not. If not, the bundle is rejected and flagged.

No validator trust required. No miner trust required.