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

---

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 / 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_ids 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 (best for agents like Bardiel).

    • 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, and

    • 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) per-session reliability via 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:

  • ACP higher-stakes jobs

  • ERC-8004 validator / oracle roles

  • 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 / 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 and 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 Virtual / GAME / ACP

For GAME Workers and ACP flows, Bardiel can:

• use v3 only for higher-value jobs, governance-like or settlement-adjacent checks, and disputes

• map policies to consensus profiles, for example:

  • ACP “high-stakes” market:

    • validation / arbitration flows -> replicas = 5, aggregation = "majority", disagreement_policy = "return_all"

Typical ACP path:

1. ACP job or dispute asks Bardiel:

   • 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 and receives:

   • per-replica verdicts

   • agreement / confidence

4. Bardiel transforms that into:

   • VALID, INVALID, RETRY, NEEDS_SPEC,

   • SELLER_VALID, SELLER_INVALID, or INCONCLUSIVE for ACP.

7.2 ERC-8004 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 8004 registries and agent 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–v0.2 use this to become a real trust agent rather than a thin wrapper.

• v3 (this spec – near-term target)

  • Adds explicit 1 / 3 / 5 redundancy, multi-session routing, and consensus metadata.

  • Bardiel v0.5+ uses v3 to power:

    • stricter validation

    • Arbitration-as-a-Service

    • ACP and ERC-8004 higher-stakes 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:

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