Bardiel & Cortensor Router

Bardiel is a Virtual-native service agent, 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 Virtual

---

1. What is the Cortensor Router?

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

• Accepts requests from clients (Web2/Web3, SDKs, agents)

• 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 2026 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)

  • MCP (Model Context Protocol)

  • x402 (pay-per-call)

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

• It exposes clean, agent-friendly endpoints

• It understands sessions, billing, and validation as first-class concerns

• It 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 Virtual and 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 client-side service agent that lives in the Virtual ecosystem and uses the Router as its backend.

Layering looks like this:

1. Virtual / GAME

   • Agents, Workers, Functions

   • ACP buyers/sellers

2. Bardiel (by Virtual)

   • Delegation-as-a-Service

   • Validation-as-a-Service

   • Arbitration-as-a-Service

3. Cortensor Router / Router Agent

   • Sessions, queues, routing, billing (Stake-to-Use / x402)

   • Interfaces: /completions, /validate, MCP, Web3 SDK

4. Cortensor Miners & Validators

   • LLM inference, PoI/PoUW, reputation

So:

Virtual agents → Bardiel → Cortensor Router → Cortensor Network

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

---

4. Request Lifecycle (Router + Bardiel Together)

Here’s a simplified flow for a typical Bardiel call.

1) From Virtual to Bardiel

A GAME agent decides it needs trusted compute or verification:

• Delegation example: delegate_to_bardiel(task, policy="safe")

• Validation example: validate_with_bardiel(task, claimed_result)

The Worker/Function sends:

• task payload

• optional policy hint (Fast/Safe/Oracle/Adaptive)

• context (budget, importance, time sensitivity)

2) Bardiel → Cortensor Router

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

• chooses model / model class

• picks redundancy (1, 3, 5+ miners)

• chooses which Router endpoint to hit:

  • /completions for raw inference

  • /validate for structured proofs

• attaches session / payment info (x402, Stake-to-Use, etc.)

Router then:

• validates the request

• enqueues tasks

• routes to appropriate miners

3) Router → Miners & Validators

• Miners run the tasks (possibly in parallel for redundancy).

• Validators compute:

  • PoI similarity / consensus

  • PoUW usefulness scores

  • integrity and reputation checks

Router aggregates these into a structured response.

4) Back to Bardiel

Bardiel receives:

• miner outputs

• PoI/PoUW metrics

• any validator metadata

It then:

• applies its policy logic (based on version: v0.1 / v0.2 / v0.5 / v1.0)

• chooses a result

• decides on a verdict (VALID, INVALID, RETRY, NEEDS_SPEC)

• generates a confidence score and evidence summary

5) Bardiel → Virtual Agent

Finally, Bardiel sends a clean, agent-friendly response back to Virtual:

{
  "status": "SAFE_VALID",
  "result": { /* chosen output */ },
  "confidence": 0.93,
  "evidence": {
    "redundancy": 3,
    "poi_cluster_agreement": 0.88,
    "pouw_score": 0.91
  },
  "retry_instructions": null
}

The GAME agent uses this verdict to:

• accept the result

• ask for a retry

• or escalate (e.g., full arbitration)

---

5. Dependency Without Ownership

It’s important to be clear about boundaries:

• Cortensor owns Router.

  • It defines how sessions, routing, proofs, and economics work.

  • It exposes /completions, /validate, MCP, x402, etc.

• Virtual owns Bardiel.

  • It defines how Bardiel uses Router:

    • which endpoints

    • which policies

    • which tiers

  • It defines how Bardiel talks to other agents (GAME/ACP).

• 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/policy strategies, it can evolve without changing Cortensor’s core contracts.

You can think of it as:

Router is infrastructure. Bardiel is product on top of that infrastructure.

---

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

As both projects move through 2026:

• Cortensor will:

  • mature /completions and /validate

  • improve PoI/PoUW, telemetry, and ERC-8004 metadata

  • harden Router v1.5 → v2.0

• Bardiel will:

  • start as a thin client over Router (v0.1)

  • become a data-driven trust engine (v0.2)

  • become Virtual’s default trust oracle (v0.5)

  • grow into a full arbitration + trajectory validator (v1.0)

Over time, you can expect:

• More Bardiel-specific hints in Router calls (policies, tags, metadata)

• Better use of Router-side metrics in Bardiel’s scoring

• Routing optimizations tailored to trust vs cost vs latency for Bardiel traffic

But the layering stays the same:

Virtual (Bardiel) decides the “what” and “why”. Cortensor (Router) executes the “how” at network scale.