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 (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.
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.
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:
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.
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.
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.
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