# Testnet Phase #3

Phase #3 advances Cortensor from “trust-layer hardening” into economic + agentic hardening — finalizing payments, staking utility, and reward automation, while continuing router iteration so agents can reliably delegate, validate, and reach consensus on results.

Building on Phase #2’s stable baseline, self-managed L3 traction, and expanded router surfaces, Phase #3 treats Testnet-0 + Testnet-1a as the primary proving grounds — with pre-mainnet environments used for mainnet-identical dry runs.

***

### Phase #3 — Payments, Staking Utility & Incentive Mechanics

*(Privacy & data mobility: optional / staged but strongly tested.)*

Timeline: End Q1 → Early/Mid Q2 2026\
Goal: Finalize economic flows and automate incentives while pushing agent-ready router surfaces.\
Focus: Sustainability, pricing correctness, incentive fairness, and real-world data movement under load.

***

### Contest Rules

#### Stake Requirement

* All participants must stake 10,000 $COR per node (Pool 3) to qualify for Testnet Phase #3.
* 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 payment-aware sessions (`SessionPayment` metadata + fee attribution) without breaking telemetry.
* Run nodes capable of handling redundant workflows (multi-run / multi-miner consensus requirements).
* Ensure correct registration + telemetry sync in the primary environments:
  * Testnet-0 (Arbitrum Sepolia)
  * Testnet-1a (Self-managed COR L3)

#### Participation & Reporting

Participants are expected to:

* Report anomalies in payments, quotas, rewards, and routing behavior — not just inference/validation bugs.
* Help validate staking-to-use accounting and NodeReward automation under real network traffic.
* Share structured logs + findings through Discord reporting channels.

#### Disqualification Criteria

Cortensor reserves the right to disqualify any operator for:

* Misreporting uptime or falsifying telemetry data.
* Exploiting staking, rewards, routing, or payment mechanisms.
* Any conduct or manipulation that undermines fairness, sustainability, or network stability.

***

### Rewards

* Rewards follow the same structure as Phase #2, unless explicitly updated in the Phase #3 announcement.
* Phase #3 emphasis shifts toward:
  * automating reward computation, and
  * validating the parameters used for level-based rewards and capacity signals (see Testing Focus).

***

### Testing Focus

#### 1) Payment Flow Refinement (SessionPayment “Production Shape”)

Phase #3 makes payments robust enough to scale:

* Tune unit costs, rebates, and surcharge parameters.
* Expand `SessionPayment` metadata for pricing transparency:
  * execution depth / validator depth
  * redundancy profile (miners, consensus method, threshold)
  * model class + route hints
* Improve gas tracking and cost attribution (per session / per route / per validation path).
* Validate fee correctness under real traffic:
  * predictable totals
  * stable accounting
  * clean failure handling.

***

#### 2) Dynamic Pricing Activation (SLA / Depth / Redundancy Aware)

Turn the pricing scaffolding into live economics:

* Activate `SessionPaymentTable` with richer inputs:
  * SLA tier / reliability tier
  * model class (light vs heavy)
  * execution depth / tool depth
  * validator depth
  * redundancy level + consensus requirements.
* Validate pricing is consistent, manipulation-resistant, and understandable.

***

#### 3) Staking-to-Use (Stake Utility → Quotas → Auto-Deduction)

Primary economics feature for Phase #3:

* Extend `SessionPayment` to support stake-based free inference quotas.
* Enable auto-deduction from user stake balances for paid overages.
* Define quota accounting + guardrails:
  * refresh cadence (daily / weekly)
  * usage buckets (by model class / redundancy)
  * abuse prevention (rate limits / per-address caps).

***

#### 4) Node Reward Automation + Level Parameter Tuning

*(Model Count as Capacity Signal)*

Phase #3 moves rewards toward a predictable, automated system:

* Implement automated reward computation linked to:
  * Node Level / `NodeReputation`
  * validator feedback (agreement rate, consistency, failure behavior)
  * supporting signals: throughput + uptime.
* Shift “fairness” tuning to level reward parameter adjustments driven by capacity signals:
  * reward parameters incorporate model count / routing breadth (how many models a node supports).
  * ensure incentives reflect useful coverage + reliability, not just raw hardware advantage.
  * prevent dominance by a narrow set of high-end configs by rewarding breadth + consistency.
* Automate reward computation + payout pipeline to reduce manual ops overhead.

***

#### 5) Router Surfaces (v3/v4) + Consensus/Redundancy Attributes (Agent-Ready)

Phase #3 pushes router endpoints closer to agent primitives:

* Iterate on `/delegate` and `/validate` toward router v3:
  * richer policy hints (budget/risk/latency)
  * structured outputs + tool traces
  * retries/fallbacks under partial failure.
* Add explicit redundancy + consensus attributes in requests:
  * number of miners / sessions
  * aggregation method (`majority`, future `weighted`, `median`, etc.)
  * agreement thresholds
  * disagreement/arbitration rules.
* Apply the same consensus model to factcheck and any new endpoints required by agent workflows.

(These features lay the groundwork for router v4: programmable trust + reusable validation artifacts.)

***

#### 6) PyClaw – Router-Aligned Agent Runtime (Design & Validation)

PyClaw is a separate product layer on top of Cortensor — a local-first agent runtime aligned with router/session primitives:

* Continue early PyClaw design so it lines up with:
  * `/completion`, `/delegate`, `/validate`, and `factcheck` surfaces.
  * session IDs, routing policies, redundancy attributes, and validation contracts.
