RedTeam: how the mechanism works

RedTeam pays for offensive and defensive security tools, and a program that scores attacks and evasions has a problem the rest of this course has not had to face yet: someone has to decide, mechanically, whether an attack actually worked.

RedTeam runs security challenges as a competitive-programming contest, operated by a company called Innerworks. Its own overview describes it as "a decentralized platform designed to drive innovation in cybersecurity through competitive programming challenges," where solutions "can be integrated into real-world products to improve their security features." [source]

Concretely, this means miners submit small, self-contained programs against a rotating set of named challenges. At the time this course's source was pinned, two challenges were live and weighted in the subnet's own registry: AB Sniffer, where a submission has to detect which browser-automation framework is driving a page, and Bot Virus, where a submission has to build a bot that *evades* that kind of detection and completes a task anyway. [source] [source] One challenge scores defense, the other scores offense, and both feed the same emission.

The grading problem

Bot Virus is the clean case of the problem this page is really about. A miner submits exactly two files — bot.py and a Dockerfile — and the challenge's own objective is explicit that self-reporting is not how this gets scored: "the score is based on the runner's evaluation of the submitted image, not on a locally reported value." [source] The documented flow is: a miner receives a task, returns bot.py and Dockerfile, "the challenge builds the submitted container in an isolated runner," and that runner "applies the Simple Bot gate, then browser-web checks, and returns feedback and a score." [source] The requirements page repeats the isolation claim directly: "the runner builds and executes untrusted miner containers in an isolated environment." [source]

So a successful attack is judged by a two-layer check inside that runner, not by the miner's own claim. "Simple Bot is the first layer. It is a pass/fail gate containing common bot-detection checks," and "Browser-web is the main check. Its configured browser sessions determine the submission's score." [source] [source] The only authoritative answer a miner can query is the runner's own verdict: "GET /result for evaluator feedback; it is the authoritative result for a submission." [source]

Here is the part this course's own pinned source cannot answer: who wrote that runner, and can anyone outside RedTeam read it? The public repository defines a base ChallengeManager class whose two scoring methods are declared but never filled in — update_miner_scores and get_challenge_scores are both plain @abstractmethod stubs in the pinned code. [source] [source] The concrete subclasses that actually implement them — abs_challenge.challenge_manager.ABSChallengeManager for AB Sniffer, bv_challenge.challenge_manager.BVChallengeManager for Bot Virus — are named only as class paths inside each challenge's own closed, versioned Docker image: redteamsubnet61/rest-abs-challenge:6.0.2 and redteamsubnet61/rest-bv-challenge:1.0.3, pulled from a private registry and run locally by every validator. [source] [source] The subnet's own testing manual confirms the split directly: local testing uses "miner-created framework runners," while production scoring uses "private RedTeam framework runners and presets." [source] [source]

In other words, every validator really does run the judge locally — the challenge_container_run_kwargs block in that same registry entry is what launches it — so this is not a remote call to someone else's server, but the judge's own source is not part of the code this course's snapshot can read. [source] A validator runs a binary it trusts by tag; it cannot audit what "passing the anti-bot checks" actually checks for.

Unverified whether that closed judging image is published anywhere for independent review — a security audit, a bug bounty, a changelog describing what changed between 6.0.1 and 6.0.2 — is not something this course's pinned source shows either way. This course only has the client-side contract (task in, score out), not the judge's own code, so silence here is this author's search result, not a documented fact about RedTeam's practices.

Before a submission ever reaches that runner, it passes through a second, entirely different check: a similarity engine that exists "to ensure that every submission is unique, original, and meets the quality standards required for scoring," comparing a new submission "against a specific subset of existing submissions to ensure it is not a duplicate or a minor modification." [source] [source] The comparison pool is every past accepted submission plus every submission made so far that same day. [source] A submission that scores above the acceptable threshold against that pool is "skipped from scoring entirely," with a stricter bar (around 0.9) against a miner's own past work than against a rival's (around 0.7). [source] [source] Worth noting for anyone relying on this as a safeguard: "a comparison score of 0 always indicates a failure or error during the comparison process," and the documented behaviour on that outcome is to skip it — "a 0 will never trigger a similarity penalty or rejection." [source] [source] A broken comparison call fails open, not closed.

A third, narrower check runs after scores come back: exclude_same_miner, in the public src/redteam_core/validator/miner_manager.py, groups every submission "that share an IP, Docker username or have overlapping coldkeys," and keeps only the highest score in each group. [source] [source] This one is genuinely public and auditable — unlike the runner, its full logic sits in the repository this course can read.

What miners are actually optimising

