# Testnet Phase The Testnet Phase is where Cortensor transitions from proving core inference flows into comprehensive E2E testing. Every major module - from runtime controls to validation logic - will be reviewed, iterated, and validated under real user conditions. The goals of the Testnet are: * Comprehensive regression testing across Router, Miner, Validator, Oracle, and Dashboard Indexer nodes. * Full E2E flow validation: task creation → routing → validation → payment → reputation update. * Cross-module integration checks for Cognitive, Session, Validator, Runtime. * Dashboard baselines: latency, throughput, validator sync, miner precommit stats. * Node infrastructure review: NodePool, NodeSpec, heartbeat, uptime tracking. * Code cleanup + unit testing: regression fixes and interface harmonization. * Initial gas benchmarking: identify high-cost paths in Session, Payment, and Validation. * Developer docs: REST API + on‑chain interfaces with Python/TS/JS examples. Reference:\ *** ### Testnet Strategy Cortensor uses a **dual-network testnet model** to balance short-term iteration with long-term sovereignty. #### Testnet-0 – Arbitrum Sepolia * **Purpose**: Lightweight test environment for rapid iteration. * **Infrastructure**: Shared public L2 chain (Arbitrum Sepolia). * **Cost**: Minimal infra maintenance, but higher per-transaction gas (ETH). * **Use Cases**: * Session flow validation * User task pipeline testing * Node onboarding and interaction * Staking and SessionPayment validation #### Testnet-1 – L3 Rollup (COR as Gas) * **Purpose**: Long-term AppChain testnet for scalability and sovereignty. * **Infrastructure**: L3 Rollup maintained by Cortensor with Oracle/Miner nodes and COR-native execution. * **Cost**: Monthly rollup infra cost (bridge, explorer, RPC), but near-zero per-use cost. * **Use Cases**: * App-specific chain logic and slashing * Validator feedback loops * Metadata rollup * Multi-session routing and recursive task flows * COR-based payments and economic tracking **References**:\ L3 Rollup Bridge: [https://cortensor-testnet-1-32ph80a02h-01acc12814e9cea3.testnets.rollbridge.app](https://cortensor-testnet-1-32ph80a02h-01acc12814e9cea3.testnets.rollbridge.app/)\ L3 Explorer: [https://testnet1.explorer.cortensor.network](https://testnet1.explorer.cortensor.network/) *** ### Core Modules Under Review #### Cognitive (Node Assignment) * **Cognitive (Network Task)** – validation of inference outputs per network-assigned task/session, including unsupervised network task games/rounds; purpose is to measure baseline capability and reliability of nodes. * **Cognitive Level (Node Level)** – tiered scoring for node reliability and compute power, directly tied to rewards. #### Runtime & Access Controls * **Runtime** – **dynamic, adjustable parameters** that control live network behavior (e.g., thresholds, scoring weights, routing rules). Tuned in real-time to adapt performance and governance. * **ACL (Access Control Layer)** – allowlists/denylists for network gateways. * **IAM (Identity & Access Management)** – node identity registry with roles, attributes, and access rules. #### Node Infrastructure * **Node Spec** – memory index, GPU/CPU capacity, and supported model catalog. * **Node Version** – software versioning for upgrade coordination. * **Node Utils** – helper services for node operators. * **Node Stats** – **counter-based metrics** (e.g., task completions, failures, response times) for network task performance. * **Node Reputation** – **time-series driven data** to measure reliability and consistency of nodes across tasks. * **Node Pool** – dynamic node pool management for routing and SLA classification. #### Session Layer * **Session** – base unit of inference interaction. * **Session Queue** – **time-series style tracking** for user task execution history, similar to Node Reputation but at session granularity. * **Session Auth** – **miner-to-router and peer authentication layer**, ensuring secure communication between nodes. * **Session Stats** – **telemetry and metrics for user tasks/sessions**, tracking completion, latency, and errors. * **Session Reputation** – aggregated scoring of session reliability and user-facing performance. * **Session Payment** – contract-to-contract flow for miner compensation and user billing. * **SessionQueueValidation:** Ensures task integrity and verification across the Session Queue by validating whether each queued task was processed, failed, or pending.\ Introduces TaskRoot (per-task Merkle root of miner outputs) and SessionRoot (rolling aggregate of all TaskRoots) for cryptographic proof of session history. #### Data & Storage * **Network Data** – relatively **static datasets** that the network and its modules can reference (e.g., baseline configs, role registries, default parameters). Provides a stable foundation for module behavior. * **Session Data** – session-level configuration and metadata (e.g., user parameters, model selection, runtime context). Does not include actual task inputs/outputs. * **Session Queue Data** – execution-level data tied to queued tasks, including inputs, outputs, intermediate results, and scheduling structures for task orchestration. #### **Validation Layer** The Validation Layer extends Cortensor’s core trust mechanism from simple task monitoring to semantic, quantitative, and qualitative evaluation of inference results.\ It powers the network’s transition from task completion tracking to verifiable, meaningful work scoring. * **QuantitativeStats (PoI):**\ Evaluates consistency between miner outputs by comparing **embedding vectors** and measuring **distance-based similarity**.\ Detects anomalies, outliers, and inconsistencies in inference results across multiple nodes.\ Forms the foundation for **Proof of Inference**, storing metrics over time to assess node reliability and alignment. * **QuantitativeReputation:**\ Aggregates quantitative evaluation results over time to build longitudinal reliability profiles for each node, informing reputation and routing logic. * **QualitativeStats (PoUW):**\ Uses **LLM-verifier models** to assess the *usefulness*, *semantic coherence*, and *contextual quality* of inference outputs.\ Scores results on criteria such as relevance, correctness, and task adherence.\ Implements the foundation of **Proof of Useful Work**, extending validation beyond correctness into value. * **QualitativeReputation:**\ Builds long-term profiles of node performance based on **qualitative scoring** and validator assessments, rewarding miners whose outputs consistently demonstrate high utility. Together, these modules unify quantitative reliability (PoI) and qualitative usefulness (PoUW) into Cortensor’s validator framework, ensuring all work performed in the network is both accurate and meaningful. *** ### Why Testnet Prioritizes Validation Expansion & Privacy Features The Testnet phase is where Cortensor moves beyond proving end-to-end flows and actively **implements and validates two critical components** that are essential for Mainnet readiness: 1. **Validation Expansion** – extending beyond Validator v1 by building Proof of Inference (PoI) and Proof of Useful Work (PoUW) directly into the validator logic. This shifts from prototype scoring to verifiable, system-wide enforcement of result quality. 2. **Privacy Features** – transitioning from PoC tools into production-ready three-party encryption, enabling encrypted user–miner–oracle sessions. These privacy-preserving flows will be integrated into Session and Session Queue modules and tested live. These priorities were intentionally deferred until Testnet because they require **real-world data and conditions**: * **DevNet was limited** to synthetic datasets and controlled flows, sufficient to prove inference and payments but not to validate trust and privacy guarantees. * **Testnet + hackathons produce diverse, large-scale workloads**, giving PoI/PoUW enough variation to tune thresholds, prevent gaming, and measure accuracy under live conditions. * **Privacy must be tested under load**, with real routing, latency, and session concurrency to measure the true cost and optimize for developer usability. By building and hardening these two pillars during Testnet, Cortensor ensures that what moves to Mainnet is not only functional but **trustless, verifiable, and privacy-preserving by design**—delivering on the network’s core mission. *** ### Validation Expansion Cortensor already has **Validator v1**, which focused on **node-level behavior**: monitoring network task results and upgrading/downgrading nodes based on uptime, reliability, and precommit scores. Now, Testnet expands validator logic to **user task results** and **inference quality**, through PoI and PoUW. #### Proof of Inference (PoI) * **Goal**: Verify outputs are consistent across nodes. * **Method**: Embedding/distance-based checks. * **Step**: Move from dashboard JS prototype into **Cortensord** validator path. Reference:\ #### Proof of Useful Work (PoUW) * **Goal**: Evaluate *usefulness* and *quality* of results, not just consistency. * **Method**: LLM-as-a-verifier, scoring outputs against prompts. * **Context**: Mirrors OpenAI’s prover–verifier loop in GPT-5 training. References:\ \ \ #### New Validation Modules **Quantitative (Embedding/Distance-based)** * QuantitativeStats * QuantitativeReputation **Qualitative (LLM Evaluation-based)** * QualitativeStats * QualitativeReputation **Relationships**: * Node Stats/Reputation → node reliability. * Session Stats/Reputation → session stability. * Quantitative/Qualitative modules → *user task result quality validation*. *** ### Privacy Features Cortensor has built **prototype tools** for privacy-preserving inference, using **three-party encryption** (User, Miner, Oracle). Two methods: * **Method 1 – Combined ECDH with Commitment Sharing**: Strong decentralization, extra communication. * **Method 2 – Coordinator-Based Distribution**: Simpler and faster, but temporarily centralizes key creation. Both methods are functional with tamper detection, decryption, and message authentication. References:\ \ \ **Next Steps in Testnet**: * Implement privacy-oriented **Session** & **Session Queue**. * Benchmark overhead and developer usability. * Select a default method for **SessionV3**. *** ### Continuous Enhancements & Bug Fixes In addition to the headline priorities of **Validation Expansion** and **Privacy Features**, Testnet will also serve as the proving ground for incremental improvements across **all existing modules**. These enhancements ensure the network matures steadily while new capabilities are being validated. Key areas include: * **Node Infrastructure** * Improving **Node Pools** with additional selection filters and SLA-based routing. * Extending **Node Selection** to leverage validator feedback, uptime history, and Cognitive Level scores. * Refining **Node Stats** and **Node Reputation** to surface clearer insights through counter-based and time-series data. * **Session Layer** * Enhancements to **Session Queue** (better fairness, reduced task drops, improved concurrency handling). * Polishing **Session Auth** for miner–router and peer-level communication security. * Expanding **Session Stats** and **Session Reputation** with richer telemetry and metrics. * **Data & Runtime** * Bug fixes in **Session Data** and **Session Queue Data** consistency. * Runtime parameter tuning for performance, validator thresholds, and routing logic. * Refinements to ACL and IAM to better manage node roles, permissions, and access rules. * **Developer & Operator Experience** * Dashboard UX improvements (clarity in payments, validation outcomes, and session monitoring). * SDK and API refinements for easier integration. * Documentation updates to reflect Testnet learnings and evolving best practices. ⚠️ These enhancements run **in parallel** with the major Testnet focus areas. They are critical to ensuring that by the time Cortensor reaches Mainnet, both **core stability** and **advanced modules** are production-ready. *** ### Duration * **Length**: Testnet will run for roughly **two quarters (4\~6 months)**. * **Flexibility**: It may be **shorter if stability is achieved earlier** and all edge cases and use cases are validated. *** ### Hackathons * At least **4 continuous hackathons** will be run during Testnet. * Each hackathon will: * Produce **new apps and use cases**. * Generate **diverse datasets** needed for PoI/PoUW validation. * Stress-test privacy-preserving session implementations. *** ### Moving Toward Mainnet By the end of Testnet, Cortensor will have: * **Integrated PoI/PoUW validation** in validator logic. * **Privacy-preserving sessions** operational at scale. * **Verified runtime, ACL, and IAM controls**. * **Refined data flows** for sessions, queues, and payments. * **Datasets from hackathons** to tune validation and reputation models. **Transition Strategy**: * Early flows validated on **Testnet-0** (Arbitrum Sepolia). * Long-term scalability hardened on **Testnet-1** (L3 COR Rollup). * Production begins with **Mainnet-Lite** (Arbitrum Mainnet). * Full sovereignty and composability on **Mainnet Full** (L3 COR Rollup with COR gas). | Stage | Environment | Purpose | | ---------------- | ---------------- | ------------------------------------------------ | | **Testnet-0** | Arbitrum Sepolia | Rapid iteration & early flow validation | | **Testnet-1** | L3 COR Rollup | Long-term scalability & validator feedback loops | | **Mainnet-Lite** | Arbitrum Mainnet | Production-ready flow & COR bridging | | **Mainnet-Full** | L3 COR Rollup | Full sovereignty & COR-native execution | Reference:\ --- # 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.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.