Subnet 72: StreetVision by NATIX
StreetVision by NATIX is Bittensor Subnet 72. Public StreetVision materials describe a street-imagery computer-vision subnet where miners submit detection models and validators score those models on roadwork and construction-site imagery.
What StreetVision Rewards
The StreetVision README frames the subnet around image classification and object detection. The initial task is detecting construction or roadwork features in street imagery, with miners returning prediction scores that indicate whether a presented image contains the target feature.
The incentive documentation describes miner ranking as accuracy-based. Validators assess miner models using a mix of tasks, including tasks with known outcomes, so the scoring signal is tied to model performance rather than only to participation.
This task is narrower than general computer vision. The subnet is focused on extracting useful street-level signals from road imagery. Reliable roadwork detection can support downstream uses such as map freshness, infrastructure monitoring, and driving-related perception, but the subnet-level work being scored is the model’s classification performance on the provided imagery.
Miner and Validator Roles
Miners build and publish image-classification models. Each model takes street imagery and predicts whether it contains the target feature. The incentive documentation describes miner ranking as accuracy-based, so miner competitiveness is tied to prediction quality rather than registration alone.
Validators test those models. They challenge miners with a balanced mix of real and synthetically generated images drawn from a range of sources, so a model has to generalize rather than memorize, and they score each miner on how accurately it classifies that mix. From those scores they set weights on the network, which is how reward flows through Yuma Consensus.
Evaluation Context
StreetVision’s evaluation context is task accuracy plus validator challenge composition. The incentive docs describe miner rank as based on accuracy across organic tasks and tasks with known outcomes, while the validator side measures prediction quality on mixed task scenarios. This keeps the incentive pointed at detection quality instead of only rewarding participation.
The README also notes that validators use real and synthetic media from diverse sources. That matters because a roadwork detector should generalize across lighting, location, camera angle, and scene variation. A model that works only on a narrow image source would be less useful than one that holds up across the broader challenge mix.
Model Submission Freshness
StreetVision’s README and incentive documentation also describe model submission freshness as part of the subnet design. The current participation requirement is that miners submit an image classification model to a publicly accessible Hugging Face repository. That gives validators a stable model artifact to challenge rather than treating each miner as an opaque service with no versioned model reference.
The same materials describe a dynamic reward idea for future regular submissions. In that plan, miners would be encouraged to submit improved models over time, with older submissions losing reward strength after a defined period. The incentive documentation marks those timing details as subject to change, so the important reader-facing point is the direction of the design: StreetVision wants miners to keep improving detection models instead of relying indefinitely on one early submission.
That freshness idea fits the task domain. Roadwork imagery can vary by geography, season, camera position, and the datasets validators add over time. A model that remains accurate across newer challenge mixes is more useful than one that only fits an older slice of examples. Public model submission and future freshness rules both support that goal by making miner candidates easier to evaluate and replace.
The public-repository requirement also keeps the evaluation artifact concrete. Validators can point their challenges at a named model submission instead of relying only on a miner’s live claim about what model is being served. That supports repeatable evaluation as the challenge mix changes.
For readers, this separates two concepts that can otherwise blur together. Accuracy on the current challenge mix decides ranking, while submission freshness describes how the subnet plans to keep the candidate model set from going stale. Both are tied to the same source-described purpose: improving construction-site and roadwork detection through repeated model evaluation.
References: StreetVision README, StreetVision incentive documentation
At the subnet level, StreetVision is therefore a repeated image-classification competition. Miners submit models, validators challenge them with road-imagery tasks, and ranking follows the accuracy of those models under the current evaluation set.
On-Chain Identity
Live SN72 subnet data is available on TaoStats. The source-backed street-imagery and scoring details in this article come from public StreetVision materials rather than from live identity fields.
Relationship to Yuma Consensus
Subnet 72 uses Yuma Consensus to convert the accuracy-based 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 StreetVision’s context, validators challenge each miner’s submitted image-classification model with a balanced mix of real and synthetically generated street-imagery tasks drawn from diverse sources. Scores reflect prediction accuracy across organic tasks and tasks with known outcomes, rewarding models that generalize rather than memorize. Validators submit weight vectors reflecting those per-model accuracy rankings. 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 Subnet 72, that sequence applies to the standard Bittensor lifecycle: localnet for isolated development, testnet for shared non-production testing, and mainnet for live operation with real emissions.
On mainnet, Subnet 72 is registered as the live production subnet at netuid 72. The Bittensor Networks reference separates mainnet, testnet, and localnet. Participation examples or emission outcomes from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 72 StreetVision by NATIX should not be read as generic Bittensor subnet documentation, a general computer-vision API, or a finished mapping or navigation product. It names one subnet’s street-imagery detection task — scoring miner models on roadwork and construction-site imagery — on netuid 72 (StreetVision repository, Understanding Subnets, Glossary: Netuid).
A miner’s rank reflects detection accuracy on the scored imagery set, so it should not be read as a guarantee of downstream map-freshness, infrastructure-monitoring, or driving-perception outcomes.