> For the complete documentation index, see [llms.txt](https://docs.cortensor.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cortensor.network/community-and-ecosystem/community-testing/testnet-phase-4.md).

# Testnet Phase #4

Phase #4 turns Phase #3’s foundation into a more **production-shaped pipeline** — locking the full end-to-end scope, deepening stress testing, and starting real implementation work on **Portal V1** as the product layer on top of Cortensor.\
\
This phase treats **data management → inference quality → routing behavior → payments/quotas** as one connected system, while also preparing **Mainnet Lite infra** so execution is not blocked later.

***

### Phase 4 — E2E Hardening, Stress Tests & Portal V1 Productization

**Timeline:** Early Q2 → Mid Q2 2026\
**Goal:** Lock an end-to-end test plan, validate reliability under stress, and begin Portal V1 implementation as a real product boundary.\
**Focus:** End-to-end stability, stress-tested quality paths, and production-ready product surfaces.

***

### Contest Rules

#### Stake Requirement

* All participants must stake **10,000 $COR per node (Pool 3)** to qualify for Testnet Phase #4.
* 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 **higher sustained throughput** and longer-running stress tests.
* Handle **data-management + offchain flows** (where enabled) without breaking telemetry.
* Ensure correct registration + telemetry sync in the primary environments used for Phase #4 testing:
  * **Testnet-0 (Arbitrum Sepolia)**
  * **Testnet-1a (Self-managed COR L3)**

#### Participation & Reporting

Participants are expected to:

* Report end-to-end failures (pipeline breaks), not just single-module bugs.
* Help validate stress test results: latency spikes, failure modes, recovery behavior, and data integrity.
* Provide structured logs + feedback via Discord reporting channels.

#### Disqualification Criteria

Cortensor reserves the right to disqualify any operator for:

* Misreporting uptime or falsifying telemetry data.
* Exploiting rewards, routing, or load-test mechanics.
* Any conduct or manipulation that undermines testing fairness or network stability.

***

### Rewards

* Rewards follow the **same structure as Phase #3**, unless explicitly updated in the Phase #4 announcement.
* Phase #4 emphasis is less about new incentive mechanics and more about **E2E reliability and production readiness**.

***

### Testing Focus

#### 1) E2E Scope Lock (Phase #3 → Phase #4)

Phase #4 starts by locking the full end-to-end plan based on what Phase #3 surfaced:

* Finalize the **full E2E test plan** (what we test, in what order, and how we measure success).
* Treat **data management → inference quality → routing behavior** as one connected pipeline, not isolated modules.
* Define clear pass/fail metrics for:
  * throughput + latency baselines
  * error classes and recovery time
  * scoring drift and consensus stability
  * data integrity + offchain correctness (when enabled)

#### 2) Deeper Stress Testing (Data → Quality Path)

Plan heavier load tests across the “data to quality” path:

* Run longer-duration, higher-volume tests that intentionally hit failure conditions:
  * miner churn, partial outages, RPC degradation, queue spikes
* Validate reliability under sustained throughput and real failure/retry patterns.
* Focus on stability of:
  * routing behavior under load
  * validator throughput and queue health
  * aggregation/consensus correctness under disagreement

#### 3) Privacy + Offchain Storage Stress Tests (Optional / Heavier)

Privacy can be treated as an optional lane, but Phase #4 stress tests it more directly where enabled:

* Plan heavier load tests across:
  * privacy flows (three-party encryption paths)
  * offchain storage (inputs/outputs, result URNs, retrieval correctness)
  * data-management edge cases (timeouts, retries, stale keys, partial writes)
* Goal: validate privacy/offchain overhead and failure handling under real throughput.

#### 4) SLA / Quality Signals – Deeper Validation (#3 Signals)

Phase #4 continues evolving SLA-driven behavior:

* Stress test SLA / quality signals under load and churn:
  * scoring drift detection
  * reliability weighting vs raw uptime
  * consensus disagreement rate + arbitration behavior
* Validate that SLA signals remain usable at scale (not just in clean conditions).

#### 5) Portal V1 (Design → Early Implementation) + Backend Product Boundary

Portal V1 becomes a core Phase #4 track as a real product layer:

* Implement Portal V1 surfaces in parallel with planning so it does not remain “just docs”.
* Define the product boundary clearly:
  * customer app → Portal backend → router pool → sessions
* Core Portal goals:
  * **API keys** issuance and management
  * **usage visibility** (requests, spend, quotas)
  * **managed router pools** (customers don’t touch raw routers)
* Plan backend business logic early so implementation stays clean:
  * auth strategy + organization/user mapping
  * gateway verification (key validation, quotas, rate limits)
  * request normalization and response normalization
  * billing hooks + usage event emission/metering
* Keep separation of concerns crisp:
  * Portal owns product logic
  * Router owns execution + routing primitives
  * Sessions remain the decentralized execution contract

#### 6) PyClaw (Early Dev Release Track)

PyClaw becomes a more concrete track in Phase #4 — moving from “design only” into an **early development release**:

* Ship the initial public-facing layer:
  * **landing page**
  * initial **docs / structure**
* Begin early implementation iteration aligned with router/session primitives:
  * local-first runtime scaffolding
  * minimal agent loop + audit trail foundation
  * clear mapping to router surfaces (completion/delegate/validate/factcheck)
* Goal: make PyClaw tangible and testable as a product layer on top of Cortensor, while keeping scope controlled.

#### 7) Mainnet Lite Infra Planning (Execution Readiness)

Prepare Mainnet Lite infra so Phase #4 doesn’t end as “just testing”:

* Plan Mainnet Lite-related infra:
  * servers, RPC, monitoring, alerting, ops
* Evaluate redundancy, performance, and cost tradeoffs before execution.
* Validate runbooks and operational posture under realistic failure scenarios.

***

### Key Outcomes

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

* A locked **end-to-end test plan** with clear success metrics.
* Stress-tested stability across the connected pipeline:
  * data management → quality → routing behavior
* Stronger confidence in privacy/offchain lanes (where enabled) under load.
* Portal V1 moved from “design only” into **early implementation**, with product boundary clearly defined.
* PyClaw moved into an **early dev release** state (landing page + docs + initial implementation scaffolding).
* Mainnet Lite infra planning mature enough to execute without major blockers.

***

### Outcome Statement

Testnet Phase #4 is about turning the Phase #3 foundation into a **production-shaped pipeline** — stronger end-to-end reliability, stress-tested quality paths, a real Portal V1 product surface, and infrastructure planning that can scale into Mainnet Lite.

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