Subnet 126: Poker44
Poker44 is Bittensor Subnet 126, a subnet focused on a single problem: detecting bots in online poker through objective, reproducible evaluation. As the repository puts it, Poker44 is security infrastructure rather than a poker room — its product is bot-risk scoring that online poker operators can use to spot automated players. The incentive-mechanism code is maintained in the Poker44/Poker44-subnet repository.
What the Subnet Produces
The subnet’s output is bot-risk predictions over poker play. Validators send miners chunks of poker-behavior data — each chunk a batch of hand payloads — and miners return a risk score per chunk indicating how likely that play came from a bot. Because bot behavior keeps evolving, the task rewards predictions that generalize to new live-table behavior rather than ones tuned to a fixed sample.
A defining feature is that the evaluation data is centralized: it is produced by Poker44’s platform infrastructure and served to validators through a canonical evaluation API, so validators do not run their own poker tables. This keeps every miner graded against the same reproducible material.
Miner and Validator Roles
Miners build detection models and respond to detection requests, returning one risk score per chunk regardless of how many hands the chunk contains. A miner competes by producing scores that hold up on fresh, canonical batches over time rather than on a one-off test.
Validators pull canonical evaluation material from the central API, query miners with it, score the returned predictions, and publish weights on chain. According to the repository, the competition runs in rolling multi-hour epochs with the evaluation material refreshed on a fixed cadence, and a public leaderboard is derived from signed runtime state. Those validator scores become the weights that feed into Yuma Consensus, which aggregates validator scoring into consensus weights for miner incentives. The Emission reference describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Production Evaluation Boundary
The Poker44 README describes the current production model as centralized evaluation data produced by Poker44 platform infrastructure. Validators do not run their own poker tables in that production path. Instead, they consume canonical evaluation material from the central evaluation API, query miners, score the responses, and set weights on chain.
That boundary is important because Poker44 is not asking every validator to recreate the poker runtime locally. The platform infrastructure owns live benchmark tables, bots seated at those tables, persistence of hands and events, and publication of canonical chunks. The validator side is the consumer of that material and the Bittensor-facing scorer.
For readers, this keeps the evidence chain clear. Miner outputs are judged against centrally prepared evaluation batches, not against arbitrary validator-local poker sessions. The article’s claim that Poker44 is security infrastructure rather than a poker room follows from the same boundary: the subnet produces bot-risk evaluation, not a user-facing poker venue.
Reference: Poker44 README source
Chunk and Competition Context
The miner guide
describes the live miner contract as DetectionSynapse(chunks=...). Each chunk is a list of poker
hand payloads, may contain one or many hands, and requires one risk score from the miner. Miners do
not receive ground-truth labels in the live production path.
The validator guide describes the same production path from the validator side: validators fetch active canonical batch sets, convert them into detection chunks, query miners, score responses chunk by chunk, and update weights on chain. It also describes public competition surfaces as derived from signed validator and network state.
This explains why Poker44 scoring should be read as continuous chunk-level evaluation rather than a single static test file. The public benchmark can help miners iterate, but the production path uses canonical live batches and rolling competition windows. The stable task for miners is to return well-calibrated bot-risk scores for the chunks they receive.
References: Poker44 miner guide, Poker44 validator guide
On-Chain Identity
Live SN126 data, including metagraph state and alpha token pool information, is available on TaoStats. The source-backed detection-task and scoring details in this article come from the public Poker44 subnet repository and its miner and validator documentation rather than from live identity fields.
Relationship to Yuma Consensus
Subnet 126 uses Yuma Consensus to convert the bot-detection 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 Poker44’s context, validators pull canonical evaluation material from a central API, query miners with bot-behavior data chunks, score the returned risk predictions, and translate those scores into weight vectors for 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 Poker44 (SN126), 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, Poker44 (SN126) is registered as the live production subnet at netuid 126. 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 126 Identifies the Subnet On-Chain
Bittensor assigns every subnet a unique numeric identifier called a netuid, and Subnet 126 is the subnet registered at netuid 126 (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 Poker44 from every other subnet.
For a reader, this means “Subnet 126” and “netuid 126” refer to the same on-chain slot. A claim about Poker44 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 126 Poker44 should not be read as generic Bittensor subnet documentation, proof that any single result from the subnet is correct or guaranteed, or a substitute for the subnet’s own primary sources. It names the on-chain subnet registered at netuid 126 under the identity “Poker44” (Understanding Subnets, Glossary: Netuid).