Subnet 28: gm
gm is Bittensor Subnet 28. Its current Finney identity registers the subnet name as “gm” and now lists contact, website, and description metadata.
Readers should treat this page as a current identity record for the subnet metadata exposed on Finney. Subnet identity fields can change, so live identity data should be checked before relying on older metadata statements.
Current Status
The useful public fact about Subnet 28 is its registered identity state. Active subnet articles can usually cite a project repository or documentation that explains how miners produce work and how validators score it. Subnet 28’s current identity provides lightweight project metadata through its contact, URL, and description fields.
If the operator later updates the identity fields or publishes documentation, the subnet may need a more detailed article. Until then, claims about a specific task, reward mechanism, setup process, or validator behavior would need a direct source beyond the blank identity fields.
On-Chain Identity
Live SN28 data is available on TaoStats. Readers can reproduce the
subnet’s registered identity fields with the Bittensor CLI command documented in the
btcli reference:
btcli subnets get-identity --netuid 28 --network finney.
That Finney identity reports netuid 28, subnet name “gm”, contact hi@saygm.com, subnet URL
saygm.com, and description “say gm to AI.” The GitHub, Discord, and additional
fields are blank.
Relationship to Yuma Consensus
Subnet 28 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.
gm’s on-chain identity lists a project URL and contact information but no GitHub repository. No public source provides a source-verified description of how validators score miners on Subnet 28 beyond what the registered identity fields contain. 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 gm (SN28), 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, gm (SN28) is registered as the live production subnet at netuid 28. 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 28 Identifies the Subnet On-Chain
Bittensor assigns every subnet a unique numeric identifier called a netuid, and Subnet 28 is the subnet registered at netuid 28 (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 gm from every other subnet.
For a reader, this means “Subnet 28” and “netuid 28” refer to the same on-chain slot. A claim about gm 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.
Miner and Validator Roles
Subnet 28 operates under the standard Bittensor two-role structure. Miners supply the subnet’s capability and validators evaluate those contributions and set weights. Reward distribution follows Yuma Consensus.
Reader Boundary
Subnet 28 gm 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 registered at netuid 28 under the identity “gm” (Understanding Subnets, Glossary: Netuid).