> For the complete documentation index, see [llms.txt](https://docs.bardiel.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bardiel.tech/core-concepts/bardiel-and-cortensor-router.md).

# Bardiel & Cortensor Router

Bardiel is a trust and execution layer for **Base, Virtual, ERC-8004, and other onchain agent ecosystems**, but almost everything it does depends on one critical Cortensor component:

> the **Router Node** (and its evolution into the **Router Agent**).

This page explains:

* what the Cortensor Router does
* how it evolves into an agent-ready surface
* how Bardiel, built by Virtual, sits on top of that surface
* how responsibilities are split between Cortensor and the ecosystems Bardiel serves

***

### 1. What is the Cortensor Router?

In the Cortensor network, the **Router Node** is the main entry point for compute and validation:

* accepts requests from clients (Web2/Web3 apps, SDKs, agents, protocols)
* manages **sessions** and budgets (Stake-to-Use / Pay-Per-Use)
* queues and routes tasks to **miners** based on:
  * model type
  * hardware capability
  * SLA / priority
* collects results and forwards them to **validators** for:
  * Proof of Inference (PoI)
  * Proof of Useful Work (PoUW)
  * reputation / integrity checks

You can think of Router as:

> the traffic controller between users and Cortensor’s distributed miners.

Bardiel never talks to miners directly.\
Bardiel always talks to **Router**, and Router talks to the network.

***

### 2. Router Node → Router Agent

Cortensor’s roadmap describes the Router’s evolution:

* from a **node** that just routes requests
* into an **agent-ready surface** that can speak:
  * `/completions` (inference)
  * `/validate` (proofs / trust signals)
  * MCP (Model Context Protocol)
  * x402-style pay-per-call

This “agent-ready Router” is sometimes referred to as the **Router Agent**:

* exposes clean, **agent-friendly endpoints**
* understands sessions, billing, and validation as **first-class concerns**
* can register itself in **ERC-8004-style registries** so agents can discover it

For Cortensor itself, this means:

> any agent can treat the Router as a single, reliable API for decentralized compute.

For Bardiel, this becomes the **backbone**.

***

### 3. Where Bardiel Sits

Bardiel is **not** part of Cortensor’s core validator set and **not** a miner.

Instead, Bardiel is a **service layer on top of Cortensor** that serves **Base, Virtual, ERC-8004, and other agent ecosystems**.

A simple layering looks like this:

1. **Agent ecosystems / apps / markets**
   * Base-native agents and apps
   * Virtual GAME agents and ACP markets
   * ERC-8004-compatible agents, registries, and marketplaces
   * other onchain agent ecosystems
2. **Bardiel (built by Virtual)**
   * Delegation-as-a-Service
   * Validation-as-a-Service
   * Arbitration-as-a-Service
3. **Cortensor Router / Router Agent**
   * sessions, queues, routing, billing
   * interfaces such as `/completions`, `/validate`, MCP, and x402
4. **Cortensor Miners & Validators**
   * LLM inference
   * PoI / PoUW
   * reputation and integrity checks

So:

> agents, apps, and markets → Bardiel → Cortensor Router → Cortensor Network

Bardiel’s value is not “moving bits”; it is deciding **how** to talk to Router and **how to interpret what comes back**.

***

### 4. Request Lifecycle (Router + Bardiel Together)

Here is a simplified flow for a typical Bardiel call.

#### 1) From ecosystem to Bardiel

An agent, app, or market decides it needs trusted compute or verification.

Examples:

* delegation: `delegate_to_bardiel(task, policy="safe")`
* validation: `validate_with_bardiel(task, claimed_result, policy="safe")`

The caller sends:

* task payload
* optional policy hint (`fast`, `safe`, `oracle`, `adaptive`)
* context (budget, importance, time sensitivity, ecosystem / surface)

#### 2) Bardiel → Cortensor Router

Bardiel translates ecosystem-facing intent into Router-facing calls:

* chooses **model / model class**
* picks **redundancy** (1, 3, 5+ miners)
* chooses which Router surface to hit:
  * `/completions` for raw inference and workflow steps
  * `/validate` for proof-focused runs and trust signals
* attaches **session** / payment info:
  * Stake-to-Use sessions
  * x402-style pay-per-call metadata

Router then:

* validates the request and session
* enqueues tasks
* routes to appropriate miners based on SLA, capacity, and configuration

#### 3) Router → Miners & Validators

* miners run the tasks (possibly in parallel for redundancy)
* validators compute:
  * PoI similarity and consensus
  * PoUW usefulness scores
  * integrity and reputation checks

Router aggregates these into a structured response and returns it to Bardiel.

#### 4) Back to Bardiel

Bardiel receives:

* miner outputs
* PoI / PoUW metrics
* validator metadata and session stats

Bardiel then:

* applies its **policy engine** (tier + templates + heuristics)
* chooses a result (for Delegation flows)
* decides on a verdict (for Validation or Arbitration), such as:
  * `VALID`, `INVALID`, `RETRY`, `NEEDS_SPEC`
  * `SELLER_VALID`, `SELLER_INVALID`, `INCONCLUSIVE`
* generates a **confidence score** and **evidence summary**

#### 5) Bardiel → caller

Finally, Bardiel sends a clean, agent-friendly response back to the calling ecosystem. For example:

```
{
  "status": "VALID",
  "result": { "output": "chosen result" },
  "confidence": 0.93,
  "evidence": {
    "redundancy": 3,
    "poi_cluster_agreement": 0.88,
    "pouw_score": 0.91,
    "tier": "safe"
  },
  "retry_instructions": null,
  "trace_id": "bardiel-trace-abc123",
  "bardiel_version": "v0.1.0"
}
```

The caller then uses this verdict to:

* accept the result and continue
* ask for a retry or refinement
* or, for high-stakes cases, escalate to arbitration or a market’s own dispute logic

***

### 5. Dependency Without Ownership

It is important to be clear about **boundaries**:

* **Cortensor owns Router**
  * defines how sessions, routing, proofs, and economics work
  * exposes `/completions`, `/validate`, MCP, x402, and related surfaces
* **Virtual builds and operates Bardiel**
  * defines how Bardiel uses Router:
    * which endpoints
    * which policies and tiers
    * how to interpret Router and validator signals
* **Base, Virtual, ERC-8004, and other ecosystems use Bardiel**
  * define how Bardiel plugs into their apps, markets, and agent workflows
  * decide when to call Bardiel and what to do with the results
* **Bardiel depends on Cortensor, but is not Cortensor**
  * if Cortensor adds new models or validation primitives, Bardiel can learn to use them
  * if Bardiel finds better scoring or policy strategies, it can evolve without changing Cortensor’s core contracts

You can think of it as:

> Router is infrastructure.\
> Bardiel is the trust and execution product built on that infrastructure.

***

### 6. Evolution: From Raw Router → Bardiel-Aware Router

As both projects evolve:

* Cortensor will:
  * mature `/completions` and `/validate`
  * improve PoI / PoUW, telemetry, and standards-compatible metadata
  * harden Router from v1.x toward a more agent-native Router Agent
* Bardiel will:
  * start as a thin client over Router
  * become a data-driven trust engine with better templates, tiers, and scoring
  * become a shared trust and execution layer across Base, Virtual, ERC-8004, and other agent ecosystems
  * grow into a fuller arbitration and long-horizon trust system for agent workflows

Over time, you can expect:

* more Bardiel-specific hints in Router calls (policies, tags, market or agent identifiers)
* better use of Router-side metrics in Bardiel’s scoring and tier selection
* routing optimizations tailored to **trust vs cost vs latency** for Bardiel traffic

But the layering stays the same:

> agent ecosystems and apps decide the “what” and “why”\
> Bardiel decides how to turn that into trusted execution\
> Cortensor Router executes the “how” at network scale