# Testnet Phase #2

Phase #2 advances Cortensor from “system-wide regression” into **trust-layer hardening** — tightening validator logic, expanding redundancy, and beginning **formal gas + runtime optimization**.\
Building on Testnet Phase #1’s end-to-end stability baselines, this phase focuses on making validation **more accurate, more resilient, and cheaper to operate** at scale across both **Testnet-0 (Arbitrum Sepolia)** and **Testnet-1 (L3 COR Rollup)**.

***

### Phase 2 — Validation Refinement & Infrastructure Hardening

**Timeline:** Early Q1 → Mid Q1 2026\
**Goal:** Strengthen validator logic, expand redundancy, and begin formal gas optimization.\
**Focus:** Accuracy, trust stability, and infrastructure robustness.

***

### Contest Rules

#### Stake Requirement

* All participants must stake **10,000 $COR per node (Pool 3)** to qualify for Testnet Phase #2.
* Nodes must remain staked and active throughout the testing window to receive rewards.

#### Node Uptime & Performance

Operators must:

* Maintain **continuous uptime** and responsiveness to assigned sessions.
* Support **redundant validation flows** (more multi-run / multi-miner validation paths).
* Handle **higher validator throughput**, including scoring + reporting without bottlenecks.
* Ensure correct registration + telemetry sync across both **Testnet-0** and **Testnet-1** when participating in both.

#### Participation & Reporting

Participants are expected to:

* Report bugs, validator anomalies, scoring drift, or reliability issues.
* Help validate improvements to **Validator v2/v3**, redundancy policies, and router reliability.
* Share structured logs + findings through Discord reporting channels.

#### Disqualification Criteria

Cortensor reserves the right to disqualify any operator for:

* Misreporting uptime or falsifying telemetry data.
* Exploiting reward, routing, or validation mechanisms.
* Any manipulation that undermines fairness, accuracy, or network stability.

***

### Rewards

**Base Reward**

* Base rewards is $20 per node.
* Qualification Requirements:
  * Active uptime during the entire test window
  * **Precommit Score ≥ 60 %**
  * **Node Level Success Rate**

**Role-Based Bonus**

* **+1 % per verified Discord role** (capped at 10 %).

**Node Level Bonus**

* Level-based bonus scales linearly (**+$0.80 per level**, 0–10):
  * Level 0 = $0 → Level 10 = $5 extra per node per month.

**Performance Prize**

