# SessionQueueValidation: TaskRoot & SessionRoot for ERC-8004 Compatibility (Draft)

**Status:** Conceptual Design Phase\
**Related Modules:** `SessionQueue`, `Validator`, `QuantitativeStats`, `QualitativeStats`\
**Reference:** <https://x.com/cortensor/status/1974765387339473150>

***

### **Overview**

The **SessionQueueValidation** module is being extended to introduce **TaskRoot** and **SessionRoot** structures — a cryptographic framework for tracking verifiable task completion and continuous session evolution.\
This design aims to make Cortensor’s **inference validation** interoperable with **ERC-8004’s Validation Registry**, enabling standardized proof exchange across agent and compute networks.

Cortensor sessions are continuous and open-ended.\
Each **task** executed within a session becomes an **atomic proof unit**, while the session itself evolves as a **rolling ledger of trust**.

***

### **Conceptual Design**

#### **TaskRoot (Sealed Proof)**

* Each task request within a session is executed by multiple miners.
* Their outputs are hashed, verified, and aggregated into a **Merkle root (TaskRoot)** that cryptographically commits to all miner results for that task.
* Once sealed, a TaskRoot serves as an immutable proof artifact — representing one verifiable checkpoint of inference.

**Purpose:**\
Provides tamper-evident validation for a single task execution.\
Used by validators for replay verification (e.g., **Proof of Inference (PoI)** or **Proof of Useful Work (PoUW)**).

***

#### **SessionRoot (Rolling Ledger)**

* As each TaskRoot is sealed, it is appended to a **rolling Merkle accumulator** called the **SessionRoot**.
* The SessionRoot evolves as new tasks are completed, forming a cumulative state that represents all verified tasks under one session.
* This enables perpetual sessions without closure after each task, maintaining continuity for long-lived agent or application processes.

**Purpose:**\
Maintains a verifiable, cumulative record of all TaskRoots under a given session.\
Acts as a **living commitment** to the full session history.

***

### **Proposed ERC-8004 Mapping**

The design aligns Cortensor’s validation structure with **ERC-8004’s trust fabric**, allowing Cortensor sessions to function as verifiable agent servers under the ERC-8004 model.

| **ERC-8004 Field** | **Cortensor Equivalent** | **Description**                                                                                                          |
| ------------------ | ------------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| `AgentServerID`    | `SessionID`              | Represents the aggregated “agent server.” Abstracts miner identities internally but exposes a unified external identity. |
| `AgentValidatorID` | `Validator / Oracle`     | Executes PoI / PoUW checks and records ValidationResponse events to the ERC-8004 Validation Registry.                    |
| `DataHash`         | `TaskRoot / SessionRoot` | Cryptographic commitment referencing either a single verified task or the cumulative session state.                      |

**Key Relationship:**

* **TaskRoot** → atomic proof of a single inference.
* **SessionRoot** → rolling ledger of all inferences under a session.\
  Together, these structures enable **cross-network trust interoperability** — allowing Cortensor proofs to be read, verified, or referenced by external ERC-8004 registries.

***

### **Internal Data Model**

Each **TaskRoot** is derived from a canonical hashing schema that records the full provenance of a task:

```
(taskID, minerID, modelID, inputHash, outputHash, metadata)
```

**Fields:**

* **taskID:** Unique identifier of the inference task.
* **minerID:** Node(s) performing the work.
* **modelID:** Model or architecture used for inference.
* **inputHash:** Cryptographic hash of the input (prompt, configuration).
* **outputHash:** Hash of the generated output tensor or result.
* **metadata:** Optional contextual data (timestamps, environment info, scoring).

Merkle leaves are constructed from this structure.\
The resulting **TaskRoot** becomes a deterministic commitment to all miner outputs, verifiable by validators or external auditors.

***

### **Validator Interaction**

#### **1. ValidationRequest**

Validators initiate verification using a `DataHash` (TaskRoot or SessionRoot) to request validation of a given inference.

#### **2. Verification Process**

Validators perform:

* **Proof of Inference (PoI):** embedding-distance checks for result consistency.
* **Proof of Useful Work (PoUW):** LLM-based evaluations of result quality and utility.

#### **3. ValidationResponse**

Upon completion, validators submit **ValidationResponse** entries into the **ERC-8004 Validation Registry**, anchoring Cortensor proofs on a common trust layer for transparent, interoperable validation.

***

### **Why It Matters**

* **Reproducibility:** Every inference becomes a sealed, replayable proof unit.
* **Continuity:** SessionRoot preserves long-running, evolving workloads.
* **Interoperability:** Bridges Cortensor’s decentralized validation with ERC-8004’s standardized trust registries.
* **Transparency:** Enables external audits, proof replay, and cross-network reputation scoring.

Together, **TaskRoot** and **SessionRoot** form a unified framework for **verifiable, evolving, and auditable inference**, anchoring decentralized AI execution in a shared validation ecosystem.

***

### **Next Steps**

1. Prototype canonical hashing schema `(taskID, minerID, modelID, inputHash, outputHash, metadata)` for Merkle generation.
2. Integrate **ValidationRequest / ValidationResponse** into Cortensor’s PoI loop.
3. Map **SessionID / ValidatorID** to ERC-8004 Identity Registry for agent reputation linkage.
4. Simulate **rolling SessionRoot updates** and test replay validation.
5. Benchmark **multi-validator performance and gas costs** for potential cross-chain anchoring.

***

### **Architecture Flow**

```
┌───────────────────────────────┐
│      Task Execution (Miners)  │
└──────────────┬────────────────┘
               │
               ▼
      Hash inputs/outputs → Build Merkle leaves
               │
               ▼
       TaskRoot (sealed proof per task)
               │
               ▼
   SessionRoot (rolling ledger of all TaskRoots)
               │
               ▼
     Validator performs PoI / PoUW verification
               │
               ▼
   ValidationResponse → ERC-8004 Validation Registry
```

**Flow Summary:**\
Each task produces a **TaskRoot** as a sealed proof.\
The **SessionRoot** continuously aggregates all TaskRoots, forming a rolling ledger of trust.\
Validators then verify and anchor these proofs into **ERC-8004’s on-chain Validation Registry**, connecting Cortensor’s decentralized execution fabric with the emerging agent trust fabric.