Documentation
1. Overview
The TaoStatus subnet coordinates three distinct roles, miner, validator, and protocol, around a single objective: allowing miners to contribute spare large-language-model (LLM) API capacity to a shared pool, and rewarding them on-chain in proportion to how reliably that capacity is actually used.
The arrangement is deliberately asymmetric. Miners hold the only thing of real value, a working API key, but have no visibility into how it is used once contributed. The protocol holds no chain authority and cannot influence rewards directly. The validator sits between the two, acting as both a courier that cannot read what it carries and the sole author of on-chain weight.
In brief: a miner offers a key. The validator relays it, encrypted, to the protocol. The protocol verifies, stores, and later reports on its use. The validator converts that usage data, and nothing else, into on-chain reward.
2. Governing Principles
Two constraints hold across every interaction described in this document. They are architectural, not incidental, and they explain most of the design decisions that follow.
2.1 All miner-protocol communication is intermediated
Miners do not contact the protocol, and the protocol does not contact miners. Every exchange between them passes through the validator, which forwards submissions without the ability to decrypt them. This gives the validator complete auditability over what was exchanged and when, without granting it access to the contents.
2.2 The protocol has no authority over chain weight
The protocol's role is limited to verification, custody, and reporting. It supplies the validator with raw, factual usage data, success counts, failure counts, latency, activity status, and nothing more. The validator alone determines what that data is worth in terms of on-chain reward. This separation ensures that reward-setting logic remains fully auditable within the validator, independent of any protocol-side change.
3. Roles and Responsibilities
Miner
The miner operates independently by configuring and providing spare LLM API capacity. When requested by a validator, the miner evaluates the request locally, encrypts its working API key using the protocol's public key, and sends the secure submission. The miner remains completely isolated from how the key is utilized or evaluated once accepted.
Miners are entirely responsible for managing their own API quotas and maintaining valid keys for supported providers (e.g., OpenAI, Anthropic). Their client evaluates requests safely: if they haven't opted in, or if their configured provider isn't supported in a given round, they simply decline the request rather than submitting malformed data.
Responsibility: Holds a raw LLM API key. Opts in to participation, selects a provider and model, and responds to periodic submission requests from the validator.
Visibility: Its own key only. No visibility into other miners, protocol internals, or reward calculations.
Validator
The validator acts as the secure intermediary and the sole author of on-chain rewards. It initiates submission rounds to gather encrypted keys from miners and relays them directly to the protocol. It later polls the protocol for raw performance data (such as success rates and latency) and mathematically converts this usage data into final on-chain weight submissions.
Crucially, validators enforce the system's trustlessness. Because they only relay encrypted payloads, they never have access to the underlying plaintext API keys, removing any risk of key theft by validators. At the same time, because the protocol itself has no authority to submit chain weights, the validator retains full, auditable control over how rewards are calculated and distributed.
Responsibility: Initiates submission rounds, relays encrypted key material to the protocol without decrypting it, polls for usage reports, and computes and submits on-chain reward weights.
Visibility: Which hotkey submitted what, and all usage reports. Never the plaintext key value.
Protocol (BT Arena)
The protocol is the engine that validates and utilizes the provided resources. Upon receiving encrypted keys from the validator, it decrypts and tests them against the actual provider to ensure they are functional. It securely stores valid keys, monitors their ongoing health and usage, and provides transparent, factual performance reports back to the validator.
Responsibility: Verifies submitted keys against an allow-list, decrypts and preflight-tests them against the real provider, rejects duplicates, stores accepted keys encrypted at rest, and reports usage back to the validator.
Visibility: The plaintext key, transiently, only during verification. No access to chain state or reward weights at any point.
The Multi-Agent Quantum Analysis Engine
At the core of the protocol's analytical framework lies the Multi-Agent Quantum Analysis Engine. Rather than relying on a single AI model to process data and generate a unilateral decision, the engine distributes the workload across a suite of specialized agents. Each agent is tasked with observing a problem from a distinct perspective—gathering data, identifying patterns, and contributing to a shared knowledge base before engaging in a structured quantum analysis.
This architecture ensures that conclusions are not simply generated, but rigorously researched, challenged, evaluated, and justified. The system follows a deliberate, sequential pipeline:
Specialized Data Agents
The system employs specialized agents to monitor distinct data streams. This guarantees that the final quantum analysis is informed by a diverse set of signals rather than a single, potentially biased source:
- Discord Agent: Monitors community discussions to gauge grassroots sentiment, track recurring themes, and understand direct community concerns.
- Twitter/X Agent: Analyzes broader social activity and public narratives, tracking shifts in attention and identifying influential discourse.
- On-Chain Agent: Provides verifiable, data-driven evidence by analyzing blockchain activity, including TAO transactions, staking behaviors, and emissions.
- Whale/Wallet Agent: Monitors the behavior of significant token holders to detect large accumulations, distributions, and other meaningful capital movements.
The Quantum Analysis Layer
Once the initial analysis is complete, findings are deposited into a shared knowledge base and the quantum analysis layer is activated. This stage is intentionally adversarial; its purpose is to ruthlessly cross-examine evidence rather than blindly accept it.
The Positive Agent is tasked with building the strongest possible argument in favor of a conclusion. It aggregates positive signals, growth indicators, and strong fundamentals, answering the question: "Why is this conclusion correct?"
Conversely, the Negative Agent actively attempts to dismantle that argument. It searches for risks, contradictions, and weak assumptions, answering the question: "Why is this conclusion flawed?"
Judgment and Final Decision
The final arbitration is handled by the Judge Agent. The Judge reviews the entirety of the shared knowledge base—including the raw data, the historical context, and the arguments presented during the quantum analysis.
The Judge does not simply count which side raised more points. Instead, it evaluates the empirical weight of the evidence, determining which arguments are supported by verifiable data. The resulting output is a high-confidence assessment that clearly articulates both the final conclusion and the specific rationale behind it.
4. The Submission and Verification Cycle
The cycle below repeats continuously in the background for every participating miner. It is presented here as a sequence of stages; timing details for each stage are given in Section 5.
- 1
Stage 1 - Preparation (miner-side, one time)
A miner operator enables participation and configures which provider and model it is offering, along with the corresponding API key, entirely within its own environment. No data leaves the miner at this stage.
- 2
Stage 2 - Submission request (validator-initiated)
The validator retrieves the protocol's current public key and its current list of accepted providers and models, then issues a submission request to every eligible miner. These values are fetched fresh on each round rather than cached, so a request is never encrypted against a key the protocol has since rotated away from.
- 3
Stage 3 - Miner response
Each miner evaluates the request locally against its own configuration:
- If the miner has not opted in, it declines.
- If the requested provider or model is not on the accepted list for that round, it declines.
- Otherwise, it encrypts its key against the protocol's public key and responds affirmatively.
This evaluation is designed to fail safely: any unexpected error on the miner's side results in a decline rather than a malformed or partial submission.
- 4
Stage 4 - Relay
The validator forwards each affirmative response to the protocol exactly as received, with no visibility into its contents. Responses of either kind (offer or decline) are logged for basic participation tracking; as detailed in Section 6, this record does not influence reward.
- 5
Stage 5 - Verification and custody
On receipt, the protocol performs an ordered sequence of checks: it confirms the provider and model are permitted, decrypts the submission, places a genuine test call against the provider to confirm the key is functional (rather than merely well-formed), and checks that the same key is not already active under a different hotkey. A submission that passes every check is re-encrypted under a separate storage key and retained; the temporary decrypted copy is discarded immediately. A submission that fails any check is rejected outright and never stored.
- 6
Stage 6 - Active use
An accepted key becomes available to the protocol's key pool. At present, this pool is exercised by a recurring health-check process that re-tests each active key on a schedule; this is also the current source of the usage data described below. The same pool is designed to serve future protocol-side consumers as they are introduced.
- 7
Stage 7 - Reporting
The validator periodically requests all usage activity recorded since its last check - successes, failures, average latency, and current active status - for every key it has submitted. This report is the sole input to the scoring calculation described in Section 6.
5. Timing and Cadence
Three independent schedules govern the cycle. They are not synchronized with one another, and understanding the distinction matters for interpreting observed behavior.
| Activity | Default interval | Governs |
|---|---|---|
| Key submission round | Every 4 hours | How often the validator asks miners for keys and relays them to the protocol |
| Usage report polling | Every 10 minutes | How often the validator's internal scores are updated |
| On-chain weight submission | Once per chain epoch (block-based) | How often a snapshot of scores is actually written to the chain |
Because scores can update many times between two weight submissions, only whichever score a miner holds at the precise moment an epoch triggers is the value that reaches the chain.
6. Reward Calculation
Reward weight derives from exactly one internal value maintained by the validator for each miner, and that value is written to in exactly one place: the scoring routine described below. There is no separate code path that credits a miner for participation alone, and none that penalizes a miner for declining to submit a key.
Important distinction: responding to a submission request, even successfully, does not by itself generate reward. Reward is generated only by verified, ongoing usage of a stored key, as reported by the protocol.
6.1 From a usage report to a score
For each usage report received, the validator computes a composite score from three weighted components:
- Reliability (50% weight) - the proportion of calls that succeeded.
- Latency (25% weight) - full credit at negligible latency, declining linearly to zero at a configured ceiling.
- Volume (25% weight) - credit scales with call volume up to a configured target, capped at full credit beyond that point.
This composite is then multiplied by a tier weight associated with the specific provider and model the miner last submitted, so that different offerings are not treated as equivalent by default.
Two conditions override the calculation entirely: if the report indicates the key is no longer active, the score for that report is forced to zero regardless of prior performance; if a key has accumulated too few calls in the reporting window to be statistically meaningful, it is excluded from scoring altogether for that round rather than being recorded as a zero.
The resulting score is not applied directly. It is blended with the miner's prior score using an exponential moving average, so that reward moves gradually in response to changing performance rather than reacting sharply to any single report.
6.2 From scores to a submitted weight vector
At each chain epoch, the validator takes a direct, unmodified snapshot of current scores across all miners as the basis for its weight submission - no additional blending or adjustment is applied at this stage.
A fixed proportion of the total weight is reserved unconditionally for a designated burn allocation, independent of how much verified miner activity exists. This proportion does not shrink as real usage accumulates. The remaining proportion is distributed among miners with a positive score, in proportion to that score.
If no miner has yet demonstrated verified key activity, for instance, immediately after the system is first deployed, the entire non-reserved portion falls back to the burn allocation by default. In every case, the validator still submits a complete, valid weight vector at each epoch, satisfying the underlying network's requirement that a validator never go silent.
7. Key Lifecycle
A contributed key passes through a well-defined sequence of states from submission to eventual retirement:
- Submitted - the miner transmits an encrypted key through the validator.
- Verified - the protocol decrypts and tests the key against the real provider, and checks for duplication.
- Active - an accepted key is stored, encrypted at rest, and becomes eligible for use.
- Monitored - recurring health checks and, eventually, genuine usage generate ongoing performance reports.
- Retired - once a key stops functioning (quota exhaustion, revocation, or invalidation), the next report marks it inactive; its score is forced to zero and the miner's blended score decays over subsequent rounds rather than being removed abruptly.
No key is ever specially deleted from the scoring process. A retired key simply stops generating positive reports, and its effect on reward fades through the same averaging mechanism that governs every other change in performance.
8. Data Visibility by Role
The table below summarizes what each participant is able to observe at any point in the cycle.
| Data | Miner | Validator | Protocol |
|---|---|---|---|
| Plaintext API key | Own key only | Never | Transiently, during verification |
| Encrypted key material | Produces it | Relays it | Decrypts and re-encrypts it |
| Submission attribution (which hotkey submitted what) | Own submissions only | Full visibility | Hotkey identifier only |
| Usage and performance history | No visibility | Full visibility | Source of record |
| Chain weights and metagraph state | No visibility | Full visibility | No visibility |
9. Agent Roles
The Multi-Agent Quantum Analysis Engine (Section 3) is powered by a dedicated set of specialized agents. Each one owns a single evidence source or quantum analysis stance, is a consumer of the same pooled, miner-contributed LLM keys used elsewhere in the subnet, and reports every attempt it makes back into that miner's scoring window. Each is summarized individually below.
Discord Agent
Discord Agent answers quantum analysis claims about a subnet's Discord community activity, message volume, active-member counts, channel spread, and announcement reach, using evidence it has actually collected rather than the model's own memory.
Read the full write-upChain Agent
Chain Agent runs quantum analysis on claims about the Bittensor chain, fusing ingested documents, subnet registry snapshots, and recent chain events into one retrieval layer, feeding the shared evidence pool that Convergent, Critical, and Divergent draw on.
Read the full write-upWallet Agent
Wallet Agent runs quantum analysis on claims about holder and staking behavior, stake concentration, whale movements, unstake and restake patterns, and delegation churn, drawing on a chain indexer's ledger of coldkey and hotkey balances together with analyst-labeled watchlist annotations.
Read the full write-upTwitter Agent
Twitter Agent answers claims about social attention and sentiment on X/Twitter, mention volume, engagement, account reach, and sentiment split, using normalized mention and engagement counters plus embedded text from high-engagement posts.
Read the full write-upGithub Agent
Github Agent tracks a subnet's development activity, commits, pull requests, issues, releases, and contributors, giving the quantum analysis layer a read on genuine engineering progress independent of social or market signal.
Read the full write-upDivergent Agent
Divergent Agent is one of three stance agents, alongside Convergent and Critical, that share the same pooled evidence but apply different epistemic policies to it. Divergent's job is to argue the contrarian, minority-supported reading of that evidence, provided a genuine minority case exists.
Read the full write-upConvergent Agent
Convergent Agent is seeded to argue the position the plurality of pooled evidence actually supports, giving the quantum analysis a reliably evidence-anchored voice alongside Critical's caution and Divergent's contrarianism.
Read the full write-upCritical Agent
Critical Agent refuses to settle a claim unless the pooled evidence corroborates it from at least two independent sources, catching claims that only look well-evidenced: a single loud data point dressed up as consensus.
Read the full write-up