Trust Model & Verifiability

There is one validator and the owner runs it. That is a decision, not an accident (D1): a mechanism that runs a miner's 70 GB model against real benchmarks for real money does not have a second party willing to pay to re-derive it. What replaces multi-validator consensus is a record in which every input was committed before it could be chosen and every output is signed — so a third party cannot re-run a window, but can check that the window ran the way it said it would.

What is committed before anyone enters

what	where	what it closes
the whole schedule's root — one chained manifest covering every window's draw, stratification and parameters	the owner's commitment slot on chain, written once	the owner choosing a slice after seeing who committed
each window's nonce — a chain beacon at the block the window opens	derived, not written	whoever picks the nonce picks the slice; nobody picks it
the miner's tree — a signed manifest naming every file's size and SHA-256, and the manifest's own digest in the ready signal	the miner's commitment slot on chain, once per hotkey	serving one tree and having committed to another
the catalog snapshot	the window record	king and challenger seeing different prices or models

The validator refuses to start unless the root it computes from its own configuration equals the one on chain, and refuses a window whose entry's index does not match the window being scored — the manifest chains N entries and all are equally authentic, so membership alone would let window 23's slice be scored inside window 7.

What is verified at admission

Before the king's arm is touched and before a cent is spent on a challenger:

the manifest's digest equals the one in the on-chain ready signal, it is signed by the signalling hotkey, and it names that hotkey's registration;
every object under the miner's prefix appears in the manifest and vice versa — an unlisted extra is refused, not ignored;
every file is hashed as it lands and refused at the first mismatch;
config.json is compared field by field to the pinned reference, the tokenizer by digest, every tensor's name, shape and dtype against the inventory; pickle archives, bundled *.py, auto_map and trust_remote_code are refused;
the serving stack is asked to load it under the name v3-<hotkey>@<manifest digest>, and the validator refuses to talk to an endpoint that reports any other name.

Every one of those is a refusal at the call site: the shot is spent, the king is not charged.

What is verified during a window

The worker request is a pure function of the task and the observations. The scaffold builds it; the audit republishes it; anyone can recompute it and assert byte-equality. This is the property that makes public benchmarks safe: nothing the model writes reaches the answer path.
Every call is metered against a signed receipt and every arm is reconciled: metered spend must equal recorded spend, or the arm is unscoreable and says so. Exhaustion, futile calls and unfunded calls are counted per arm and published.
A restart resumes from checkpoint at zero new calls, and the reveal records how many tasks were resumed.

What is published

The reveal — window, nonce, slice size, the power gate's numbers, the king's arm, every challenger's status and four-condition verdict, the metering reconciliation, the weights as set, the metagraph as resolved, and the full decision traces of the arms the owner paid for — is signed by the owner's hotkey and published at v3/reveal/<window>.json, a path that is a pure function of the window number. Authenticity comes from the signature, never from where the bytes were found. Persisting the verdicts happens before setting weights and before publishing, so a crash between the steps re-does only the cheap half and never re-judges a shot.

What is not verifiable by a third party, stated plainly

that the validator actually ran the model it admitted, rather than a different one — the traces make a substitution visible in kind but do not prove it in bytes;
that the worker outputs are what the providers returned — receipts are the gateway's, and the gateway is the owner's;
worker-side nondeterminism: third-party endpoints do not decode deterministically at temperature 0 (measured: six identical calls, six distinct answers), so a re-run would not reproduce a score bit for bit even with the owner's cooperation. The mechanism absorbs this by measuring the king once per slice and by ε; it does not eliminate it.

The intended remedy for the first two is the confidential-serving design — the owner's own image, measured and attested, serving the conductor and metering the calls where the owner cannot intervene. See Confidential Serving. Until it is deployed, the trust in the validator is a stated dependency, not a hidden one.

The attestation stack that survives from v2

The first-generation mechanism proved the hardware end of this on real machines: genuine Intel TDX quotes, the complete DCAP verification chain (pinned Intel root, TCB status, CRL, QE identity), image identity over MRTD + RTMR0/1/2, runtime measurement into RTMR3, a reproducible measured image (byte-identical UKI → the same RTMR1, dm-verity-locked rootfs), and on-chain approved-measurement governance. What is kept in the tree is the quote and verification code (koth/tdx.py, koth/collateral.py), the measurement-governance record (serve/governance.py) and the v3 image recipe (scripts/build_router_image.sh), which is what confidential serving builds on. The runtime-measurement and confinement modules and the v2 image recipes were removed with the mechanism that used them on 2026-09-07; they are proven designs to be rebuilt from the record, not code that exists today.