> 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/technical-architecture/core-primitives/delegate-and-validate-v3-spec-consesus.md).

# /delegate & /validate v3 Spec - Consesus

> Scope: This page describes how Bardiel uses v3 of Cortensor’s `/delegate` and `/validate` (and future `factcheck`) endpoints.\
> It is about the endpoint contracts Bardiel calls, not a “Router v3”.

Bardiel sits on top of the Cortensor Router. v3 is where Bardiel gets **explicit redundancy and consensus knobs** instead of inheriting whatever redundancy a single session happens to have.

From Bardiel’s perspective, v3 is:

> Agent-ready consensus — explicit 1 / 3 / 5 redundancy plus structured consensus metadata for `/delegate`, `/validate`, and `factcheck`, so Bardiel can turn Cortensor into an AWS-for-agents execution layer and a neutral safety checkpoint.

This matters across **Base, Virtual, ERC-8004, and other onchain agent ecosystems**:

* **Base-native agents and apps** can use Bardiel for higher-confidence execution and pre-action checks.
* **Virtual** uses Bardiel deeply through GAME and ACP.
* **ERC-8004-compatible systems** can use Bardiel as a validator / oracle surface.
* **Other agent ecosystems** can reuse the same trust and execution rails.

***

### 1. Goal (Bardiel View)

v3 extends the v2 contract-first endpoints with a new `consensus` block:

* `POST /api/v3/delegate` – execution with explicit redundancy
* `POST /api/v3/validate` – verification with explicit redundancy
* `POST /api/v3/factcheck` (name TBD) – fact / reality checks with explicit redundancy

Instead of:

* one request -> one session -> implicit redundancy (if any)

Bardiel can now ask Cortensor for:

* how many independent sessions to run (1 / 3 / 5), and
* how to aggregate their results into a single answer or verdict.

This lets Bardiel map its policy tiers:

* `fast`
* `safe`
* `oracle`
* `adaptive`

onto concrete redundancy and consensus strategies, instead of everything living inside a single session.

***

### 2. v2 vs v3 – Mental Model for Bardiel

#### v2 (today – Bardiel’s baseline)

Bardiel calls:

* `/api/v2/delegate` with:
  * `objective`, `input`, `execution`, `policy`
  * one `session_id`
* `/api/v2/validate` with:
  * `claim`, `policy`, `context`
  * one `session_id`

Inside that single session, Cortensor may:

* fan out to multiple miners
* run PoI / PoUW
* apply some redundancy

But from Bardiel’s perspective:

* it is still one session, and
* consensus is implicit and opaque inside that session.

Bardiel can see evidence, but it cannot directly say:

> Run this across 3 sessions and show me where they agree or disagree.

#### v3 (this spec – what Bardiel is preparing for)

Bardiel calls:

* `/api/v3/delegate` or `/api/v3/validate` with:
  * the same v2 core contract (objective / claim + policy), plus
  * a `consensus` block describing:
    * how many replicas (1 / 3 / 5)
    * which sessions or session pool to use
    * how to behave if replicas disagree

The router then:

* chooses sessions
* runs the job across multiple independent sessions when requested
* aggregates outputs
* returns a final answer / verdict plus per-replica evidence plus consensus metadata

From Bardiel’s point of view, v3 turns:

* “I hope the session did something sensible under this tier”

into:

* “I explicitly asked for 3 independent runs under this tier, and I can see exactly how they agreed or disagreed.”

***

### 3. Request Shape – Consensus as Policy Knobs

v3 adds a `consensus` block to the existing v2-style payload.

#### 3.1 Consensus Block (Conceptual)

Example shape:

```
"consensus": {
  "replicas": 3,
  "session_pool": ["201", "202", "203"],
  "aggregation": "majority",
  "disagreement_policy": "return_all"
}
```

Fields (shape, not final schema):

* `replicas`
  * `1`, `3`, or `5`
  * `1` behaves almost like v2 (single session)
  * `3` and `5` trigger multi-session runs
* `session_pool`
  * list of candidate `session_id`s such as `["201", "202", "203"]`
  * Router chooses from this pool (plus routing policy) to build the replica set
  * Future: allow labels or profiles instead of raw ids
* `aggregation`
  * initial v3: `"majority"`
  * v4 roadmap: `"weighted"`, `"median"`, `"median_of_means"`, `"model_ensemble"`, etc.
* `disagreement_policy`
  * how to behave when replicas disagree:
    * `return_all` – return all replica results plus consensus summary
    * `fail_hard` – treat disagreement as an error
    * `best_effort` – still pick a winner but tag low confidence and expose evidence

#### 3.2 Router Behavior (Bardiel Expectations)

`replicas = 1`:

