Subnet 27: Team TBC
Team TBC is Bittensor Subnet 27.
What Team TBC Provides
Public technical documentation for Team TBC is not available through the on-chain identity alone. The description, GitHub repository, project URL, and Discord fields are all blank on Finney at the time of writing.
Miner and Validator Roles
Subnet 27 operates under the standard Bittensor two-role structure. Miners supply a capability to the network, and validators evaluate those contributions and set weights. Those weights feed into Yuma Consensus, which converts validator assessments into emissions that reward the strongest performers.
On-Chain Identity
The on-chain identity for netuid 27 lists the subnet name as Team TBC. All other identity fields — description, GitHub repository, project URL, and Discord — are blank. Live identity data is available on TaoStats.
Relationship to Yuma Consensus
Subnet 27 uses Yuma Consensus to convert validator weight vectors 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.
Team TBC’s on-chain identity lists only a subnet name; all other fields — description, GitHub repository, project URL, and Discord — are blank at the time of writing. No public source provides a source-verified description of how validators score miners on Subnet 27. The Emission documentation describes how 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 Team TBC (SN27), 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, Team TBC (SN27) is registered as the live production subnet at netuid 27. 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.
Netuid 27 Identifies the Subnet On-Chain
Bittensor assigns every subnet a unique numeric identifier called a netuid, and Subnet 27 is the subnet registered at netuid 27 (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 Subnet 27 from every other subnet.
For a reader, this means “Subnet 27” and “netuid 27” refer to the same on-chain slot. A claim about Subnet 27 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 27 should not be read as generic Bittensor subnet documentation, confirmation that the subnet has a published, working mechanism, or a substitute for the subnet’s own primary sources. It names the on-chain subnet slot registered at netuid 27; see this article’s On-Chain Identity section for its current registered fields (Understanding Subnets, Glossary: Netuid).