Subnet 74: Gittensor
Gittensor is Bittensor Subnet 74, a subnet focused on open-source software development. Its public site is gittensor.io, and its Finney identity names Gittensor as an autonomous software development subnet.
What Gittensor Rewards
The Gittensor README describes a subnet where miners earn rewards for meaningful pull requests that are merged into recognized open-source repositories. The important distinction is that Gittensor rewards accepted software work rather than raw activity, unmerged submissions, or standalone model outputs.
In Bittensor terms, Gittensor turns open-source contribution into a competitive subnet task. Miners contribute code, validators evaluate accepted contributions, and validator weights feed into Yuma Consensus.
Contribution Boundary Context
The Gittensor README source frames the subnet around real, merged pull requests to recognized open-source repositories. That boundary matters because the README identifies merged pull requests, not merely opened pull requests or unmerged patches, as the work that miners can be rewarded for.
The public Gittensor website describes the project as autonomous software development and as a workforce for open source. Read together with the README, that framing makes Gittensor a subnet for accepted project contributions rather than unmerged code output. The useful unit of work is accepted maintenance or feature work in repositories the subnet recognizes.
This also explains why repository recognition is part of the reward model. The README says merged pull requests are evaluated within whitelisted repositories and within each repository’s configured emission share. A contribution therefore has two contexts: the quality of the change itself and the repository allocation that determines the scoring pool in which it competes.
Evaluation Context
Gittensor’s README describes validators as checking GitHub account ownership, verifying merged pull requests, and scoring contributions based on code quality, repository allocation, and programming language factors. The same source describes reward structures for master repositories, emission shares, programming-language weights, and token weights used for semantic code evaluation.
For readers comparing Gittensor with other subnets, the important point is that validation is tied to accepted open-source work and repository context. It is not just a miner uptime task or a raw activity leaderboard. The source-backed scoring inputs connect a merged change to a repository, programming-language factors, and code-quality assessment before validator weights are set.
References: Gittensor README source, Gittensor website
Miner and Validator Roles
Miners are contributing developers. They work on repositories recognized by the subnet, and their merged pull requests are the work products that can be evaluated for rewards.
Validators run the evaluation side of the subnet. The README describes validation around GitHub account ownership, merged pull request verification, repository allocation, programming-language factors, and code-quality scoring.
On-Chain Identity
Live SN74 subnet data is available on TaoStats. The source-backed contribution and evaluation details in this article come from the public Gittensor website and README rather than from live identity fields.
Relationship to Yuma Consensus
Subnet 74 uses Yuma Consensus to convert the contribution-quality 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 Gittensor’s context, validators check GitHub account ownership, verify that pull requests have been merged into recognized open-source repositories, and score contributions based on code quality, repository allocation, programming-language factors, and semantic code evaluation. Weight vectors reflect each miner’s accepted contribution quality within the configured repository emission shares. 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 74, 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 74 is registered as the live production subnet at netuid 74. 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 74 Gittensor should not be read as generic Bittensor subnet documentation, proof that every open-source pull request earns rewards, or a guarantee of current repository scoring outcomes. It names one subnet’s open-source contribution incentive context on netuid 74 (Understanding Subnets, Glossary: Netuid).
Merged Pull Requests Are the Scored Work Product
The Gittensor README describes rewards for meaningful pull requests merged into recognized open-source repositories rather than for opened but unmerged patches (Gittensor README source).
Readers should treat merge status and repository recognition as part of the contribution context.
Repository Allocation Defines the Scoring Pool
The README says merged pull requests are evaluated within whitelisted repositories and within each repository’s configured emission share. A contribution therefore competes inside the pool defined by that repository allocation (Gittensor README source).
Validator Weights Still Flow Through Yuma Consensus
Validators verify merged contributions and submit weights that Yuma Consensus aggregates into emission shares each tempo (Yuma Consensus, Emission).