A submission does not earn forever. The subnet's own release notes describe a "decay mechanism": "submissions receive incentives for a limited period, requiring miners to regularly update their solutions to maintain their position," backed by the same comparison system that "identifies and penalizes duplicate submissions." [source]

Put decay and the similarity thresholds next to each other and the literal-optimisation target comes into focus. RedTeam's own framing is that this rewards "continuous improvement and innovation" — but the mechanism as built does not actually measure improvement, it measures *distance from the existing pool*. A miner who wanted to satisfy the letter of the incentive without doing the underlying security research could resubmit small, cosmetic variations of a working solution just often enough, and just different enough (above roughly 0.9 similarity to their own last version), to outrun decay indefinitely. RedTeam's own docs warn about exactly this shape of gaming without naming it: "To avoid high similarity scores, focus on unique logic and implementation strategies rather than just renaming variables or changing formatting." [source] That the warning exists is itself evidence the incentive rewards apparent novelty, checkable mechanically, rather than security value, which the pinned source gives no way to check mechanically at all.

Do validators do anything besides validate?

Nothing in this course's pinned source shows an individual validator running a paying side business. The subnet's own description of the role stays narrow: its docs list a validator's duties as evaluating miners, assigning scores, maintaining consensus with other validators, and earning rewards — nothing about serving outside traffic. [source] [source]

But the judging pipeline a validator runs is not self-contained. Its internal-services configuration defaults to an authenticated API hosted by RedTeam itself — RT_INS_HOST defaults to scoring-api.theredteam.io — and its storage layer's documented first move on a read is to try "centralized storage" before any local fallback: the code logs "Failed to fetch validator state from centralized scoring server, trying fallback" whenever that first call fails. [source] [source] [source] So the more precise finding is not that a validator moonlights — it is that RedTeam the company operates required central infrastructure (a scoring API, a storage backend, and the closed judging images described above) that every validator's output depends on. Decentralised judgment sits on top of a centralised judge.

Unverified this course's pinned source also carries a live migration notice telling every validator operator to switch to a separate, official repository within one week or stop receiving work. [source] [source] Everything above describes the pinned RedTeamSubnet/RedTeam codebase; whether the new, separate validator repository changes any of this is outside what this course can check.

Why it earns

RedTeam's own docs describe its emission split as 41% to miners, 41% to validators, and 18% to the subnet owner. [source] [source] None of that changes how much of the network's total daily payout flows to RedTeam in the first place: every subnet's cross-network slice runs on one formula, a subnet's own moving-average alpha price divided by that same figure summed across the network. [source] [source]

By that formula, RedTeam is one of this course's stronger earners: A @ 8878789-tier, taking 3.2% @ 8878789 of daily emission, with subnets at or above its rank capturing 81.6% @ 8878789 of the total. It carries 2323 @ 8878789 token holders and 12 @ 8878789 permitted validators judging 75 @ 8878789 active miners, with 14.2% @ 8878789 of its judging stake coming from the root network rather than RedTeam's own alpha. Its alpha traded at 0.007894958 @ 8878789 TAO at the snapshot block, up 44.09229402357833 @ 8878789 percent over the trailing month against 7728924084449 @ 8878789 rao of trading volume the prior day.

None of the figures above are evidence the closed runner judges attacks correctly, that the decay-and-similarity design measures real security value, or that a miner gaming the similarity threshold is rare. The formula that sets RedTeam's earnings has no term for mechanism quality — by construction it can only move by moving the price people pay for RedTeam's own alpha — so this course's evidence cannot separate a token bought because the mechanism is trusted from one bought on momentum alone. [source] [source]

What to copy, what to avoid

Copy the layered defense: a fast pass/fail gate ahead of an expensive main check saves compute on obviously bad submissions before spending real evaluation effort. [source] Copy publishing the client-side contract in full — task, output schema, and result endpoint — even where the judge itself stays closed; a miner can build against a documented interface without ever seeing the grading code.

Avoid closing the judge entirely. RedTeam's public dedup (exclude_same_miner) is auditable and its logic is easy to check against its own claims; its runner is not, since the concrete ChallengeManager subclasses that score every submission ship only as class paths inside closed Docker images. [source] [source] That asymmetry means the single most consequential question on this page — was this attack actually stopped, or evaded? — cannot be checked from outside RedTeam at all. Avoid a similarity check whose failure mode is silent leniency: a comparison score of zero always means the check itself failed, and the documented behaviour on that outcome is to skip the penalty rather than block the submission — the shape an attacker would design if asked to make a plagiarism filter fail safe for the plagiarist. [source] [source]