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
Last updated