* Local-first design goals:
  * a control plane (CLI/chat/voice adapters) that routes commands to the right agent/session and keeps a global audit log.
  * a state-machine brain loop:\
    `interpret → plan → policy-gate → act → observe → reflect → improve`.
  * tools + memory + strict context compaction for safety and efficiency.
* Scaling intent:
  * start as single-host daemon; keep contracts ready for multi-agent / remote workers later.
* Phase #3 emphasis is design + validation, so Phase #4 can begin deeper implementation work.

***

#### 7) Bardiel Dashboard Iterations + Regular Test Jobs

Make router experimentation visible and repeatable:

* Iterate Bardiel dashboard views for delegation/validation:
  * policy tiers, risk settings, verdict traces, consensus metadata.
* Set up regular scheduled test jobs (smoke + regression) so the dashboard always has live examples.
* Ensure the UX reflects v3 router schema changes without breaking existing views.

***

#### 8) Pre-Mainnet Experiments (Mainnet-Identical Setup)

Phase #3 introduces realistic “go-live” dry runs:

* Use pre-mainnet environments designed to be apple-to-apple with mainnet config.
* Validate:
  * real ops + reliability expectations
  * cost mechanics (RPC / sequencer / validator costs where applicable)
  * payment + staking + reward flows under realistic conditions
  * agent-facing router behaviors with mainnet-like constraints.

***

#### 9) Self-Managed L3 as Primary Track

*(Ops Hardening + Runbooks)*

Phase #3 treats Testnet-1a (self-managed COR L3) as the forward path:

* Continue L3 ops hardening with existing playbooks:
  * backups, snapshots, disk-space estimates
  * recovery-oriented runbooks and restart procedures.
* Validate that ops procedures actually work under incidents, not just on paper.

***

#### 10) ERC-8004 Agent Presence + Router MCP/Prototype Stack

Build on Phase #2’s ERC-8004 registrations:

* Exercise Corgent + Bardiel in real workflows backed by the Router Node MCP/prototype stack.
* Validate registry presence isn’t “just a listing”:
  * run practical delegation/validation flows.
  * verify reliability + cost behavior.
  * attempt pre-mainnet runs if environments are ready.

***

#### 11) Gas Profiling Iteration (Economics + Optional Privacy)

* Measure gas after payment / staking / reward changes.
* Compare against Phase #2 baseline.
* Continue trimming:
  * storage writes
  * log spam
  * unnecessary on-chain calls.

***

#### 12) Privacy-Preserving Sessions (Optional / Staged)

Privacy stays opt-in until stable and cost-acceptable:

* Implement V0 encryption for dedicated-node sessions:
  * router-issued, scope-bound `payload_enc_key` (session / session+task).
  * env-based allowlist (`ENCRYPTION_ALLOWED_LIST`) controlling who may fetch keys.
  * deterministic keys derived from a secret `ENCRYPTION_SEED` + scope.
* Prepare V1 design for ephemeral/node-pool sessions using:
  * dynamic policy storage (router data module / contract), not only env.
* Benchmark latency / failure modes and keep privacy optional until overhead is understood.

(See: `Private / Encrypted Inference` docs for full design details.)

***

#### 13) Data Mobility & Large Dataset Stress Tests

Re-introduce data mobility as a first-class test axis, focused on large datasets:

* Design data-mobility workloads that:
  * move or stream large artifacts across miners and storage layers (local CAS, IPFS, future Stratos/Filecoin or similar).
  * simulate realistic workloads: multi-GB logs, embeddings, checkpoints, or multi-part documents.
* Stress-test:
  * router + session behavior when tasks operate on large artifacts.
  * artifact ingestion, fetch, and eviction behavior under load.
  * bandwidth and latency impacts when many nodes fetch the same large dataset.
* Validate:
  * that artifact references remain stable even as data moves or is re-chunked.
  * that node operators can handle high I/O + storage churn without crashing router or miner processes.
  * that future data-management roadmap (IPFS / L3-aware storage / off-chain backends) stays compatible with:
    * `SessionPayment` accounting
    * rewards (proof that data-heavy work was actually done)
    * privacy constraints where applicable.

These tests ensure Cortensor is ready for data-heavy AI workloads, not just small text-only inference.

***

### Key Outcomes

By the end of Phase #3, Cortensor should achieve:

* Payments that are transparent, tunable, and resilient under real traffic.
* Stake-to-use quotas working end-to-end with auto-deduction and abuse guardrails.
* Automated rewards with tuned level parameters using model-count + routing breadth as capacity signals.
* Router endpoints closer to agent primitives, supporting explicit redundancy + consensus attributes.
* PyClaw design validated as a router-aligned agent runtime layer (foundation for Phase #4 implementation).
* A repeatable testing loop via Bardiel dashboard + scheduled test jobs.
* Pre-mainnet environments validated as mainnet-identical dry-run platforms.
* Continued confidence in the self-managed L3 ops path via playbooks + incident-ready runbooks.
* Expanded real-world use of ERC-8004 agents (Corgent + Bardiel) backed by Router MCP/prototype stack.
* Proven handling of data mobility and large dataset workloads, feeding into long-term data-management roadmap.

***

### Outcome Statement

Testnet Phase #3 is where Cortensor becomes a real economic network:

* Phase #2 hardened trust.
* Phase #3 makes execution payable, stake-usable, data-heavy capable, and incentivized fairly, while pushing the router toward agent-ready delegation, validation, consensus, and data mobility under mainnet-like conditions.

Join Cortensor Discord: <https://discord.gg/cortensor>