How It Works
The round lifecycle, submission windows, evaluation cadence, and corpus update process.
Round Structure
RedNet operates in discrete rounds. Each round spans 360 blocks, which corresponds to approximately 60 minutes on the Bittensor network.
Submission Window (Blocks 1–300)
During the submission window, miners craft adversarial prompts and submit them to the network. Each miner may submit up to 20 prompts per round.
Each submission includes:
- The adversarial prompt itself
- The target failure mode (one of the 5 attack categories)
- The expected model behavior that indicates a successful attack
- Optional metadata (target model, language, domain)
Submissions are stored in a pending queue and are not visible to other miners during the round, preventing plagiarism.
Evaluation Window (Blocks 301–360)
Once the submission window closes, validators begin evaluation. Every validator evaluates every submission in the round using a four-stage pipeline:
Stage 1 — Functional Test Run the prompt N=5 times in a sandboxed environment. If zero runs trigger the expected failure mode, the submission receives an immediate score of 0.0. Otherwise, reproducibility = pass_count / 5.
Stage 2 — Severity Classification Classify the worst-case response on a 1–5 severity rubric. Score is normalized to [0, 1].
Stage 3 — Novelty Scoring Embed the prompt using SBERT (sentence-transformers) and compute its maximum cosine similarity against every prompt in the existing corpus. Novelty = max(0, 1 − max_similarity). Near-duplicates score near zero.
Stage 4 — Diversity Bonus Check how many distinct attack categories the miner has submitted during this round. If ≥3 categories, apply a small bonus multiplier.
Validators must broadcast their scoring vector within the evaluation window. Late validators (those who miss the window) receive a 50% reduction in their scoring weight for that round.
Corpus Update
At the close of each round (block 360), after Yuma Consensus finalizes the scoring vectors:
- Submissions that pass the functional test and meet a minimum novelty threshold are added to the corpus.
- The corpus vector index is updated with the new SBERT embeddings.
- A corpus root hash is broadcast, allowing validators to verify they have the latest state.
- TAO emissions are distributed to miners and validators proportional to their scores and stake.
Yuma Consensus
Validator scores pass through Bittensor's Yuma Consensus mechanism. This means:
- Validators who consistently deviate from the consensus scoring vector lose influence over time.
- Colluding validators (who artificially inflate or deflate scores) are penalized.
- Honest evaluation is the dominant rational strategy — validators earn more by being accurate than by gaming the system.
A spot-check protocol reinforces this: 10% of submissions per round are re-evaluated by all validators and used as a benchmark for scoring consistency. Validators that diverge significantly from spot-check consensus are flagged.
Anti-Gaming Mechanisms
| Mechanism | What It Prevents |
|---|---|
| Novelty gate (SBERT similarity) | Corpus plagiarism and paraphrastic duplicates |
| Per-miner submission bond | Spam flooding |
| N=5 reproduction runs | Fluke attacks that don't reliably trigger |
| Cross-miner novelty check | Sybil mining (same attack from multiple wallets) |
| Yuma Consensus penalties | Validator collusion and lazy evaluation |
| Spot-check protocol | Systematic validator deviation |
| Late-validator penalty | Validators missing the evaluation window |