Subnet 44: Score
Score is Bittensor Subnet 44, a decentralized intelligence layer for live video and imagery, built on a codebase called TurboVision. Its goal is to take raw footage and turn it into structured, decision-ready data in real time, with early deployments focused on professional sports. Miners contribute the computer-vision models that do the analysis, validators benchmark those models on live data, and the best models earn emissions. The incentive-mechanism code is maintained in the score-technologies/turbovision repository.
What the Subnet Produces
The subnet’s output is structured information extracted from video and images — the kind of data a downstream product needs rather than raw frames. Work is organized around a manifest of tasks the network calls Elements: each Element is a specific analysis job, and miners submit models that solve it. Framing the work as discrete Elements lets the network add new video-understanding tasks over time without changing how miners and validators interact.
Because the useful product is an accurate model rather than a one-off answer, the subnet is a continuous competition: miners publish models and are rewarded for how well those models perform against fresh data, which keeps pressure on them to improve.
Visual Intelligence Context
The Score website presents the project around making cameras intelligent and building models that turn raw video into structured visual intelligence. The TurboVision repository gives the subnet-level version of that idea: raw footage becomes structured, decision-ready data in real time, with early deployments focused on professional sports.
This context supports reading Score as visual-perception infrastructure. The subnet’s output is structured data extracted from footage, not the footage itself. That distinction matters because the subnet is rewarding models that make visual streams usable by other systems.
For readers comparing subnets, Score sits closer to an applied perception network than to a text or agent benchmark. Miners compete on models that make camera feeds machine-readable. Validators turn those model outputs into a scoring signal, so the network can reward improvements in visual understanding instead of rewarding simple service availability.
Element Evaluation Context
TurboVision’s repository organizes work around Elements, which are discrete model tasks in the active manifest. That structure is important because “video understanding” is too broad to evaluate as a single undifferentiated capability. One Element can represent one kind of analysis job, while a different Element can carry a different cadence, window, and weight in the validator process.
The repository describes validators as aggregating recent scores per Element and then selecting winners before setting weights. At the article level, this means miner performance is judged within the task family the model is trying to solve. A miner can be strong on one Element without that automatically proving broad visual intelligence across every possible camera task.
That Element structure also explains how Score can add new model tasks without changing the basic article-level split between miners and validators. Miners publish models for Elements, validators score those models against the active task definitions, and the resulting weights reward the strongest model performance for each evaluated task.
Miner and Validator Roles
Miners contribute models that solve the Elements defined in the manifest, publishing them so validators can run them. Validators keep the network honest by scoring those models on live data: according to the repository, a validator fetches a challenge for an Element on a fixed block cadence, builds the ground truth to grade against (real or pseudo), runs the eligible miners’ models from the on-chain registry, and scores their outputs.
Selection is competitive per Element. The validator aggregates recent scores for each Element over a window, picks the winners, and submits the corresponding weights on chain. Those weights feed into Yuma Consensus, which converts them into the incentive split across miners and validators. The effect is that a miner is paid for a model that measurably outperforms its peers on the task, not for simply being registered.
Relationship to Yuma Consensus
Subnet 44 uses Yuma Consensus to convert the Element-performance weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The linked documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Score’s context, validators fetch Element challenges on a fixed block cadence, run eligible miners’ models from the on-chain registry against live data, aggregate recent scores per Element, and translate the winner selections 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.
On-Chain Identity
Live SN44 data, including metagraph state and alpha token pool information, is available on
TaoStats. Readers can reproduce the subnet’s registered identity
fields with the Bittensor CLI command documented in the
btcli reference:
btcli subnets get-identity --netuid 44 --network finney.
The Finney subnet identity for netuid 44 points to the score-technologies/turbovision repository, which is the source of truth for the Element model and scoring process described above.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Score (SN44), that sequence changes how readers should interpret live video analysis examples and computer-vision scoring outcomes.
In localnet, Score-compatible miners and validators can be developed and tested in an isolated environment. Localnet video analysis results and emission outcomes do not represent production subnet performance.
On testnet, Score-compatible model submission and benchmark evaluation workflows can be exercised in a shared, non-production network. Testnet evaluation scores and validator weights are separate from mainnet subnet state.
On mainnet, Score (SN44) is the live production subnet where miners contribute computer-vision models for structured video analysis and validators benchmark them on live data to determine real Bittensor emissions. The TurboVision repository is the registered project repository for SN44 on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A video analysis result or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 44 Score should not be read as generic Bittensor subnet documentation, a video hosting service, or proof that registering a model equals top emissions. It names one subnet’s structured visual-intelligence model competition on netuid 44 (Understanding Subnets, Glossary: Netuid).
Elements Split Video Tasks Into Discrete Jobs
The TurboVision repository organizes work around Elements, discrete model tasks in the active manifest rather than one undifferentiated video benchmark (TurboVision repository).
Miner performance is therefore judged within the Element family each model targets.
Validators Fetch Challenges on a Fixed Cadence
The repository describes validators fetching an Element challenge on a fixed block cadence, building ground truth, and scoring eligible miner models from the on-chain registry (TurboVision repository).
Weights reward measured model performance on those live evaluation runs.
Validator Weights Still Flow Through Yuma Consensus
Subnet 44 uses Yuma Consensus to convert validator weight submissions into emission shares each tempo (Yuma Consensus, Emission).