Bitsec.ai — subnet 60

Bitsec pays for finding real security bugs, and its own published code shows exactly how a finding gets checked — right up until the point where an activation switch only the project's own team controls decides whether a judge's work counts at all.

What it does

Bitsec pays for real software security work. A miner submits an agent — code that reads a real codebase and produces a report of vulnerabilities it believes it found — and a validator runs that agent inside a sandbox against benchmark projects, then scores its findings against a known set of real, high- or critical-severity vulnerabilities. [source]

The repository pinned here is explicitly the development and testing sandbox for that agent, not the full production system — its own README points to a separate documentation site for the complete picture, while treating this repository's own code as the final word on how a local run actually behaves. [source] [source]

How the incentive mechanism works

A miner's agent lives in miner/agent.py and must expose one function, agent_main(), returning a JSON report with a top-level list of vulnerabilities. [source] On the judging side, validator/manager.py runs two continuously polling queues — one that executes submitted agents, one that evaluates their reports — and validator/evaluator.py hands each finished report to a scorer class the repository calls ScaBenchScorerV2, described in its own file as doing deterministic, one-by-one matching between what an agent found and what the benchmark actually contains. [source] [source] The result is a structured record — total findings expected, total found, true positives, false negatives, false positives, a detection rate, precision, and an F1 score — that a validator submits back to the project's own platform. [source] [source]

That matching itself leans on an outside judge: a judge's own setup step requires an inference-provider key, used specifically for "scoring and evaluating agent output" — meaning the comparison between a reported finding and a real vulnerability is not simple string matching, but a call out to a language model. [source] What this dossier could not confirm from what was pinned is the exact prompt or matching logic that call runs — the scorer file itself was captured mostly as its own module header and imports, not its full body.

One more piece governs whether any of this runs at all: a freshly registered judge does not receive real work purely by registering and starting its software. The project's own team has to activate it on their platform first, and the README says so directly. [source]

What miners are actually optimising

The stated goal is finding real, high-severity vulnerabilities in real software. What an agent is actually scored against is a specific, curated benchmark set of projects and known findings — one filename in the repository, a curated list of high-severity cases dated to a specific day, is itself evidence that the benchmark is a fixed, versioned artifact rather than an open-ended test of general security skill. [source]

Unverified Because matching runs through a language-model judge rather than an exact, mechanical comparison, an agent's real edge may come partly from producing reports that read persuasively to that judge — clear structure, confident language, plausible-sounding detail — separately from whether the underlying finding is actually correct. This dossier's pinned source does not show the judge's own prompt or grading criteria, so this is this author's own inference about a risk the design creates, not a documented fact about how often it actually happens.

Why it earns

Under this network's own design, a contest's share of a day's pay against every other contest runs on one formula and nothing else: share_i = p_i × (1 − b_i) / Σ_j p_j × (1 − b_j), where p is that contest's own moving-average price and b is a penalty for pay an owner withheld to its own keys. [source] [source] A precisely specified scoring pipeline, like the one described above, can only move that number by first moving price — by making enough people want to hold the token — so a documented mechanism is never, on its own, proof of what is actually driving the pay.

Mechanism evidence

The visible design is genuinely specific: a structured evaluation record with named fields for true and false positives, precision, and an F1 score, produced by a scorer that re-runs each submission itself rather than trusting a self-report. [source] [source] Set against that specificity is the activation gate: however well the scoring pipeline works in principle, a judge only ever gets to run it after the project's own team switches it on, which puts a discretionary human step ahead of every measurement this section otherwise describes. [source]

Concentration evidence

Bitsec's 2257 @ 8871732 holders is a count of wallets holding the token on the open market, not a count of anyone with a say in setting a weight here — that power sits with a much smaller permitted set of judges, reported in the technical note at the end of this dossier, and the activation gate above means even that smaller number understates who is actually doing the judging at any moment. [source] Root proportion — how much of that judging power traces back to stake placed generally into the root network rather than into Bitsec's own token — sits at 15.1% @ 8871732 here. [source]

Price evidence

Bitsec's price fell -20.17586304646128 @ 8871732 percent over the trailing month even as it rose 9.81480079820069 @ 8871732 percent over the trailing week, against a price of 0.004381582 @ 8871732 TAO and 1146243199030 @ 8871732 rao traded over the preceding day, with a market capitalisation of 21321937066438 @ 8871732 rao. [source] Because the cross-contest formula above answers only to price, this recent mixed movement — a weekly bounce inside a month-long decline — is, by construction, a real part of the earnings picture here, independent of anything the scoring pipeline above does or does not reward well.

Failure modes and attack surface

The activation gate is the clearest structural risk this dossier can point to: a contest that can, by design, refuse to let a properly registered, properly staked judge do any judging until its own team flips a switch is not fully permissionless, whatever else its code does correctly. [source] That gate also means this dossier cannot confirm how many of Bitsec's permitted judges are actually active and scoring at any given moment, as opposed to registered but waiting.

A judge relying on a language model to decide whether a reported finding matches a real vulnerability inherits that model's own weaknesses — a persuasive but wrong report and a plain but correct one are not guaranteed to be told apart by the same rules a strict, mechanical comparison would apply. [source] Nothing pinned here shows safeguards against that specific risk beyond the deterministic, one-by-one matching the scorer's own name promises.

What to copy, what to avoid

Worth copying: running every miner-submitted agent inside an isolated sandbox before trusting anything it reports, and re-scoring its actual output rather than any claim it makes about itself. [source] [source]

Worth avoiding: a judge-activation step that sits entirely with the project's own team. A contest can publish open, well-specified scoring code and still keep real control of who gets to judge in a much smaller, private room than the code alone suggests. [source]