Subnet 120: Affine
Affine is Bittensor Subnet 120. The live Finney identity lists its subnet name as Affine, its GitHub repository as AffineFoundation/affine, its subnet URL as www.affine.io, and its description as “Reason Mining.” The GitHub identity URL currently resolves to the AffineFoundation/affine-cortex repository.
The Affine README describes the subnet as an incentivized reinforcement-learning environment for reasoning tasks such as program abduction and coding. Miners submit model revisions, and the system tests challengers against the current champion across evaluation environments.
What Affine Provides
Affine provides a competitive loop for improving reasoning models. The README describes a queue where each pending challenger faces the current champion across every evaluation environment in a back-to-back contest. A challenger only replaces the champion if it wins across all environments by the required per-environment margin.
At the article level, Affine turns incremental model improvement into a Bittensor task. The subnet uses public model commitments, validator-side orchestration, backend scoring, and on-chain weight-setting to direct rewards toward the current champion through Yuma Consensus.
Miner and Validator Roles
Miners commit a Hugging Face model and revision pair on chain. The miner guide says the validator hosts inference for miners when their queue slot comes up, and miners use public status commands to track model metadata, queue state, and scores.
Validators perform the on-chain weight-setting role. The validator guide says evaluation and scoring run in backend services, while the validator service fetches the latest normalized weights, applies the burn mechanism, and submits weights to Bittensor. This is the subnet-specific form of the broader Mining and Validating pattern in Bittensor.
Challenger Queue Context
The Affine README describes the subnet around a current champion and a queue of pending challengers. The validator-side scheduler walks that queue in first-block order, and each challenger faces the current champion across every evaluation environment in a single back-to-back contest.
That structure makes Affine different from a leaderboard that simply accumulates scores over time. A challenger has to win across all environments by the required per-environment margin before it can replace the champion. If it does not dethrone the champion, the queue advances to the next miner instead of keeping the failed challenger in place.
The README also says the environment task-id pool refreshes on a roughly daily cadence and the current champion is re-sampled before the queue continues. For readers, the important point is that Affine’s evaluation is framed as repeated champion defense rather than isolated one-off model tests. The live champion remains the model receiving winner-take-all weight until another challenger passes the full contest condition.
Reference: Affine README source
Commit and Validation Boundary
The miner guide describes miner participation as committing a Hugging Face model and revision on chain. The miner does not operate the validator’s backend services; the validator-side scheduler deploys the committed weights when the miner’s queue slot comes up.
The validator guide keeps another boundary clear: evaluation and scoring run in backend services, while the validator service reads the resulting normalized weights, applies the configured burn mechanism, and submits weights to Bittensor. This separates model improvement, challenge evaluation, and on-chain weight-setting into distinct parts of the subnet.
That division helps explain why Affine articles should treat public model commitments and validator weights as connected but not identical. The committed model revision is the miner’s candidate artifact; the backend contest determines whether it beats the champion; the validator-facing output is the normalized weight state that can be submitted on chain.
References: Affine miner guide source, Affine validator guide source
On-Chain Identity
Live SN120 data is available on TaoStats. Readers can also
reproduce the chain identity fields with the Bittensor CLI command documented in the
btcli reference:
btcli subnets get-identity --netuid 120 --network finney.
That Finney identity reports the subnet name as Affine, the subnet URL as www.affine.io, and the GitHub repo as AffineFoundation/affine.
Relationship to Yuma Consensus
Subnet 120 uses Yuma Consensus to convert the challenger-contest 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 Affine’s context, validators fetch the normalized weights produced by the backend contest evaluation, apply the burn mechanism, and submit those weight vectors to 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 Affine (SN120), that sequence changes how readers should interpret reasoning model competition examples and challenger-queue scoring outcomes.
In localnet, Affine-compatible miners and validators can be developed and tested in an isolated environment. Localnet challenger contest results and emission outcomes do not represent production subnet performance.
On testnet, Affine-compatible model commitment and challenger evaluation workflows can be exercised in a shared, non-production network. Testnet contest scores and validator weights are separate from mainnet subnet state.
On mainnet, Affine (SN120) is the live production subnet where miners commit reasoning model revisions and validators evaluate challengers against the current champion to determine real Bittensor emissions. The Affine repository describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A challenger contest result or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Netuid 120 Identifies the Subnet On-Chain
Bittensor assigns every subnet a unique numeric identifier called a netuid, and Subnet 120 is the subnet registered at netuid 120 (Glossary: Netuid). The Understanding Subnets reference explains that each subnet runs its own incentive mechanism while sharing the same underlying Subtensor chain, so the netuid is the stable handle that distinguishes Affine from every other subnet.
For a reader, this means “Subnet 120” and “netuid 120” refer to the same on-chain slot. A claim about Affine should be tied to that netuid rather than to the registered name alone, because the name field can be changed on-chain while the netuid stays fixed.
Reader Boundary
Subnet 120 Affine should not be read as generic Bittensor subnet documentation, mining-profitability advice, or a substitute for the subnet’s own primary sources. It names the on-chain subnet registered at netuid 120 under the identity “Affine” (Understanding Subnets, Glossary: Netuid).