Subnet 60: Bitsec.ai
Bitsec.ai is Bittensor Subnet 60, a security-focused subnet. The Bitsec sandbox README source describes miners as building AI security agents that analyze codebases and produce vulnerability reports. Validators run those agents in sandboxed environments, score their findings against benchmark ground truth, and submit results back to the platform.
What the Subnet Produces
The subnet’s output is the work of security agents: programs that examine a target codebase and report findings. The Bitsec docs describe the contest as rewarding miners who build better AI agents for finding and fixing exploits in software. That makes the useful output a vulnerability report from an autonomous agent, not a generic chat answer or a checklist.
The same docs say the goal is to improve performance in security products, bug-bounty submissions, and audit challenges. For Taopedia readers, that ties the subnet to applied software security: the agent is valuable when it finds high-impact vulnerabilities in realistic codebases.
Round Context
Bitsec’s incentive documentation describes a round structure with submission, evaluation, and feedback phases. During submission, miners submit their agents privately and each submission is screened. During evaluation, agents that pass screening are evaluated by validators on SCA-Bench codebases against ground truth from human auditors. Afterward, agent code, scores, and evaluation logs become public.
This structure gives the subnet two useful boundaries. First, miner agents compete during a defined round rather than through a continuous stream of ad hoc reports. Second, the benchmark and public post-round artifacts make performance review more transparent after the private submission phase ends.
Screening Boundary Context
Bitsec’s incentive documentation describes screening as a separate step before full validator evaluation. Submitted agents do not go straight from private submission into the main benchmark round. They first pass automated checks that look for basic validity, expected format, unsafe or unfair behavior, near-duplicate submissions, and benchmark-specific hard steering.
That screening boundary matters because Bitsec evaluates untrusted security agents. The main round is meant to compare agents on vulnerability discovery, not to spend validator capacity on files that cannot run, submissions that are copied from another miner, or agents that are shaped around known answers instead of general analysis. Screening narrows the field to submissions that can enter the sandboxed benchmark process.
The docs also describe a preliminary sandbox execution before normal validator jobs are created. That step checks whether the agent can finish on a preconfigured project. Passing this preliminary run does not award the miner a benchmark score by itself; it only makes the submission eligible for the main round evaluation.
The same docs connect this to reliability in the scored phase. Agents can be run more than once on a codebase and scored by multiple validators, so a strong submission needs repeatable vulnerability discovery rather than a lucky single report. That keeps the screening and evaluation stages aligned: screening checks whether the agent is eligible to compete, and evaluation checks whether it performs reliably against the benchmark.
For readers, this explains why Bitsec’s scoring is not only about the final vulnerability report. The subnet first filters for runnable and fair submissions, then evaluates surviving agents against SCA-Bench codebases and human-auditor ground truth. The screening stage protects the benchmark comparison, while the evaluation stage decides which agent performed best. Public post-round artifacts then make that result easier to inspect.
References: Bitsec incentive mechanism docs, Bitsec sandbox README source
Scoring Context
The incentive docs describe Bitsec as a hard benchmark where agents need to match critical and high findings while performing reliably under sandbox resource constraints. The winner is the top-scoring agent, and tie-breakers favor the number of confirmed vulnerabilities found.
That scoring frame is narrower than “find anything suspicious.” The subnet rewards agents that surface benchmarked security findings and survive the screening and validator evaluation process. It also means a miner’s best strategy is to improve the agent’s actual vulnerability discovery performance, not simply to produce longer reports.
Miner and Validator Roles
Miners submit an agent — a self-contained program — to the subnet platform. The agent is what competes: a miner improves its standing by writing an agent that produces better security results on the assigned projects.
Validators evaluate the submitted agents by running each one inside an isolated Docker container with resource and time limits, capturing its output, and scoring it against the benchmark task. Running agents in disposable, resource-limited containers keeps untrusted miner code contained during evaluation.
Source and Live Data
Live SN60 data is available on TaoStats. The mechanism details in this article are tied to the Bitsec sandbox README and incentive documentation rather than to live identity fields.
Relationship to Yuma Consensus
Subnet 60 uses Yuma Consensus to convert the security-agent score weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The linked documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Bitsec.ai’s context, validators run miner-submitted security agents inside isolated Docker containers with resource and time limits, score the resulting vulnerability reports against SCA-Bench ground truth from human auditors, and translate those benchmark scores into weight vectors for the subnet. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Bitsec.ai (SN60), that sequence changes how readers should interpret security agent submission examples and benchmark scoring outcomes.
In localnet, Bitsec-compatible miners and validators can be developed and tested in an isolated environment. Localnet agent evaluation scores and emission outcomes do not represent production subnet performance.
On testnet, Bitsec-compatible security agent submissions can be exercised in a shared, non-production network. Testnet screening results and validator weights are separate from mainnet subnet state.
On mainnet, Bitsec.ai (SN60) is the live production subnet where miners submit autonomous security agents and validators score those agents against SCA-Bench codebases to determine real Bittensor emissions. The Bitsec.ai subnet repository describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. An agent benchmark score or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 60 Bitsec.ai should not be read as generic Bittensor subnet documentation, a guarantee of vulnerability findings on arbitrary codebases, or proof that every security report format scores the same way. It names one subnet’s autonomous security-agent benchmark on netuid 60 (Understanding Subnets, Glossary: Netuid).
Agents Compete Through Defined Rounds
Bitsec incentive documentation describes submission, screening, evaluation, and feedback phases rather than a continuous stream of ad hoc reports (Bitsec incentive mechanism docs).
Readers should treat round status and screening eligibility as part of the scoring context.
SCA-Bench Ground Truth Defines the Scored Signal
Validators score surviving agents against SCA-Bench codebases and ground truth from human auditors (Bitsec incentive mechanism docs).
That makes the useful signal benchmarked vulnerability discovery rather than report length alone.
Validator Weights Still Flow Through Yuma Consensus
Subnet 60 uses Yuma Consensus to convert validator weight submissions into emission shares each tempo (Yuma Consensus, Emission).