* Additional $5 bonus for nodes meeting both:
  * **Total Score ≥ 50 %**
  * **Precommit Score ≥ 60 %**
  * Leaderboard → [View Testnet #0 Dashboard](https://dashboard-testnet0.cortensor.network/)
  * Leaderboard -> [View Testnet #1 Dashboard](https://dashboard-testnet1.cortensor.network/)

**Multi-Node Bonus (New Ops Only)**

* 3 + nodes → +10 % bonus
* 5 + nodes → +20 % bonus

***

### Testing Focus

#### 1) Validator v2/v3 Refinement (PoI + PoUW)

Phase #2 is centered on tightening trust calibration and reducing scoring drift:

* **Deep PoI (quantitative)** validation refinement: improve numerical consistency, dispersion bounds, and convergence under redundancy.
* **Deep PoUW (qualitative)** validation refinement: strengthen rubric adherence (accuracy, relevance, completeness, clarity, safety) and reduce judge variance.
* Improve validator determinism under real load: fewer “flaky” outcomes, better repeatability, clearer failure modes.

#### 2) Validator Engine Experiments: Ollama Models + Embedding Variants

We will explicitly experiment with **Ollama-based model stacks on validator nodes** to improve hardware compatibility and verification quality:

* Validate **Ollama model variants** as LLM-verifier options (judge models / verifier models), comparing stability, latency, and scoring consistency.
* Test **multiple embedding model variants** to address known issues where certain validator GPU setups produce inconsistent/unsupported embedding behavior with the current engine.
* Target outcome: **better hardware adaptation on validator nodes**, fewer environment-specific failures, and more predictable validator throughput.

#### 3) QuantitativeStats / QualitativeStats Expansion

To tune thresholds and reduce false positives/negatives:

* Expand datasets for calibration of **PoI thresholds** and **PoUW scoring**.
* Improve LLM-verifier scoring alignment across task domains (general QA, code, reasoning, extraction, etc.).
* Track distributions over time to detect drift, regressions, and “boundary-case” instability.

#### 4) Redundancy Expansion & Trust Stability

Strengthen reliability through broader redundancy policies:

* Increase multi-run / multi-miner redundancy where needed.
* Validate aggregation logic (median/majority/weighted) and ensure it behaves correctly under partial failures.
* Measure trust stability: score variance, disagreement rate, and disagreement handling behavior.

#### 5) Router Surface Experiments: `/delegate` + `/validate`

Phase #2 expands structured testing of the router’s agent-facing surfaces:

* `/delegate` experimentation:
  * Policy-driven delegation (cost/risk hints), routing behavior, retries, and fallbacks
  * Multi-run delegation and “same task, different miners/models” variance testing
  * Response structure stability for downstream agent consumption
* `/validate` experimentation:
  * Validator tier selection, scoring stability under different verifier policies
  * Regression testing across domains and edge cases (hallucination, partial answers, ambiguous prompts)
  * Throughput/latency profiling for validation-heavy workloads

#### 6) Oracle & Internal Service Reliability

Harden the supporting pipeline that feeds validation and observability:

* Router APIs and internal services reliability under sustained load.
* Indexer consistency + freshness, including recovery from missed blocks/events.
* Dashboard feed integrity (no stale/partial views, accurate merging across networks).

#### 7) Infrastructure Redundancy: RPC, Failover, Backups

Make “survives failures” a first-class requirement:

* Multiple RPC endpoints per network + automatic failover behavior.
* Validator backups / fallback paths to prevent single points of failure.
* Validate ops playbooks: restart recovery, resync behavior, and degraded-mode handling.

#### 8) Gas Optimization & Runtime Tuning (Formal Start)

Begin structured profiling and cost reduction:

* Profile **Cortensord** runtime parameters and on-chain execution paths.
* Optimize key L2 contracts/modules:
  * **SessionQueueValidation**
  * **SessionPayment**
  * **Validator** storage layout
* Reduce unnecessary log events and nested calls to minimize gas and execution overhead.

#### 9) Dashboard Expansion: Trust Observability

Expand instrumentation so Phase #2 improvements are measurable:

* Real-time **PoI / PoUW analytics**
* Validator health views (availability, queue latency, drift indicators)
* Endpoint health indicators (RPC/indexer/router feed status) and alert-style visibility

#### 10) L3 Rollup Comparison: Self-Managed vs RaaS (Apple-to-Apple)

A dedicated Phase #2 focus to validate tradeoffs before scaling Testnet-1:

* Benchmark **Testnet-1a (self-managed L3)** vs **Testnet-1 (RaaS L3)** under the same workload and validation requirements.
* Measure:
  * Indexer/validator freshness under load
  * RPC reliability + failover behavior
  * Throughput/latency + telemetry completeness
  * Operational overhead and where cost/runtime tuning matters most
* Goal: a data-backed decision on which L3 approach best supports Testnet → Mainnet progression.

#### 11) Light MCP Integration: Component Assignment Experiments (Nice To Have)

Phase #2 includes early “agent-ready wiring” work via light MCP integration:

* Experiment with **MCP component assignment** (mapping tasks to tools/components cleanly)
* Validate minimal MCP compatibility for task execution + validation loops (without over-scoping full protocol rollout)
* Goal: prove the router can begin acting as an **agent execution surface** where tools/components are assigned deterministically and observed end-to-end.

***

### Key Outcomes

By the end of Phase #2, Cortensor should achieve:

* **Higher-accuracy validation** with more stable PoI/PoUW scoring.
* **Expanded redundancy** with measurable trust improvement and lower variance.
* **Infrastructure robustness** via failover, backups, and reduced service fragility.
* **Early gas + runtime optimizations** reducing cost and execution overhead on L2.
* A **fully instrumented trust layer**, observable in real time through dashboard analytics.

***

### Outcome Statement

Testnet Phase #2 is about making Cortensor’s trust layer **redundant, cost-efficient, and fully observable** — a foundation where validation isn’t just “working,” but **stable under load, resilient under failure, and optimized for scale**.

**Join Cortensor Discord:** <https://discord.gg/cortensor>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.cortensor.network/community-and-ecosystem/community-testing/testnet-phase-2.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.