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 & execution layer:
delegation (execute on Cortensor, with tools),
validation (check outputs or planned actions),
arbitration (resolve disputes where the host market opts in).
Cortensor provides the decentralized compute + proofs:
Router Nodes, Sessions, Miners, Validators, PoI/PoUW, and reputation.
In practice, every call looks like:
Virtual Agent / ACP → Bardiel → Cortensor Router → Miners + Validators → PoI/PoUW proofs → Bardiel verdict → back to Virtual / ACP.
Bardiel hides the complexity of sessions, redundancy, tooling, and proofs behind a small, agent-friendly surface.
Architectural Roles
Agent Caller (Virtual / ACP / ERC-8004)
Decides what needs to be done.
Chooses Bardiel mode:
Delegation – “do this task for me.”
Validation – “check this result / plan.”
Arbitration – “two sides disagree, decide who is right.”
Provides:
task/spec,
optional context (docs, URLs, prior messages),
policy hints (
fast,safe,oracle,adaptive).
Interprets Bardiel’s status codes (
VALID,INVALID,RETRY,NEEDS_SPEC,SELLER_VALID, etc.) and takes action (proceed, retry, or settle).
Bardiel (Virtual Agent powered by Cortensor)
Bardiel is the smart client + oracle wrapper:
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.
Manages Cortensor sessions and x402 billing.
Uses tooling (web fetch, summarization, schema checks, etc.) to prepare context before sending work to Cortensor.
Requests redundant miner runs and PoI/PoUW checks.
Interprets trust primitives (consensus, usefulness, reputation, integrity).
Returns a structured verdict plus optional result and retry instructions.
Cortensor (Infrastructure Layer)
Routes jobs to miners through Router Nodes and Session Queue.
Runs redundant inference (N-of-M miners).
Produces:
PoI (Proof of Inference) consistency data,
PoUW (Proof of Useful Work) quality scores,
reputation / SLA metrics,
integrity and commit/reveal signals.
Optionally stores evidence bundles (e.g. on IPFS) for later audit.
Bardiel never runs models locally; it always goes through Cortensor.
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:
Request envelope (conceptual):
mode–delegation,validation, orarbitrationtask– spec, inputs, constraintspolicy–fast,safe,oracle,adaptivecontext– URLs, prior messages, structured docs, etc.metadata– job IDs, buyer/seller IDs, ACP or ERC-8004 info
Response envelope:
status–VALID,INVALID,RETRY,NEEDS_SPEC,SELLER_VALID,SELLER_INVALID,INCONCLUSIVEresult– chosen output (for delegation / some validation modes)confidence– numeric scoreevidence– summarized signals (redundancy, agreement, key violations)retry_instructions– optional guidance
Explains how the same surface is exposed as:
GAME Workers / Functions in Virtual,
ACP integration calls (execution/validation hooks),
and, 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 & Tiers
Explains how Bardiel decides validation depth, redundancy, and cost vs risk trade-offs:
Tiers:
fast– minimal redundancy, light checkssafe– 3x redundancy, PoI + basic PoUWoracle– 5+ redundancy with diversity, strict thresholdsadaptive– start cheap, escalate only when confidence is low
How tiers map to:
number and diversity of miners,
PoI / consensus checks,
usefulness / rubric scoring,
schema/spec enforcement,
cost and latency.
Covers when Bardiel escalates automatically (adaptive policy) and how this differs for:
Virtual pre-action checks (guardrails before tools/ACP),
ERC-8004 validators (pre- and post-action checks for jobs).
Use this page when you care about risk vs cost vs latency and how Bardiel chooses between them.
Sessions, Billing & x402
Documents how Bardiel uses Cortensor’s economic layer:
Sessions as prepaid budgets on Cortensor.
How each Bardiel call consumes budget from a session.
Integration with x402 pay-per-call:
request/receipt model,
mapping from Bardiel calls to x402 charges.
How Virtual / ACP / ERC-8004 hosts can:
fund sessions,
set spend limits,
decide who pays (buyer, marketplace, or infra sponsor).
Use this page when you need to understand who pays for what, and how to keep Bardiel online and funded without exposing end users to miner/gas details.
ACP
Covers how Bardiel plugs into ACP specifically in the Virtual ecosystem:
Mapping ACP job/spec → Bardiel task envelope.
Execution flow:
Bardiel as an optional Execution Oracle for high-trust jobs.
Validation flow:
Bardiel as a pre-settlement Validation Oracle before ACP evaluators and payouts.
Arbitration flow:
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 / oracle service for ERC-8004 agents:
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/settlement contracts.
Use this page when you are designing 8004-compatible agents, registries, or markets that want Cortensor-backed trust without reimplementing proof logic.
Data & Telemetry
Explains what data Bardiel emits and how it can be observed:
Per-call metrics:
latency,
cost / spend,
tier used,
redundancy,
PoI/PoUW outcomes.
Aggregated stats for:
agents, sellers, buyers,
models / domains,
policies and tiers.
Optional evidence artifacts:
e.g. IPFS bundles with anonymized or summarized traces,
references via IDs/hashes from responses.
Use this page when you’re thinking about monitoring, analytics, or trust dashboards for Bardiel inside Virtual or external UIs.
Versioning & Compatibility
Defines how Bardiel evolves without breaking callers:
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/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 picture:
Virtual / ACP / ERC-8004 decides intent. “Execute this,” “check this,” or “resolve this dispute.”
Bardiel converts intent into infrastructure work. It chooses a policy, runs delegated work on Cortensor (with tools and redundancy), evaluates proofs, 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