Subnet 61: RedTeam
RedTeam is Bittensor Subnet 61, a subnet built by Innerworks that drives cybersecurity innovation through competitive programming challenges. Miners submit code solutions to security-focused technical challenges, and the network rewards solutions that are both high-quality and original, with the intent that strong solutions can be integrated into real-world products. The incentive-mechanism code is maintained in the RedTeamSubnet/RedTeam repository.
What the Subnet Produces
The subnet’s output is a stream of vetted code solutions to security challenges. Its defining feature is that originality is scored alongside performance: every submission is run through a similarity check against previously accepted solutions and against other submissions made the same day, and copies or near-duplicates are rejected. This pushes miners to contribute genuinely new work rather than resubmitting or cloning existing solutions.
Submissions are evaluated once per day, and scores across miners are normalized so that meaningful improvements are rewarded proportionally rather than winner-take-all. The emphasis on fresh, non-duplicate contributions is what keeps the challenge set advancing over time.
Originality and Challenge Context
The RedTeam repository frames originality as part of the subnet’s security value, not only as an anti-spam rule. A code solution can be technically successful and still add little value if it closely copies an older submission. By comparing new solutions with previous accepted work and with other submissions from the same day, the subnet tries to reward miners that bring genuinely new approaches to the challenge set.
That design fits the cybersecurity use case. Red-team style work is useful when it uncovers a new attack path, improves a defense, or finds a better way to solve a constrained technical problem. A subnet that rewarded only repeated working answers would quickly converge on copied solutions. A subnet that also rewards originality can keep pressure on miners to find distinct improvements.
The same source says strong solutions can be integrated into real-world products. That gives the subnet’s output a practical framing: the challenge result is not just a leaderboard response, but a candidate security improvement that may be reused after review. Originality checks support that goal because a product team gains little from many miners submitting the same code path, even if the code path solves the current challenge.
This makes duplicate filtering a quality boundary as well as a participation rule. It helps define whether a submission adds to the pool of security techniques the subnet is collecting, rather than only asking whether the submitted code passes the immediate challenge.
The repository also describes RedTeam as performance-based and improvement-oriented. In reader terms, the useful output is not a single permanent winning answer; it is an evolving pool of vetted solutions. Daily evaluation, duplicate rejection, and incentive decay all point toward the same goal: keep the active challenge set moving instead of letting stale submissions dominate.
The public RedTeam site is the project entry point, while the repository explains the challenge and originality model used here. Together, those sources support reading Subnet 61 as a cybersecurity challenge subnet where quality and novelty are both part of the contribution being measured.
Miner and Validator Roles
Miners develop and submit code solutions to the active challenges. Beyond solving the challenge well, a miner has to keep its submissions current: the repository describes a decay mechanism in which a submission’s incentive fades over time, so miners must regularly update their solutions to hold their position, and duplicate submissions are penalized.
Validators run the challenges and compute scores. According to the repository, a miner’s final score combines its challenge performance with a 50% alpha-burn component — the latter reserving half of the alpha to support the subnet’s token rather than paying it out — and when a challenge has no valid submissions, its weight is directed to burn instead. Those validator scores become the weights that feed into Yuma Consensus, which converts them into the incentive split across miners and validators.
On-Chain Identity
The live Finney identity for netuid 61 registers the subnet name as RedTeam, with the description “The RedTeam subnet by Innerworks is a decentralized platform designed to drive innovation in cybersecurity through competitive programming challenges.” The registered project website is theredteam.io and the GitHub repository is RedTeamSubnet/RedTeam, which is the source of truth for the challenge and scoring system described above. Live subnet data is available on TaoStats.
Relationship to Yuma Consensus
Subnet 61 uses Yuma Consensus to convert the challenge-performance weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The Yuma Consensus documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In RedTeam’s context, validators run security challenges, score each miner’s solution on performance and originality, apply duplicate-similarity filtering, and combine the result with a 50% alpha-burn component before submitting weight vectors. Scores are normalized across the active miner set so that meaningful improvements are rewarded proportionally. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Reader Boundary
Subnet 61 RedTeam should not be read as generic Bittensor subnet documentation, a penetration testing service, or a place to upload unsafe malware outside the validator-run challenge format. It names one subnet’s competitive cybersecurity challenge system, where miner output is evaluated for both challenge performance and originality, including similarity checks that reject near-duplicate solutions (RedTeam repository).
It is also not a winner-take-all leaderboard. The repository describes daily evaluation with score normalization and incentive decay, so miner standing depends on current, non-duplicate solution quality rather than a single permanent best submission. Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Subnet 61, 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 61 is registered as the live production subnet at netuid 61. 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 61 RedTeam should not be read as generic Bittensor subnet documentation, a managed penetration-testing service, or a guarantee that any submitted solution is production-secure. It names one subnet’s competitive cybersecurity-challenge market — miners submit original code solutions that are rewarded for quality and originality — on netuid 61 (RedTeam repository, Understanding Subnets, Glossary: Netuid).
A miner’s reward reflects the scored quality and originality of a challenge solution, so it should not be read as certification that the code is safe to deploy as-is (RedTeam site — theredteam.io).