# 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:** --- # 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-4.md?ask= ``` 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.