Subnet 70: NexisGen
NexisGen is Bittensor Subnet 70. Its on-chain description is “The dataset engine of decentralized AI,” and the project site is nexisgen.ai. The subnet’s job is to produce the raw material that AI models learn from — in its current form, datasets of video clips with text captions — by paying miners to assemble that data and validators to confirm it is real and usable. The project website describes this as a commissions-house model for AI training data, while the NexisGen README source describes the subnet implementation that produces and verifies video-clip datasets.
What NexisGen Rewards
Good machine-learning models need large amounts of clean, well-labeled data, and gathering that data is the work NexisGen rewards. Miners collect source videos, cut them into clips, and attach text captions describing each one, packaging the result as a structured dataset. The reward goes to datasets that are genuine and correctly formed rather than to volume alone.
The network operates in production cycles, with each miner contributing a dataset for the current cycle. Because many miners are gathering data in parallel, the subnet also checks for overlap and duplication, so a miner earns for original, well-captioned clips rather than for copying content another miner has already submitted. That keeps the resulting dataset both large and clean.
Commissioned Dataset Context
NexisGen’s public site frames the product around commissioned data: a buyer defines the kind of dataset needed, decentralized producers create records for that specification, and appraisers certify whether the records are usable. That framing matters because it makes the subnet more than a generic media-scraping pipeline. The useful output is a verified dataset that can be handed to model builders with provenance, not simply a pile of clips.
The current public commission is focused on video data. The site describes a video dataset lot with grounded captions, source provenance, and record certification, while the repository describes miners producing video-clip datasets and validators checking those submissions before they become network weights. Read together, those sources explain why the article treats data quality, provenance, and validation as central parts of the subnet rather than secondary operational details.
Validation Context
NexisGen’s validation work is the bridge between raw collection and reward. Miners can gather clips and captions, but validators are responsible for deciding whether a submitted dataset is genuine, well-formed, distinct from other submissions, and useful enough to count. The README describes that validator path as including schema checks, anti-cheat checks, sampled media review, caption review, and overlap arbitration.
For readers comparing data subnets, this means NexisGen’s reward signal is tied to certified record quality instead of volume alone. A larger submission is not automatically better if records are duplicated, unverifiable, badly captioned, or outside the active commission. The validator role is therefore closer to data appraisal: it turns a miner’s submitted media records into a quality score that can be reflected through subnet weights.
Miner and Validator Roles
Miners are the data producers. In each production cycle, they build a package of video clips with captions and submit it, granting validators access to their data so it can be checked. A registered hotkey on netuid 70 is what ties a miner’s submissions back to them.
Validators are the verification layer. They retrieve each miner’s dataset, run format and anti-cheat checks, sample individual clips and frames to confirm the content is real and meets the required standards, review the captions, and resolve overlap between miners so the same material is not rewarded twice. From those results they score miners and set weights on the network, which is how reward flows through Yuma Consensus. At the article level the split is straightforward: miners build the datasets, while validators verify their quality and weight each miner accordingly.
Source and Live Data
The public project site is nexisgen.ai, and the codebase is maintained in the RendixNetwork/nexisgen repository. Live SN70 subnet data is available on TaoStats. The mechanism context in this article is tied to the project site and public README rather than to live identity fields alone.
Relationship to Yuma Consensus
Subnet 70 uses Yuma Consensus to convert the dataset-quality 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 NexisGen’s context, validators inspect submitted video-clip datasets, check captions and source provenance, resolve overlap between miners, and translate those quality assessments into weights for the subnet. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Reader Boundary
Subnet 70 NexisGen should not be read as generic Bittensor subnet documentation, a passive media-scraping pipeline, or a claim that larger datasets automatically earn more rewards. The public materials frame the product as commissioned, validated video-clip datasets with captions and provenance, where validators certify record quality and arbitrate overlap so the same media is not rewarded twice (NexisGen README source).
This also means the unit of value is the verified record set, not only the presence of clips. A miner can submit many records and still score poorly if validators find schema issues, duplication, or low-quality captions. Validator weight vectors then flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).
The production-cycle framing is another scope boundary. The article describes miners submitting a dataset package for the active cycle, and validators checking genuineness and overlap in that cycle, so “best miner” is defined against the current commission constraints and dataset lot rather than a timeless, fixed benchmark.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Subnet 70, 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 70 is registered as the live production subnet at netuid 70. 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 70 NexisGen should not be read as generic Bittensor subnet documentation, a stock-media library, or a guarantee that any dataset is licensed for a given use. It names one subnet’s training-data market — miners assemble captioned video-clip datasets and validators verify the data is genuine and well-formed before rewards — on netuid 70 (NexisGen repository, Understanding Subnets, Glossary: Netuid).
A miner’s reward reflects validator-verified authenticity and form of the submitted data, so the article describes a data-production pipeline rather than a licensing or fitness guarantee for any downstream model (NexisGen site — nexisgen.ai).