skip to content

docs

Proof protocol (sketch verifier)

The sketch receipt that every miner attaches to a completion, and how validators reverify in milliseconds.

FIGthe sketch verifier — submit a proof, the validator re-executes
the sketch verifier — submit a proof, the validator re-executesMINERcompact sketch proofVALIDATORre-executes in msACCEPTREJECTthe proof costs ms to check, not a full re-run

Every completion is bound to a receipt with three parts:

  1. The sketch — a hidden-state fingerprint at one fixed layer of the model, taken at 32 randomly-sampled token positions.
  2. The randomness — per-window PRF output the miner cannot predict when computing the answer. This makes pre-committing to a sketch infeasible.
  3. The signature — HMAC-bound to the miner hotkey, so nobody else can claim authorship of the receipt.

Verification

Validators re-run the model at only the sampled positions. The diff between their sketch and the miner's must fall inside a fixed tolerance envelope. Cross-GPU determinism was empirically shown across 4 hosts (3× Blackwell + 1× H100), 90 samples, bit-identical digests.

Why a sketch, not a full recompute

A single-layer forward pass at 32 positions runs in milliseconds. A full recompute runs in seconds. For a subnet processing thousands of completions per window, the math does not work with full recompute.

Tolerance envelope

The ceiling PROOF_SKETCH_TOLERANCE_BASE = 1000 (units of sketch integer space — tightened from the original 6000 design budget after cross-GPU calibration measured near-zero honest drift) protects honest miners against cross-hardware numerical drift. Empirically it is unused by the honest path under tested configs — the real defense against tampering comes from the combined nine-stage pipeline, not from the sketch envelope alone.