Subnet 96: Verathos
Verathos is Bittensor Subnet 96. Public Verathos materials describe it as a verified AI compute network where miners return AI outputs with cryptographic proof material that validators can check without rerunning the full model.
What Verathos Provides
The Verathos overview frames the subnet around cryptographically verified AI compute. Instead of asking validators to trust that a miner ran the claimed model, Verathos makes the returned work carry proof evidence tied to the model weights and computation being checked.
The proof system is designed to make verification cheaper than reproduction. A validator should not need the miner’s GPU or a full rerun of the model to reject dishonest work. The overview describes sumcheck-style proofs over Merkle-committed weights, with validators checking proofs on ordinary processors before weights are assigned.
Verathos also distinguishes current and future work. The source describes verified inference as the live focus, while verified training is still described as in testing or development. That boundary matters because the same verification idea can apply to both serving and training, but the active subnet behavior is more precise as verified inference with verified training as a stated extension.
Proof Context
The inference verification protocol describes a probabilistic verification system for large-language-model inference. A miner returns an output together with commitments and proof data; the validator checks the proof against on-chain weight commitments and a request-specific challenge. The point is not to hide the model, but to make dishonest substitutions or partial computation detectable.
The proof guarantees cover several separate questions. Weight checks address whether the claimed model weights match committed roots. Computation checks address whether challenged tensor operations were carried out correctly. Output binding addresses whether the final response was altered after proof generation. Probabilistic coverage addresses the fact that only sampled layers are challenged on a given request, with detection confidence increasing across repeated checks.
This gives Verathos a different shape from a normal inference marketplace. Miner quality is not only about speed or model usefulness; it also depends on whether the returned work can survive proof verification. A proof failure is therefore a direct signal that the miner’s work should not be trusted for subnet scoring.
Detection and Probation Context
The inference protocol describes Verathos as a cryptoeconomic verification system rather than a claim that every tensor operation is rechecked on every request. A validator samples proof targets, and the miner has to make the sampled computation agree with committed model weights, activations, prompt binding, sampler settings, and output commitments. The per-request check is probabilistic, but repeated checks raise the chance of detecting dishonest serving.
The same source presents sampling as an efficiency tradeoff, not as a weaker trust model. Validators can verify selected proof targets on ordinary CPUs instead of rerunning the whole model on a GPU. That keeps validator work lightweight while still making repeated dishonest serving increasingly hard to hide.
That matters for how the subnet discourages cheaper-than-honest behavior. The protocol’s threat model focuses on miners that try to save compute while still collecting emissions. If a miner serves the wrong model, skips layers, substitutes prompts, changes sampling parameters, or fabricates intermediate work, the sampled proof path is designed to expose that mismatch. Detection then affects rewards instead of remaining a purely diagnostic event.
The same source describes probation as the economic response to proof failure. A detected failure can remove reward eligibility until the miner demonstrates clean behavior again. This makes the verification loop part of subnet scoring: proofs are not only technical receipts attached to responses, but evidence validators can use when deciding whether a miner should continue receiving weight.
The protocol also explains why request binding is important. Validators provide a nonce, and the challenge is derived from that nonce and the miner’s output commitment, so a miner cannot pick the layers that will be checked before finishing the inference. This keeps the proof sample tied to the specific request and response rather than to a reusable certificate created in advance.
References: Verathos overview, Verathos inference protocol
Miner and Validator Roles
Miners provide AI compute and attach proof evidence to returned results. Validators check those proofs, combine proof validity with performance signals, and set subnet weights from the verified work. The important role split is that miners perform the expensive computation, while validators perform cheaper verification and scoring before rewards flow through the subnet.
On-Chain Identity
Live SN96 data is available on TaoStats. The source-backed verification and subnet-role details in this article come from the public Verathos repository and documentation rather than from live identity fields.
Relationship to Yuma Consensus
Subnet 96 uses Yuma Consensus to convert the proof-verified inference weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The Yuma Consensus documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Verathos’s context, validators check cryptographic proofs attached to miner-returned AI inference results, combining proof validity with performance signals into weight vectors for the subnet. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Verathos (SN96), that sequence changes how readers should interpret cryptographically verified AI inference examples and proof-based scoring outcomes.
In localnet, Verathos-compatible miners and validators can be developed and tested in an isolated environment. Localnet inference verification results and emission outcomes do not represent production subnet performance.
On testnet, Verathos-compatible verified inference workflows can be exercised in a shared, non-production network. Testnet proof-verification results and validator weights are separate from mainnet subnet state.
On mainnet, Verathos (SN96) is the live production subnet where miners provide AI compute with cryptographic proof evidence and validators verify those proofs to determine real Bittensor emissions. The Verathos repository describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A verified inference result or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 96 Verathos should not be read as generic Bittensor subnet documentation, a guarantee that every model layer is rechecked on every request, or proof that verified training is already the live subnet product. The Verathos overview describes verified inference as the current focus, with verified training still described as in testing or development.
Verification Samples Requests Rather Than Replaying Full Models
The inference verification protocol describes probabilistic proof checks derived from each request’s nonce and output commitment. Validators can reject dishonest serving without rerunning the full model, but a single passing proof does not by itself prove every future response will be honest without continued checks.
Proof Failure Can Trigger Probation, Not Just Lower Quality Scores
The same protocol ties detected proof failures to probation economics where reward eligibility can be removed until a miner demonstrates clean behavior again. Proof validity is therefore a gateway to subnet scoring, not a cosmetic audit log separate from emissions.
Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).