* behaves similarly to v2:
  * choose a single `session_id` (from `session_pool` or routing policy)
  * run the job there
  * return one result
  * still attach `consensus` metadata indicating `replicas = 1`

`replicas = 3` or `5`:

* Router:
  * picks 3 or 5 distinct sessions (from `session_pool` and routing rules)
  * sends the same logical job to each session independently
  * waits for enough to finish under overall timeout
  * aggregates their outputs into:
    * a final answer / verdict
    * a per-replica evidence bundle plus agreement metrics

This applies to:

* `/api/v3/delegate` – redundant execution runs
* `/api/v3/validate` – redundant verification runs
* `/api/v3/factcheck` – redundant fact / world checks

#### 3.3 Mapping Bardiel Tiers -> v3 Consensus

Bardiel’s policy engine can map its tiers to consensus knobs, for example:

* `fast`
  * `replicas = 1`
  * `aggregation = "majority"` (trivial)
  * `disagreement_policy = "return_all"`
* `safe`
  * `replicas = 3`
  * `aggregation = "majority"`
  * `disagreement_policy = "return_all"` or `"best_effort"`
* `oracle`
  * `replicas = 5`
  * `aggregation = "majority"`
  * `disagreement_policy = "return_all"` or `"fail_hard"` for high-stakes flows
* `adaptive`
  * start with `replicas = 1`
  * escalate to `3` or `5` if initial checks show low confidence or high disagreement, via follow-on v3 calls

These mappings live in Bardiel’s own Policy Engine & Tiers, but v3 gives Bardiel the knobs to implement them cleanly.

***

### 4. Response Shape – Consensus Metadata for Bardiel

Every v3 response includes a `consensus` section. Bardiel consumes this and may expose a simplified version in its own `evidence` field.

#### 4.1 Consensus Block (Response, Conceptual)

Example shape:

```
"consensus": {
  "replicas": 3,
  "agreement": 0.67,
  "verdicts": ["VALID", "VALID", "INVALID"],
  "strategy": "majority",
  "confidence": 0.82
}
```

Fields:

* `replicas`\
  Number of independent runs actually executed – `1`, `3`, or `5`.
* `agreement`\
  Fractional agreement, for example:
  * `0.67` for 2 / 3
  * `0.8` for 4 / 5
* `verdicts`\
  Per-replica verdicts or coarse labels, for example:
  * for `/validate`: `["VALID", "VALID", "INVALID"]`
  * for `factcheck`: `["TRUE", "TRUE", "FALSE"]`
  * for `/delegate`: `["OK", "OK", "TIMEOUT"]` or similar task-level labels
* `strategy`\
  Aggregation strategy used (for example `"majority"` in v3).
* `confidence`\
  A derived confidence score combining:
  * agreement ratio
  * tier / policy
  * future v4 hooks into PoI / PoUW and reputation

#### 4.2 How Bardiel Uses This

Bardiel uses the router’s `consensus` block to:

* drive its own top-level verdicts:
  * `VALID`
  * `INVALID`
  * `RETRY`
  * `NEEDS_SPEC`
  * `SELLER_VALID`
  * `SELLER_INVALID`
  * `INCONCLUSIVE`
* inform its `confidence` field in Bardiel responses
* populate its `evidence` block with:
  * redundancy used
  * agreement level
  * notable disagreements

Example:

* **Delegation case**\
  “2 out of 3 runs produced equivalent JSON under `safe` policy; Bardiel chooses the consensus-merged result, confidence = 0.82.”
* **Validation case**\
  “3 out of 5 verification runs judged the claim as VALID; Bardiel returns status = VALID, confidence = 0.78, and includes summary reasons.”

Key point: Bardiel is not guessing — it can see how many runs, how they were aggregated, and how much agreement there was.

***

### 5. Endpoint Versioning for Bardiel Integrations

To keep integration simple:

* v2 endpoints remain:
  * `/api/v2/delegate`
  * `/api/v2/validate`
* v3 endpoints are added:
  * `/api/v3/delegate`
  * `/api/v3/validate`
  * `/api/v3/factcheck` (once promoted)

Both sets coexist:

* **v2** – contract-first, policy-aware, single-session focus; basic evidence
* **v3** – contract-first plus explicit multi-session redundancy and consensus metadata

Bardiel will:

* continue to support v2 for:
  * simple flows
  * backwards compatibility
  * testnet smoke tests
* adopt v3 for:
  * higher-stakes jobs in Base-native, Virtual, and ERC-8004-compatible workflows
  * Arbitration-as-a-Service
  * any workloads that need explicit redundancy and visible consensus

MCP / x402 / A2A tools follow the same naming, for example:

* `cortensor_delegate_v3`
* `cortensor_validate_v3`

mapped behind Bardiel’s own delegation and validation surfaces.

