RedTeam — subnet 61

RedTeam pays for offensive security code, and its own pinned source shows one part of its scoring formula still described in a docstring that the running code no longer implements.

What it does

RedTeam runs a series of cybersecurity challenges as a competitive-programming contest. Miners submit code — bot-detection evaders, automation detectors, device fingerprinters, and similar tools — and are rewarded based on the quality and originality of their solutions; the subnet reports that these solutions can be, and are, integrated into real security products. [source]

The scoring is meant to reward continual improvement rather than a single good submission: every time a miner submits a solution, it's judged both on how well it performs and on how much genuinely new value it adds over what already exists on the subnet. [source] [source]

How the incentive mechanism works

Individual challenges are scored mechanically. In the Bot Virus challenge, for instance, a miner submits a containerised browser bot; the challenge's own runner builds and executes it in isolation and scores it against the runner's own evaluation of the built image, not against anything the miner self-reports. [source] [source] Other challenges, like AB Sniffer, combine multiple weighted components — for example 90% framework classification accuracy and 10% headless-browser classification accuracy — into one per-submission score. [source]

A decay mechanism sits on top of every individual challenge score: a submission only keeps earning for a limited period, and a miner has to keep updating it to hold its place, while a duplicate-detection system separately identifies and penalises copies. [source]

Turning all of that into on-chain weights is the job of get_onchain_scores in src/redteam_core/validator/miner_manager.py. Its own docstring says the result should combine two components — challenge performance at 50% and an "alpha burn" score at 50% — but in the pinned commit, the entire alpha-burn calculation is commented out: final_scores = challenge_scores is the only line that actually runs. What the validator sets on chain today is 100% challenge performance; the 50/50 split the code's own comments describe is not what executes. [source] [source] [source] [source]

Before those scores reach the chain, exclude_same_miner groups every submission by shared IP address, Docker username, or overlapping coldkey, and keeps only the single best-scoring submission in each group — a direct check against one miner operator running multiple registrations to multiply their own reward. [source] [source]

What miners are actually optimising

Because scores decay and duplicates are penalised, a miner that wants to stay paid has to keep shipping visibly different, incrementally better solutions on an ongoing schedule — the mechanism rewards a steady stream of updates over a single strong submission left untouched. [source]

The dead "alpha burn" code is also informative about what miners are *not* being asked to optimise, at least right now: whatever that component was meant to reward — the code names it "burn amount," and older release notes describe removing it as deliberate — is not part of today's payout at all. [source] [source]

Unverified the exclude_same_miner grouping catches submissions that share an IP, a Docker username, or an overlapping coldkey. Whether it catches an operator who deliberately avoids all three — different cloud regions, different container registries, unrelated wallets — is not something this course's evidence can confirm; the check only describes what it does catch.

Why it earns

Mechanism evidence

Every subnet's cross-network emission share is set by one chain-wide formula: a subnet's own moving-average alpha price, adjusted for how much of the last period's miner incentive was redirected back to the subnet owner, divided by that same figure summed across every subnet on the network. [source] [source] The quality of RedTeam's own scoring code has no direct entry in that formula, so what earns is not evidence the mechanism is good — it can only be evidence about what the mechanism verifiably does, and how well that survives contact with its own source.

By that standard, RedTeam's own source shows a real, working anti-multi-accounting filter, an isolated execution runner that scores a built container rather than a self-report, and a genuine gap between a docstring's claimed formula and the formula the pinned code actually runs. All three are checkable facts about the code, independent of whatever RedTeam currently earns. [source] [source]

Stake evidence

RedTeam carries 2325 @ 8871732 token holders at holder rank 45 @ 8871732, against an emission rank of 6 @ 8871732 — a wide enough gap between the two that a reader might expect a rank disagreement flag, but the snapshot does not raise one for RedTeam: false @ 8871732. RedTeam sits among the highest-earning subnets this course tracks, with 81.6% @ 8871732 of network emission captured by subnets at or above its rank. Separately, 14.2% @ 8871732 of its own judging power comes from root network stake rather than stake placed directly in RedTeam's own alpha — a root proportion figure that says who decides within this subnet, separate from anything about price.

Price evidence

RedTeam alpha traded at 0.007729002 @ 8871732 TAO at the snapshot block: down -5.60788433482092 @ 8871732 percent over the trailing week but up 39.8228055296658 @ 8871732 percent over the trailing month, against a market capitalisation of 39197438526562 @ 8871732 rao and 5304868453404 @ 8871732 rao of trading volume in the prior day. Its emission share of 3.2% @ 8871732 tracks a slow moving average of that price rather than the latest tick, so the strong monthly gain feeds into emission share gradually rather than all at once. [source]

Unverified a positive monthly price move alongside a real, working anti-sybil check is a comfortable story to tell, but this course's evidence cannot separate "buyers trust the mechanism" from "buyers simply expect the price to keep rising" as the actual reason the token appreciated. The formula ties emission to price and price alone; anything connecting that price to the mechanism's quality is inference, not measurement.

Failure modes and attack surface

exclude_same_miner's dedup is explicitly limited to shared IP, Docker username, or coldkey overlap — an operator willing to spread submissions across genuinely separate infrastructure and wallets sits outside what this check looks for. [source]

The commented-out alpha-burn scoring is a live example of documentation drift inside the subnet's own scoring code: the docstring for get_onchain_scores still describes a 50/50 blend that the executed code has not implemented for at least as long as the linked release notes describe removing it. A miner or outside reader trusting the docstring over the code would misjudge exactly how weights get set today. [source] [source]

The decay mechanism that rewards continual updates also creates pressure to resubmit even when a solution hasn't meaningfully improved, since standing still means losing incentive over time regardless of whether the original submission is still competitive. [source]

What to copy, what to avoid

Copy the isolated-runner design: scoring what a submission actually does inside a sandboxed execution environment, rather than trusting a self-reported number, closes off an entire category of cheap gaming. [source]

Copy the identity-overlap dedup as a cheap first line of defense against multi-accounting, while recognising — and this dossier flags it as unverified rather than solved — that it only catches the overlaps it explicitly checks for. [source]

Avoid letting a scoring function's docstring diverge from what the function actually computes: RedTeam's own pinned commit shows exactly how that happens even with good intentions, and anyone reading the comment instead of the code would draw the wrong conclusion about how miners get paid. [source] [source]