How TAOStatus works
Two mechanisms, one subnet
Bittensor Subnet 104 rewards miners for two kinds of work, and each one powers a side of TAOStatus. Mechanism 0 pools miners' LLM capacity to run the Quantum Analyses on this site. Mechanism 1 puts miners' security agents through sandboxed, proof-based testing and lists the ones that pass on the Agent Marketplace.
Mechanism 0
LLM Keys
Miners contribute working LLM API capacity.
A miner offers a working API key. The validator relays it, encrypted, to TAOStatus, which verifies it and puts it to work running Quantum Analyses. Reward follows how reliably that key is actually used.
- Key offered
- Relayed encrypted
- Verified & used
- Usage reported
- On-chain weight
Powers Quantum Analysis & Agent 1 vs 1
Mechanism 1
Security Agents
Miners submit autonomous security-testing agents.
A miner submits an agent as a container image. A validator runs it in isolation against a freshly planted vulnerable target and scores only what it can prove. Agents that pass become available on the marketplace for real audits.
- Agent submitted
- Intake checks
- Sandboxed run
- Exploit proven
- Marketplace
Powers Agent Marketplace audits
Each mechanism has its own validator logic and its own scoring today, so one can change without touching the other. They share the chain, the roles and the wallet, and they are being built to work together more closely in upcoming releases.
How a subnet gets analysed
Start from a subnet, or a question of your own. Four dedicated agents go and read its live signals from the places that actually hold them: the Twitter Agent for sentiment, the Chain Agent for on-chain state, the Discord Agent for community signal, and the GitHub Agent for build activity. Those metrics become the evidence for a Quantum Analysis, where adversarial agents argue them out, and a Judge turns every perspective into a single, cited conclusion. The models doing the arguing run on LLM capacity that Mechanism 0 miners contribute.
5
Pipeline stages
4
Source agents
4
Analysis agents
4
Quality dimensions
Discovery to Conclusion
Five stages: discover the subnet, gather its signals, turn them into citable evidence, argue them out, then conclude
Subnet Discovery
Pick a subnet from the live chain-synced catalog, or ask a question of your own
Source Agents
Dedicated agents pull that subnet's live signals from Twitter, the chain, Discord and GitHub
Evidence Pack
Every retrieved signal becomes an ID-tagged item the agents must cite by name
Quantum Analysis
Three adversarial agents argue the evidence out across independent, cross-exam and revision phases
Final Conclusion
The Judge weighs every perspective into one verdict, with confidence and the evidence it used
Quantum Analysis
independent positions → cross-examination → revision → dispute if unresolved
The Four Source Agents
A subnet does not live in one place, so no single feed can describe it. The Twitter, Chain, Discord and GitHub agents each read the source they are good at, and the analysis sees all four answers side by side.
Everything arrives as citable evidence
Each returned signal is tagged with its source and given an evidence ID. The analysis agents may only argue from those IDs, which is what makes a conclusion traceable back to the post, the block, the message or the commit it came from.
Twitter Agent
Sentiment & NarrativeReads what the ecosystem is actually saying: posts, reach, recurring themes, and how sentiment around the subnet has moved.
Chain Agent
On-chain TruthReads live network state for the subnet: emissions, stake distribution, validator trust and miner activity. The numbers nobody can spin.
Discord Agent
Community SignalReads the operational pulse: how responsive the team is, what holders and builders are asking, and which problems keep resurfacing.
GitHub Agent
Build ActivityReads the work itself: commit cadence, releases, open issues and who is contributing, what the repository says regardless of the pitch.
Quantum Analysis
The gathered metrics are not summarized, they are argued over. Three agents take deliberately opposed views of the same evidence, and a fourth rules on what survived.
Why argue instead of summarize
A single pass over the data agrees with whatever it read first. Forcing the strongest case for AND against the same evidence is what surfaces the weak signal, the missing source, and the number that only looks good in isolation. You can read every turn of it in the transcript.
Where the model capacity comes from
Models marked as miner-contributed run on API keys that Mechanism 0 miners lend to the subnet. Each key is encrypted before it leaves the miner, verified before use, and rewarded only for how reliably it actually serves analyses like this one.
Convergent
Argues FORBuilds the strongest supported reading of the evidence, citing specific evidence IDs and answering the obvious objections before they are raised.
Divergent
Argues AGAINSTArgues the opposing reading just as hard, exposing weaknesses, gaps and contradictions in the signals the Convergent agent leaned on.
Critical
Stress-tests bothQuestions both positions: unsupported assumptions, missing data, and claims the evidence does not actually carry. Deliberately not a tiebreaker.
Judge
Final verdictReads the whole exchange and returns one verdict: SUPPORTED, REFUTED or INSUFFICIENT, with a confidence level and the evidence IDs it relied on.
Analysis Process
- Step 1Signal CollectionSource Agents
Each source agent is asked about the same subnet at the same time. What comes back is tagged, attributed to its source, and given an evidence ID.
- Step 2Independent PositionsNo Cross-talk
Every analysis agent reads the evidence pack and commits to a position before seeing anyone else's, so nobody anchors on the first answer in the room.
- Step 3Cross-ExaminationAdversarial
The agents question each other's positions directly. Each answer has to hold up against the specific evidence it claims to rest on.
- Step 4RevisionOn the Record
Agents state what they changed and what they still disagree about. Moving under pressure is recorded, not hidden; and so is refusing to move.
- Step 5DisputeOnly If Unresolved
When the positions have not converged, one further round targets the exact remaining disagreement instead of restating the whole argument.
- Step 6Final ConclusionJudge
The Judge weighs every perspective: chain data, sentiment, community and code, into a single conclusion, shown at the top of the results and in full at the end of the transcript.
Conclusion Quality
This scores the ANALYSIS, not the subnet. A subnet does not get a grade here, the reasoning does.
Every conclusion is measured on the same 0–100 rubric: did it follow from the evidence, did it cite real evidence IDs, did it say what would prove it wrong, and was its confidence honest. That is what makes one run's answer worth as much as another's, whichever model produced it.
Share of the 100-point total
Does the conclusion actually follow from the evidence gathered? The largest share, because a well-argued wrong answer is still a wrong answer.
Every claim must cite evidence IDs that exist in the pack, with a bonus once most of the pack is actually used. Uncited assertions earn nothing.
Three equal parts: a concrete mechanism, stated limitations, and criteria that would prove the conclusion wrong.
Confidence has to match being right. Certainty on a wrong call is penalised more than an honest “insufficient evidence”.
Deductions
- Authority deferenceup to ‒15Leaning on “experts agree” or “widely accepted” instead of the evidence in front of it.
- Refusal to answer‒20Declining a question the evidence pack was sufficient to answer.
Live Data & Re-analysis
Signals are read fresh on every run, straight from the chain and the source agents
Live Subnet Catalog
Subnets and their categories are synchronized from the Bittensor chain itself, so a newly registered subnet is discoverable without anyone editing a list. The page tells you how fresh that snapshot is.
Multi-Source Evidence
Each source agent answers independently and in parallel, so one quiet channel cannot decide the outcome. Where sources disagree, that disagreement is itself evidence the analysis has to resolve.
Re-analysis On Demand
Signals move - emissions shift, a repository goes quiet, sentiment turns. Any subnet can be analysed again at any time, and each run is a fresh read of the sources as they are right now.
Analysis flow
How an agent earns its listing
Instead of lending capacity, a Mechanism 1 miner contributes an autonomous security-testing agent. The validator's job is to decide, objectively, whether that agent can find real vulnerabilities. It scores the agent on whether it can discover and prove a planted weakness, not on whether it can write a plausible-looking report, and the agents that pass reach the Agent Marketplace.
5
Intake checks
4
Score levels
3
Capability signals
2
SQLi techniques
Submission to Marketplace
Five stages: submit the agent, inspect it, let it attack a target it cannot escape, check what it claims, then reward what it proved
Agent Submission
A miner packages its autonomous security-testing agent as a container image and submits it
Intake Checks
Five ordered checks inspect the image before, and while, it is first allowed to run
Isolated Execution
The agent attacks a freshly provisioned, deliberately vulnerable target on a private network
Proof Verification
Findings are checked against a secret answer key the agent never sees, then replayed on a fresh target
Score & Marketplace
Proven capability becomes on-chain weight, and agents that pass are listed for real audits
Every submission is treated as untrusted code
An agent is software written by an unknown party whose whole purpose is breaking into things. So it is inspected before it is loaded, run only under strict limits, and credited only for findings it can prove against ground truth that the validator alone holds.
Five Intake Checks
The checks run in order, and the first failure stops the run and names exactly one reason, so a verdict always records where and why a submission was turned away.
A failure on the validator's side, such as the container runtime being unreachable, is marked retryable and is never held against the miner.
- Stage 1File
The file exists, is within a size ceiling, and its leading bytes prove it is a real archive. The extension is never trusted.
- Stage 2Structure
Read as a stream, never extracted, and it must be a Docker or OCI image. Path traversal, escaping symlinks, device nodes and archive bombs are refused here.
- Stage 3Load
Only now does the image reach the container runtime, and the reference it reports back is pattern-checked before it is used anywhere.
- Stage 4Inspect
Metadata only: the right architecture and OS, within layer and size limits, and an entrypoint that actually runs something.
- Stage 5Dry run
The first time the code runs: no network, capped memory, CPU and processes, a read-only filesystem, every capability dropped, and a forced kill on timeout.
Contained Execution
Running untrusted code to see whether it can break into something is itself a security problem. In evaluation, one job is one agent against one freshly provisioned target, and everything is torn down on every exit path.
Private Network
One agent, one targetAgent and target run as separate containers on an internal network with no route to the internet or the host, and no name resolution to exfiltrate through.
User-space Sandbox
Beyond container limitsThe agent runs under a user-space kernel rather than directly on the host's, so the boundary does not rest on container limits alone.
Behaviour Monitor
Judged on attemptsEvery system call can be observed. Reaching for the runtime socket or probing for metadata it was not given marks an agent suspect, even when the sandbox stops it.
Safety Veto
Out of scope scores zeroEscaping, hunting for shortcuts or acting outside the task is invalid behaviour. A blocking safety violation scores the run zero, whatever the agent reported.
Proof, Not Prose
For every run the validator generates a fresh answer key: a secret value called the canary, a randomized database schema, and a record of which single endpoint carries the planted weakness.
The canary lives only inside the target, reachable only through the flaw, and changes every run. An agent that returns it exactly must have travelled the real exploit path. Its findings file is parsed strictly as untrusted data, and each finding is a claim to be checked against that key. Scoring is deterministic: the same inputs always produce the same score.
Task score for a single run
Nothing was proven, however confident the report sounds.
The secret was extracted, but the exploit has not yet been reproduced on a fresh target.
The validator replays the agent's own steps against a fresh target with a new canary, and it works again: a real exploit, not a lucky read.
All of the above, and the finding also names the correct endpoint and parameter.
Deductions
- False positivefixed penaltyEvery finding against an endpoint known to be safe costs points, floored at zero, so flagging everything and hoping is punished.
- Safety violationrun = 0A blocking violation zeroes the run. Across an agent's runs, a single one disqualifies it.
Capability, Not Luck
One solved run can be luck, so capability is measured across many freshly randomized runs. The result becomes the miner's on-chain weight. An outage on the validator's side means “don't score this round”, never a zero.
- Consistency. Does it solve run after run? A failed run counts as zero. This is the main driver.
- Efficiency. Surgical or brute force? A light modifier on top, never the deciding factor.
- Safety. One blocking violation across all of its runs disqualifies the agent.
Why cheating does not pay
Randomized Ground Truth
Nothing to memoriseA fresh canary and schema every run, so an answer cannot be memorised, copied between miners, or leaked.
Unforgeable Proof
Canary or nothingThe canary exists only inside the target, reachable only through the planted flaw. No canary scores zero; a made-up one scores zero.
Decoys & Traps
Precision mattersSafe endpoints that look vulnerable, including one that returns a realistic database error without being injectable.
One Agent, One Owner
No double earningIdentity comes from the image's filesystem layers and entrypoint, so a re-save or re-tag is the same agent, and a copy submitted by another miner is rejected as a duplicate.
SQL Injection
The validator provisions a small web application backed by a database, seeded with the per-run canary. Of its endpoints, exactly one is genuinely injectable; the rest are decoys, and one is a trap. The technique is randomized per run too, so an agent that only knows one approach fails the runs it cannot handle.
Union-based
The injection returns the secret directly in extra result rows: the fast path to extraction. Exercised in string and numeric contexts.
Boolean-based (blind)
The response carries only a true/false signal, so the secret has to be rebuilt one character at a time. Also in string and numeric contexts.
SQL injection is the first domain, not the limit. The submission, isolation, verification and scoring machinery assumes nothing about it, so further categories can each be added with their own target and answer key.
The Agent Marketplace
Validation establishes that an agent works. The marketplace makes it usable: it is where a proven agent stops being a scored row in a validator's database and becomes something a security team can find and run.
Network-scored agents
The subnet's own output. The security validator pushes each agent's scores to the marketplace, which shows them with their real track record. Only metadata and scores are published, never the agent's code or image.
Listed agents
Curated entries with a description and a price that you can run against a target of your own. One purchase is one audit run, priced in USD and paid in TAO, verified on-chain before the run starts.
The scores that follow an agent into the catalog are the same scores that drove its on-chain reward.
Agent lifecycle
How the Mechanisms Fit Together
Each mechanism has its own validator logic and its own scoring today, so one can change without touching the other. They share the chain, the roles and the wallet, and they are being built to work together more closely in upcoming releases.
Shared
One subnet, one chain, and the same three roles: miners contribute, validators evaluate and set weights, the protocol does the work. Both sides use the same Bittensor wallets and settle in TAO.
Separate
Each mechanism has its own validator logic, its own scoring and its own weights. A miner takes part in whichever matches what it can offer: LLM capacity, a security agent, or both.
Converging
LLM capacity and autonomous agents are two halves of the same idea, useful intelligence proven under pressure. Upcoming releases will connect the two tracks more closely.
A conclusion here is a structured, AI-assisted reading of the signals a subnet was giving off at the moment it was analysed. Treat it as a decision-support tool, not investment advice: the transcript shows every step, and the cited evidence is there to be checked. A security audit reports what an agent found on one run; only point it at targets you own or are authorised to test.