***

### 6. Router Behavior (What Bardiel Assumes)

To support v3, Bardiel assumes router-level behavior roughly as follows.

#### 1. Replica session selection

Given a v3 request:

* build a candidate session set from:
  * `session_pool` (if provided)
  * router routing rules (for example, tier -> specific miners / models)
  * optional policy hints from Bardiel
* select `replicas` distinct, healthy sessions that:
  * satisfy tier and SLA expectations
  * have appropriate miner pools (ideally non-overlapping for real redundancy)

#### 2. Fan-out and fan-in

For `replicas > 1`:

* fan-out:
  * send a v2-like payload plus replica / consensus metadata to each session
* fan-in:
  * collect per-replica responses
  * normalize intermediate fields
  * compute `agreement`, `verdicts`, `confidence`
  * attach a populated `consensus` block

Edge cases:

* if all replicas fail:
  * apply `disagreement_policy`
  * return a clear error or low-confidence result
* if some replicas timeout:
  * decide whether to ignore or treat as negative evidence, depending on policy

#### 3. Baseline consensus strategy (v3)

* for discrete verdicts (`VALID` / `INVALID`, `TRUE` / `FALSE`)
  * use majority vote
* for simple status flags (`OK` / `TIMEOUT` / `ERROR`)
  * treat `TIMEOUT` / `ERROR` as non-votes or negative evidence depending on policy
* for scores (future)
  * average or bucketed-majority strategies

The endpoint contract guarantees the shape of `consensus` (fields present and consistent), not the exact internal formula. Bardiel can still tune its own risk thresholds on top.

***

### 7. Bardiel-Specific Usage Patterns

#### 7.1 Base, Virtual, and other app / market flows

For app, market, and workflow integrations, Bardiel can:

* use v3 only for higher-value jobs, settlement-adjacent checks, and disputes
* map policies to consensus profiles, for example:
  * a high-stakes market:
    * validation / arbitration flows -> `replicas = 5`, `aggregation = "majority"`, `disagreement_policy = "return_all"`

Typical path:

1. an app, market, or workflow asks Bardiel for:
   * `mode = "validation"` or `mode = "arbitration"`
2. Bardiel chooses:
   * policy tier (`safe` vs `oracle`)
   * v3 consensus parameters
   * appropriate session pool(s)
3. Bardiel calls `/api/v3/validate` or future `factcheck`
4. Bardiel transforms the results into:
   * `VALID`, `INVALID`, `RETRY`, `NEEDS_SPEC`,
   * `SELLER_VALID`, `SELLER_INVALID`, or `INCONCLUSIVE`

#### 7.2 Virtual / GAME / ACP

In Virtual, Bardiel can use v3 to:

* strengthen GAME second-opinion flows
* perform pre-settlement ACP checks with explicit redundancy
* support optional arbitration as an extra oracle in disputes

#### 7.3 ERC-8004-Compatible Ecosystems

When Bardiel acts as an ERC-8004 validator / oracle:

* externally, Bardiel exposes a simpler “single verdict” surface
* internally, Bardiel can call `/validate v3` or `factcheck v3` with:
  * `replicas = 3` or `5`
  * `aggregation = "majority"`
  * appropriate `disagreement_policy`

This makes Bardiel a **consensus-aware validator** that uses Cortensor networking under the hood, but presents a clean, single-oracle interface to registries and markets.

***

### 8. Roadmap Context – v2 -> v3 -> v4 (from Bardiel’s POV)

* **v2 (current baseline for Bardiel)**
  * structured `/delegate` and `/validate`
  * policy tiers
  * mostly single-session; consensus is implicit
  * Bardiel v0.1 to v0.2 use this to become a real trust layer rather than a thin wrapper
* **v3 (this spec – near-term target)**
  * adds explicit 1 / 3 / 5 redundancy
  * multi-session routing
  * consensus metadata
  * Bardiel v0.5+ uses this to power:
    * stricter validation
    * Arbitration-as-a-Service
    * higher-stakes Base, Virtual, ERC-8004, and other ecosystem flows
* **v4 (later)**
  * builds on v3 with:
    * pluggable aggregation strategies
    * reusable validation / fact artifacts with IDs
    * dynamic redundancy that responds to risk, cost, and reputation (PoI / PoUW)
  * Bardiel can then treat router-level artifacts as long-lived trust objects that other agents and markets can reference

For now, v3’s role for Bardiel is simple but important:

> Make redundancy and consensus first-class, visible, and tunable so Bardiel can map `fast`, `safe`, `oracle`, and `adaptive` to concrete network behavior — not just vibes.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.bardiel.tech/technical-architecture/core-primitives/delegate-and-validate-v3-spec-consesus.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.