Testnet Phase (WIP/Draft)
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:
Deeper E2E testing of inference, validation, and payments.
Comprehensive code and module review for long-term maintainability.
Scaling trust features: Proof of Inference (PoI), Proof of Useful Work (PoUW), and privacy-preserving sessions.
Rich data collection from hackathons and real apps to validate scoring and reputation models.
Reference: https://docs.cortensor.network/technical-architecture/testnet-and-mainnet-strategy
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 L3 Explorer: https://testnet1.explorer.cortensor.network
Core Modules Under Review
Cognitive & Validation
Cognitive (Network Task) – validation of inference outputs per network task/session.
Cognitive Level (Node Level) – tiered scoring for node reliability, tied directly to rewards.
Validation Logic Extensions (PoI / PoUW) – embedding-based validation + verifier-based LLM scoring integrated into validator logic.
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.
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 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.
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: https://x.com/cortensor/status/1952838536690073644 https://x.com/rohanpaul_ai/status/1951400750187209181 https://docs.cortensor.network/technical-architecture/consensus-and-validation/proof-of-useful-work-pouw
New Validation Modules
Quantitative (Embedding/Distance-based)
QuantitativeStats
QuantitativeReputation
QuantitativeMetrics
Qualitative (LLM Evaluation-based)
QualitativeStats
QualitativeReputation
QualitativeMetrics
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: https://docs.cortensor.network/technical-architecture/security-and-privacy/privacy-features-three-party-encryption https://x.com/cortensor/status/1961173676919042383 https://x.com/cortensor/status/1960902776407646629
Next Steps in Testnet:
Implement privacy-oriented Session & Session Queue.
Benchmark overhead and developer usability.
Select a default method for SessionV3.
Why Testnet
The two highest-priority components for Testnet are:
Validation Expansion – scaling beyond Validator v1 into PoI and PoUW result validation.
Privacy Features – implementing and benchmarking encryption methods across live sessions.
Why now?
DevNet phases had limited synthetic data from user.
Testnet + hackathons provide large-scale, diverse data to validate both inference quality and privacy features.
These features are core to Cortensor’s mission: inference that is verifiable and privacy-preserving by design.
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).
Reference: https://docs.cortensor.network/technical-architecture/testnet-and-mainnet-strategy
Last updated