Question 1

How are miners rewarded for contributing LLM keys?

Accepted Answer

Miners are rewarded based on an efficiency score that blends four signals from real usage reports: success rate (calls that succeeded vs. failed), response latency (clamped at a ceiling), output quality (self-graded by the calling agent on each call), and call volume (capped at a target). The composite score is multiplied by a tier weight for the specific LLM model configured. Scores are folded into a per-miner exponential moving average, so sustained performance accumulates over time. A key that fails hard-floor thresholds or is marked inactive by the protocol immediately scores zero.

Question 2

What happens if a miner's LLM key stops working?

Accepted Answer

Once the protocol backend reports that a key is inactive, revoked, or exhausted, the validator immediately cuts that key's earnings to zero. If a single miner has multiple keys and only one dies, the miner's other healthy keys keep earning their share. Only when a miner's last live key dies does the miner's overall score hard-zero. If reports simply go stale with no confirmation of a bad key, the score decays gradually over a timeout period.

Question 3

Can a miner contribute multiple LLM API keys at once?

Accepted Answer

Yes. Miners can configure between 5 and 5 distinct LLM API keys (provider/model pairs) per submission. Each key is encrypted client-side and relayed as an opaque ciphertext. The validator separately polls usage reports, which are tagged with which key served each call, and scores all live keys together in a pooled efficiency window. A miner must submit at least 5 keys to avoid declining the round entirely — partial batches are not relayed.

Question 4

How does the validator prevent miners from exposing their raw API keys?

Accepted Answer

Miners encrypt each LLM API key using NaCl SealedBox with the protocol's published public key before it ever leaves the miner process. The validator relays only the opaque ciphertext blob and never holds a private key to decrypt it. This is a structural guarantee, not a policy. The protocol decrypts the transport ciphertext on arrival, then re-encrypts the key for storage using a completely separate at-rest encryption key.

Question 5

What is the minimum compute required to run a miner or validator?

Accepted Answer

Both roles are I/O-bound (HTTP calls and lightweight NaCl encryption), not compute-bound. No GPU is required. Minimum: 2 CPU cores at 2.0 GHz, 2 GB RAM, 2 GB swap, 5 GB SSD storage. Recommended: 4 cores at 2.5 GHz, 4 GB RAM, 4 GB swap, 10+ GB SSD. Network: 20 Mbps download, 10 Mbps upload (for HTTP to the protocol backend).

TAOstatus

TAOstatus

Hardware Requirements

Hardware Requirements

Miner Setup

Validator Setup

Participate

Participate

Hardware Requirements

Hardware Requirements

Miner Setup

Validator Setup