CookingTAO (SN122)’s Whitepaper Details Its TAO Mining Marketplace and Incentive Model

CookingTAO (SN122) a 15-pager whitepaper laying out the full incentive mechanism behind its Bittensor mining marketplace. The subnet connects two groups: developers or AI agents who submit mining code, and users who deploy that code without needing to handle the technical setup themselves.

Developers only earn when the users running their code actually generate measurable performance on other Bittensor subnets, which turns code quality into the primary driver of rewards.

The paper covers the scoring model, the profitability scaling, the anti-monopoly cap, and the private-code protections that keep submissions from being copied inside the marketplace.

The Problem CookingTAO Is Solving

Bittensor rewards useful intelligence through subnet-specific incentive mechanisms, but participating in most subnets requires deep technical knowledge, infrastructure setup, wallet management, and continuous operations.

That gap keeps most AI builders out of the network even though they already build models, datasets, and agents on platforms like GitHub, Hugging Face, Kaggle, workplaces, and university labs.

Where the current friction sits:

1. Wallet setup and crypto risk,

2. Infrastructure and dependency management,

3. Miner configuration and continuous operations, and

4. Uncertain rewards for the effort invested.

CookingTAO closes the gap by acting as a marketplace where developers submit mining code and users deploy it through managed infrastructure.

How The Marketplace Works

The subnet separates participants into three distinct roles:

1. Developers: Humans or AI agents who submit verified mining code. They earn CookingTAO rewards based on how well the users running their code perform.

2. Users: Anyone deploying submitted mining code through CookingTAO. Users keep all the earnings from running miners. They do not receive CookingTAO subnet rewards directly.

3. Validators: Submit weights on-chain based on measured user performance, following the subnet’s predefined scoring rules.

The core incentive loop:

1. Better mining code produces better user performance

2. Better user performance produces higher CookingTAO weight

3. Higher weight produces more developer rewards

4. More rewards attract more quality developers

Owner UID emissions fund external competitions, hackathons, grants, and ecosystem programs meant to bring more builders and users into Bittensor.

Unused portions of the miner allocation are treated as burned rather than distributed beyond the mechanism’s rules.

The Scoring And Anti-Gaming Mechanics

CookingTAO scores developers based on the real-world performance of every user running their code, with adoption as a secondary factor to prevent fake-usage attacks.

How the scoring works:

1. Performance is 90% of the score. Measured by the rank users achieve and the incentives they earn on the original subnets they mine.

2. Adoption is 10% of the score. Rewards code that gets used, but weighted low enough that fake adoption cannot dominate.

3. Miner-level scores aggregate across all deployments. A developer’s total score is the sum of every user-code pair generated by their submissions.

The anti-monopoly cap:

1. No single developer can earn more than the CAP. Currently set at 30% of the available miner reward pool.

2. Excess weight redistributes proportionally. Uncapped developers absorb what capped developers cannot take, until either the pool is exhausted or all developers hit the cap.

3. Leftover allocation gets burned through the Owner UID. If too few eligible developers exist to absorb the full pool without breaking the cap, the remainder is not redistributed beyond the limit.

Profitability scaling ensures the platform never pays out more than it earns. If platform earnings drop below the projected value of the maximum miner allocation, the pool scales down proportionally rather than paying rewards the marketplace cannot sustain.

The Private-Code Protection Model

Submitted code is not exposed as a public marketplace asset. CookingTAO does not list, download, or expose code to competing developers, which protects submitters from having their strategies copied inside the marketplace.

How the protection works:

1. Runtime code fetching from authorized sources. Code is not stored as an unrestricted platform artifact.

2. Deployment-based access only. Users can run submitted code but cannot see the codebase or the runtime environment.

3. No direct shell or filesystem access for users. Deployment logs are exposed instead of raw code.

4. Ownership and version tracking. Every submission is tied to a verified submitter with timestamps and access logging.

If two submitters independently develop similar strategies, reward attribution stays based on the verified submitter, the tracked version, and the actual user performance observed on the original subnet. Cloning inside the marketplace becomes structurally difficult.

Why This Fits Where Bittensor Is Heading

CookingTAO is positioned as a bridge between the AI builder market and Bittensor mining, which has historically been gated by technical complexity. The whitepaper’s mechanism is designed to be Bittensor-native, economically sustainable, and resistant to fake adoption, monopoly capture, code cloning, low-quality deployments, and validator collusion.

For developers, this creates a new monetization path where high-performing mining code earns based on real deployment success. For users, it lowers the barrier to Bittensor mining by abstracting the infrastructure work. For validators, the scoring framework is deterministic and rule-based, which reduces the surface area for discretionary manipulation.

➛ Explore CookingTAO Incentive Mechanism’s Docs Here 

➛ Join the waitlist here.