Gittensor SN74 shifts inference rewards toward verified output tokens

Gittensor SN74 has changed the code behind its inference-serving rewards so verified output tokens, rather than admitted hardware capacity alone, determine what a miner earns from that path.

The September 1 commits separate admission from payment. Hardware attestation asks whether a qualifying RTX 5090 is running the expected model. Once admitted, a miner accumulates reward credit from output tokens observed by the serving gateway.

The code describes the intended principle plainly. An idle card earns nothing. A card serving more verified output tokens receives more credit, subject to the serving pool cap and the project’s pricing logic.

This is an implementation change in Gittensor’s repository. Tao Outsider has not independently run the serving stack, verified production traffic or reproduced its accounting.

Hardware becomes the gate, tokens become the meter

Gittensor previously described serving compensation in card-equivalent GPU hours. The new path derives a per-token rate from a target card-hour price and the aggregate decode throughput expected from one approved runtime.

The validator records tokens served during audit rounds. Those token totals are converted into card-equivalent hours for settlement and then priced through the serving allocation function. A trailing window covers 12 five-minute audit rounds.

Hardware attestation still matters, but it changes roles. It is an admission check for the expected GPU and loaded model. The reward basis is the volume served after admission.

That distinction closes one obvious mismatch between hardware presence and useful service. Owning or presenting a qualified card does not by itself demonstrate that the card answered requests. Paying from observed output moves the meter closer to delivered work.

The proxy remains imperfect. Output-token volume does not prove answer quality, user value, unique demand or revenue. It also depends on the gateway, tokenizer, pricing inputs and anti-gaming controls working as designed.

The commit raises the serving-emission cap from 3.5% to 10% while reducing the open-source software pool from 96.5% to 90%, keeping the two configured pools at 100%.

That cap is a ceiling, not a promised payout. Gittensor’s comments say unused serving share recycles rather than flowing to admitted miners simply because capacity exists. When pricing data is unavailable on mainnet, the intended fallback is zero payment instead of automatically distributing the full cap.

The code also separates routing weight from pay. Speed and latency checks influence how much traffic a ready miner receives. Tokens served through that traffic form the settlement input.

These details make the design more legible. They do not establish that the API is open at scale, that outside users are sending traffic or that the full serving loop has been independently tested in production.

The 303,714-download signal

Gittensor reported 262,813 downloads in 17 days on August 31 and said an API was due during the following week. At 13:27 UTC on September 1, the Hugging Face API returned 303714 downloads and 136 likes for gittensor-model-hub/Qwen3.8-27B-NVFP4-RTX5090. The model record showed a last modification time shortly before noon UTC on September 1.

That count is a distribution signal. Hugging Face downloads are not unique users. They are not API calls, generated tokens, customers, revenue or proof of subnet adoption. Automated pulls and repeated downloads can contribute to the total.

The project’s claim that this is the most-downloaded Bittensor model has not been independently checked against every Bittensor-linked repository. The defensible observation is narrower. The public API reported 303,714 downloads for this specific model at the stated timestamp.

Current subnet context

The September 1 TaoSwap snapshot showed 11 active miners on Gittensor SN74 and an emission_value of 0.000005086.

That snapshot confirms current subnet context only. It does not tell us how many miners are serving the model, how much traffic the gateway receives, whether the serving accounting is active across validators or whether any user paid for inference.

Gittensor is attempting to tie one reward path to delivered output instead of idle hardware. The repository now contains that direction in code. Production evidence would require a live API surface, observable token accounting and independent tests showing that admission, routing and settlement agree under real load.