Technical Architecture
This section describes how Bardiel actually works as a Virtual-native trust and execution agent running on top of Cortensor.
At a high level:
Virtual (GAME / ACP) provides the agent ecosystem: agents, Workers, Functions, jobs, and disputes.
Bardiel provides the trust and execution layer:
Delegation (execute on Cortensor, with tools and policies).
Validation (check outputs or planned actions).
Arbitration (resolve disputes where the host market opts in).
Cortensor provides the decentralized compute and proofs:
Router Nodes, Sessions, Miners, Validators, PoI / PoUW, and reputation.
In practice, every call looks like:
Virtual Agent / ACP / ERC-8004 agent → Bardiel → Cortensor Router → Miners + Validators → PoI / PoUW signals → Bardiel verdict → back to Virtual / ACP / marketplace
Bardiel hides the complexity of sessions, redundancy, tooling, and proofs behind a small, agent-friendly surface.
Architectural Roles
Agent Caller (Virtual / ACP / ERC-8004)
The caller is any agent or host system that wants trusted execution or a second opinion.
It:
Decides what needs to be done.
Chooses Bardiel mode:
Delegation – "do this task for me".
Validation – "check this result or plan".
Arbitration – "two sides disagree, decide who is right".
Provides:
Task and spec.
Optional context (docs, URLs, prior messages).
Policy hints (
fast,safe,oracle,adaptive).
Interprets Bardiel’s status codes (for example
VALID,INVALID,RETRY,NEEDS_SPEC,SELLER_VALID,SELLER_INVALID,INCONCLUSIVE) and then:Proceeds with an action.
Requests a retry or revision.
Triggers settlement, refund, or dispute resolution.
This includes:
Virtual GAME Workers and Functions.
ACP flows and markets.
ERC-8004 agents and marketplaces that register Bardiel as a validator or oracle.
Bardiel (Virtual Agent Powered by Cortensor)
Bardiel is the smart client and oracle wrapper that sits between agents and Cortensor.
It:
Normalizes incoming requests into a common task envelope.
Picks a policy tier (
fast,safe,oracle,adaptive).Decides:
How much redundancy to use (1 / 3 / 5+ miners).
Which model or model class to target.
Which validation templates to apply (delegation, validation, arbitration modes).
Manages Cortensor sessions and x402-style billing.
Uses tooling (web fetch, summarization, schema checks, on-chain reads, etc.) to prepare context before sending work to Cortensor.
Requests redundant miner runs and PoI / PoUW-style checks.
Interprets trust primitives:
Consensus and similarity.
Usefulness scores and rubric checks.
Reputation, SLA, and integrity data.
Returns a structured verdict plus optional result and retry instructions.
Conceptually:
Virtual agents keep the "brain" (planning and decisions).
Bardiel handles "muscle and judgment" (execution, cross-checks, verdicts).
Cortensor runs the actual compute and produces proofs.
Cortensor (Infrastructure Layer)
Cortensor is the underlying decentralized AI and validation network.
It:
Routes jobs to miners through Router Nodes and the Session Queue.
Runs redundant inference (N-of-M miners per task, depending on policy).
Produces:
Proof of Inference (PoI) consistency data.
Proof of Useful Work (PoUW) quality scores.
Reputation and SLA metrics.
Integrity and commit / reveal signals where needed.
Optionally stores evidence bundles (for example via IPFS or other storage) for later audit or dashboards.
Bardiel never runs heavy models locally; it always goes through Cortensor via the Router.
What Each Sub-Page Covers
This overview page is the "map". The following pages go deeper into specific parts of Bardiel’s architecture.
Agent Surfaces
Describes the public interface that agents and ACP see when talking to Bardiel.
Request envelope (conceptual):
mode–delegation,validation, orarbitration.task– spec, inputs, constraints, instructions.policy–fast,safe,oracle,adaptive.context– URLs, prior messages, structured docs, on-chain context.metadata– job IDs, buyer / seller IDs, ACP or ERC-8004 info, market identifiers.
Response envelope:
status– for exampleVALID,INVALID,RETRY,NEEDS_SPEC,SELLER_VALID,SELLER_INVALID,INCONCLUSIVE.result– chosen output (for delegation and some validation modes).confidence– numeric score or band.evidence– summarized signals (redundancy, agreement, key violations).retry_instructions– optional guidance when a better attempt is possible.
Explains how the same surface is exposed as:
GAME Workers and Functions in Virtual.
ACP integration calls (execution and validation hooks).
Over time, MCP / x402 surfaces and ERC-8004 validator endpoints.
Use this page when you want to know:
What do I send to Bardiel, and what do I get back?
Policy Engine and Tiers
Explains how Bardiel decides validation depth, redundancy, and cost vs risk trade-offs.
Tiers:
fast– minimal redundancy, light checks.safe– 3x redundancy, PoI plus basic PoUW.oracle– 5+ redundancy with diversity, strict thresholds.adaptive– start cheap, escalate only when confidence is low or disagreement is high.
Covers how tiers map to:
Number and diversity of miners.
PoI / consensus checks.
Usefulness and rubric scoring.
Schema and spec enforcement.
Expected cost and latency.
Also covers when Bardiel escalates automatically (adaptive policy) and how this behaves for:
Virtual pre-action checks (guardrails before tools and ACP).
ERC-8004 validators (pre- and post-action checks for jobs and settlements).
Use this page when you care about risk vs cost vs latency and how Bardiel chooses between them.
Sessions, Billing and x402
Documents how Bardiel uses Cortensor’s economic layer.
Covers:
Sessions as prepaid budgets on Cortensor.
How each Bardiel call consumes budget from a given session.
Integration with x402-style pay-per-call rails:
How requests and receipts are mapped.
How usage is recorded per task or per agent.
How Virtual / ACP / ERC-8004 hosts can:
Fund sessions and top them up.
Set spend limits, tiers, and policies per job or per user.
Decide who pays (buyer, marketplace, infra sponsor, or a mix).
Use this page when you need to understand who pays for what, and how to keep Bardiel online and funded without exposing end users directly to miners, gas, or raw network complexity.
ACP
Covers how Bardiel plugs into ACP inside the Virtual ecosystem.
Topics include:
Mapping an ACP job / spec into a Bardiel task envelope.
Execution flows:
Bardiel as an optional Execution Oracle for high-trust ACP jobs.
Validation flows:
Bardiel as a pre-settlement Validation Oracle that runs before ACP evaluators and payouts.
Arbitration flows:
How Bardiel can provide additional oracle signals in complex disputes.
How ACP remains the final settlement engine (slashing, refunds, reputation).
Clarifies the boundary:
ACP already has built-in evaluators and dispute logic.
Bardiel is a pre-action and pre-settlement trust layer, and an optional extra oracle in disputes, not a replacement for ACP itself.
Use this page if you are building ACP jobs, markets, or dispute flows that depend on Bardiel.
ERC-8004 Integration
Explains how Bardiel works as a validator or oracle service for ERC-8004 agents.
Topics include:
Registering Bardiel as an 8004 validator or service in the registry.
Delegation:
ERC-8004 agents can call Bardiel to run jobs on Cortensor with chosen policy tiers.
Validation:
Bardiel verifies job results and emits statuses that can drive on-chain or off-chain logic.
Arbitration:
For 8004-based marketplaces, Bardiel can act as a dispute oracle wired into escrow and settlement contracts.
Use this page when you are designing 8004-compatible agents, registries, or markets that want Cortensor-backed trust without reimplementing proof logic themselves.
Data and Telemetry
Explains what data Bardiel emits and how it can be observed.
Includes:
Per-call metrics:
Latency.
Cost / spend.
Tier used.
Redundancy and agreement levels.
High-level PoI / PoUW outcomes.
Aggregated stats for:
Agents, sellers, buyers.
Models / domains.
Policies and tiers.
Optional evidence artifacts:
For example IPFS bundles with anonymized or summarized traces.
References via IDs or hashes in Bardiel responses.
Use this page when you are thinking about monitoring, analytics, or trust dashboards for Bardiel inside Virtual or external UIs.
Versioning and Compatibility
Defines how Bardiel evolves without breaking callers.
Covers:
API versioning strategy for:
Request envelope.
Status codes and evidence fields.
Validation templates and policy behavior.
Compatibility across:
Cortensor testnets and mainnets.
Virtual / ACP releases.
ERC-8004 registry and agent versions.
Deprecation guidelines and migration paths:
How and when old modes or policies are sunset.
How builders can opt into new tiers or templates safely.
Use this page when you need to know:
Will this integration still work after the next upgrade?
Mental Model
If you remember nothing else about Bardiel’s architecture, keep this mental picture:
Virtual / ACP / ERC-8004 decides intent. An agent or marketplace decides to execute a task, check a result, or resolve a dispute.
Bardiel converts intent into infrastructure work. Bardiel chooses a policy, runs delegated work on Cortensor (with tools and redundancy), evaluates proofs and templates, and turns noisy signals into a clear verdict.
Cortensor provides compute and truth signals. Miners, PoI / PoUW, reputation, and evidence give Bardiel the raw material to decide whether an output is trustworthy.
Everything else in this section is just a more detailed explanation of those three steps.
Last updated