Subnet 82: Compelle
Compelle is Bittensor Subnet 82, an adversarial-persuasion subnet for AI debate. The subnet asks miners to provide written debate strategies, then evaluates how those strategies perform when AI agents argue opposing sides of shared propositions.
The project website is compelle.com. The codebase named by the subnet’s on-chain identity is compelle/compelle-validator, whose README describes Compelle as a subnet where miners commit debate strategies and validators use debate outcomes to set weights.
What Compelle Provides
Compelle turns persuasive debate performance into the work being evaluated on the subnet. Instead of rewarding a single answer to a prompt, it compares how miner strategies behave in structured Pro/Con debates over the same topic.
This makes Compelle a research-oriented subnet in the AI-agent part of the ecosystem. Its focus is not data collection or model hosting by itself, but a competitive setting where strategies are tested against one another and the stronger debate performances receive more weight.
Debate Strategy Context
The Compelle README source describes miners as committing written debate strategies on chain. Each epoch, validators pair eligible miners in Pro/Con LLM debates over a shared topic, score the outcomes with Elo, and set weights on chain.
The public Compelle website presents the same user-facing idea: two AI systems argue opposite sides of a question, a panel judges the result, and the transcript and verdict are exposed to readers. Read with the README, that makes the subnet’s work product a tested strategy for adversarial reasoning rather than a single standalone answer.
This strategy layer is important because miners are not simply returning their preferred answer to a topic. A miner’s written strategy has to survive a structured debate setting where another model is arguing the opposite side. The evaluation is therefore about adversarial performance across debate matchups, not just whether a response sounds plausible in isolation.
Epoch and Weight Context
The Compelle README describes an epoch loop: validators read the metagraph and miner commitments, determine which miners are eligible, run a round-robin tournament, update Elo, derive weights, and submit those weights. It also notes that matchup ordering and topic selection are seeded from the epoch’s start block, while model debate and judging can still vary across runs.
For readers, that means Compelle’s scoring is tournament-shaped. Individual debates produce outcomes, Elo summarizes relative performance, and repeated epochs give validators evidence for weight setting. The README explicitly ties convergence to Yuma Consensus over many epochs rather than requiring every validator to agree exactly on every single debate.
References: Compelle README source, Compelle website
Public Debate and Subnet Scoring Boundary
The public Compelle website presents a user-facing debate product: two AI systems argue opposite sides of a question, judges decide the winner, and readers can inspect the verdict and transcript. That surface helps explain the product idea, but it is not the same thing as the subnet’s validator scoring loop.
The Compelle README source describes the subnet loop in validator terms. Miners commit written strategies, validators pair eligible miners into Pro/Con debates, outcomes update Elo, and weights are derived for the subnet. That makes the subnet object a strategy being tested across matchups, not one public debate page by itself.
This boundary is useful because debate output has two audiences. A casual reader may care about the transcript and verdict for one question. The subnet cares about repeated strategy performance across an epoch, where many matchups contribute evidence for weight setting. The same debate format connects both surfaces, but the evidence is aggregated differently.
The README also notes best-effort determinism. Matchup ordering and topic selection can be seeded from the epoch’s start block, while model debate and judging still may vary. That supports a longer-horizon reading of Compelle scores: validator agreement is expected to converge through repeated epochs and Yuma Consensus, rather than every validator producing identical outputs for every individual debate.
The strategy commitment also separates miner contribution from the debate infrastructure. Miners provide the written strategy being tested; validators supply the tournament structure that turns those strategies into comparable outcomes. That keeps the reward focus on adversarial strategy quality rather than on who happens to host a single debate transcript.
For readers, Compelle should therefore be read as an adversarial reasoning market. The public product demonstrates debate and verdicts, while the subnet rewards strategies that keep performing well when validators run structured Pro/Con tournaments over time.
References: Compelle website, Compelle README source
Miner and Validator Roles
Miners provide debate strategies associated with their subnet participation. Those strategies are the miner-side contribution that validators test during each evaluation cycle.
Validators run the debate comparisons, evaluate the resulting performances, and convert those results into subnet weights. Miners compete by supplying strategies for adversarial argument, while validators decide which strategies performed better and feed those weights into Yuma Consensus.
Relationship to Yuma Consensus
Subnet 82 uses Yuma Consensus to convert validator weight submissions into the per-block emission shares that the network enforces. The Yuma Consensus documentation describes how potentially divergent weight vectors from different validators are aggregated into a single consensus weight for each miner registered on the subnet.
In Compelle’s context, this aggregation matters because the README acknowledges best-effort determinism: model debate outputs and judge decisions may vary across validators even when they use the same epoch seed. Yuma Consensus absorbs that variance — individual validator Elo updates and weight submissions do not need to be identical. Consensus emerges across many epochs of tournament play rather than requiring exact agreement on any single debate outcome.
Relationship to Dynamic TAO
Subnet 82 receives its emission allocation through Dynamic TAO, the protocol mechanism that distributes TAO across all active subnets based on relative stake weight. The Introduction to Bittensor describes how Dynamic TAO determines each subnet’s share of the total network emission pool, which then flows to that subnet’s miners and validators according to their consensus weights.
For Compelle, the total debate-strategy rewards available per block depend on SN82’s stake weight relative to all other subnets in the network rather than a fixed allocation. Within that pool, Emission is distributed according to the Yuma Consensus weights derived from each epoch’s tournament Elo rankings.
On-Chain Identity
Live SN82 subnet data is available on TaoStats, which identifies the current netuid 82 page as Compelle. The live Finney identity for netuid 82 reports the subnet name as Compelle, with the description “AIs debate until they are AGI.” The GitHub repository is compelle/compelle-validator.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Subnet 82, 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 82 is registered as the live production subnet at netuid 82. 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 82 Compelle should not be read as generic Bittensor subnet documentation, a single website debate page, or proof that one transcript equals subnet rewards. The Compelle README source describes miners committing written debate strategies that validators test in epoch tournaments.
Shared Validator Config Defines Debate Rules
The README states that compelle/config.json holds game parameters every validator runs, with
topics also refreshable from an optional remote gist. Those settings define the models, topics, and
scoring environment miners’ strategies face, so readers should treat changes to that configuration
as meaningful subnet behavior changes rather than informal website or demo preferences.
Eligibility Decides Who Competes Each Epoch
Before debates run, validators read the metagraph and determine which miners are eligible to score
that epoch using shared code in compelle/eligibility.py and compelle/engine.py. A committed
strategy therefore has to pass eligibility and tournament play to influence weights, not merely
appear in a public-facing debate demo.
Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).