search
Page cover

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

hashtag
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.

hashtag
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 Virtual and Bardiel, this becomes the backbone.

hashtag
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, and markets

  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/x402 SDKs

  4. Cortensor Miners & Validators

    • LLM inference, PoI / PoUW, reputation, integrity

So:

Virtual agents → 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.

hashtag
4. Request Lifecycle (Router + Bardiel Together)

Here is a simplified flow for a typical Bardiel call.

hashtag
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, policy="safe")

The Worker or Function sends:

  • task payload

  • optional policy hint (fast, safe, oracle, adaptive)

  • context (budget, importance, time sensitivity, surface = GAME or ACP)

hashtag
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 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

hashtag
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.

hashtag
4) Back to Bardiel

Bardiel receives:

  • miner outputs

  • PoI / PoUW metrics

  • any 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

hashtag
5) Bardiel → Virtual Agent

Finally, Bardiel sends a clean, agent-friendly response back into Virtual. For example:

The GAME agent uses this verdict to:

  • accept the result and continue

  • ask for a retry or refinement

  • or, for high-stakes cases, escalate to Arbitration or ACP’s dispute logic

hashtag
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 surfaces

  • Virtual owns Bardiel.

    • Defines how Bardiel uses Router:

      • which endpoints

      • which policies and tiers

      • how to interpret Router and validator signals

    • Defines how Bardiel talks to other agents (GAME, ACP, ERC-8004)

  • 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 product built on that infrastructure.

hashtag
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-oriented metadata

    • harden Router from v1.x toward a more agent-native Router Agent

  • Bardiel will:

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

    • become a data-driven trust engine (better templates, tiers, scoring)

    • become Virtual’s default trust oracle and execution layer

    • grow into a full arbitration and trajectory validator 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:

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

PreviousArbitration-as-a-ServiceNextTechnical Architecture

Last updated