Arbitration-as-a-Service

Arbitration-as-a-Service is Bardiel’s highest trust tier – a layer built for disputes and settlement-grade decisions, not everyday checks.

Where Validation answers “is this result good enough?”, Arbitration answers:

“Two sides disagree. Given the task, spec, and evidence, who is actually right?”

It sits on top of Cortensor’s oracle-grade runs and Bardiel’s validation stack, and is designed to be slow, careful, and evidence-heavy.

• In ERC-8004 ecosystems, Bardiel can act as a first-class dispute oracle for agent marketplaces.

• In the Virtual ecosystem, ACP’s own evaluator and dispute pipeline remain primary; Bardiel arbitration is an optional backup / secondary oracle when both parties or the market explicitly choose to use it.

---

When to Use Arbitration

Use Arbitration-as-a-Service when:

• a buyer and seller (or two agents) disagree about whether work was delivered correctly

• previous validation attempts (VALID / RETRY / INVALID) are not enough to settle the issue

• a binding decision is needed for:

  • payment vs refund

  • slashing or penalties

  • reputation updates or marketplace sanctions

Arbitration is:

• slower and more expensive than normal validation

• designed for fairness, robustness, and evidence, not throughput

• driven by oracle-grade policies inside Bardiel

• usually wired into escrow-like flows, where the host protocol decides what to do with the verdict

---

Virtual vs ERC-8004 Positioning

Virtual (GAME + ACP)

• ACP already includes its own evaluators and dispute logic as the primary path for resolving disagreements.

• Bardiel Arbitration is optional / experimental and best viewed as:

  • a secondary oracle that ACP can consult for additional signal, or

  • a mutually agreed “backup referee” when both sides want an extra layer of neutrality.

Typical patterns in Virtual:

• Bardiel handles Delegation and Validation as pre-action / second-opinion steps.

• ACP remains responsible for final dispute resolution and settlement.

• Over time, ACP may choose to integrate Bardiel’s arbitration verdicts as one of several signals.

ERC-8004 Ecosystem

• ERC-8004 defines agents, validators, and marketplaces, but does not prescribe a built-in dispute oracle.

• Bardiel can be registered as a validator / oracle service that:

  • receives dispute payloads,

  • runs oracle-grade Cortensor checks,

  • and returns a settlement-grade verdict.

Typical patterns in ERC-8004:

• Marketplaces wire Bardiel into escrow flows:

  • funds / rewards held until Bardiel returns a verdict

  • SELLER_VALID → release funds

  • SELLER_INVALID → refund / slash / reputation hit

• Bardiel becomes the neutral “judge” for complex or high-value agent jobs.

---

High-Level Flow

Below is a reference flow for an ERC-8004-style or ACP-like marketplace.

1. Dispute Raised

   A marketplace or application flags a job as disputed and calls:

   arb_with_bardiel(dispute_payload)

   dispute_payload typically includes:

   • original task / spec

   • claimed result(s) from the seller or agent

   • relevant context (constraints, SLAs, contract terms)

   • any prior validation outputs or logs

2. Bardiel Escalates Policy

   Bardiel switches to oracle-grade mode, for example:

   • higher redundancy (e.g. 5+ miners)

   • diversity sampling (different miners / pools / models)

   • stricter PoI / PoUW-style thresholds

   • full schema/spec enforcement

   • optional extra safety checks

3. Cortensor Execution

   • Cortensor Router orchestrates the oracle-grade runs.

   • Miners and validators produce:

     • consensus outputs

     • similarity / agreement metrics

     • usefulness scores

     • integrity / reputation signals (where available)

4. Bardiel’s Decision

   Bardiel:

   • derives a stable consensus result from Cortensor runs

   • compares the seller’s result against:

     • consensus output

     • task specification

     • constraints / SLAs

   • issues a verdict with confidence and summarized evidence

5. Settlement by the Host System

   The host protocol (ACP, ERC-8004 marketplace, or custom dApp) uses Bardiel’s verdict to:

   • release payment or refund buyer

   • apply slashing or penalties (if rules specify)

   • update reputation for buyer/seller/agents

Bardiel does not move funds itself. It provides a judgment; the protocol applies the consequences.

---

Verdicts

Arbitration responses are higher-level than simple VALID/INVALID.

Typical verdicts:

• SELLER_VALID

  • Seller’s result aligns with consensus and spec; buyer complaint is rejected.

• SELLER_INVALID

  • Seller’s result does not meet spec or consensus; buyer claim is upheld (refund/no payout).

• INCONCLUSIVE

  • Evidence is too weak or spec is too ambiguous for a fair call.

  • Host protocol may fall back to custom rules (split refund, manual review, etc.).

Each response includes:

• status – arbitration verdict

• confidence – Bardiel’s confidence in the decision

• evidence – summarized signals backing the verdict (not all raw logs)

The marketplace or protocol defines exactly what to do with each verdict.

---

Evidence & Transparency

For arbitration, evidence matters much more than for basic validation.

Bardiel may surface, in summarized form:

• how many miners were used and at what tier

• agreement vs disagreement levels between runs

• usefulness / quality score distributions

• which constraints or schema rules were violated

• whether the seller’s output was a clear outlier vs consensus

• any spec issues that meaningfully affect fairness

Raw, low-level data (per-miner logs, exact prompts) may stay internal or be referenced via hashes/IDs, depending on:

• privacy rules

• cost constraints

• the host system’s governance and UX

The goal is to provide enough evidence for trust and auditability, without overwhelming integrators.

---

Example: Product Name Dispute

Task: “Generate 10 product names that:

• include keyword X

• are under 30 characters

• do not contain profanity.”

Seller’s output: Several names are too long and ignore keyword X.

Buyer: opens a dispute in an ERC-8004 marketplace or ACP-like system → the system calls arb_with_bardiel.

Bardiel:

1. Escalates to oracle-grade:

   • 5 miners

   • diversity sampling

   • strict constraint checking

2. Derives a consensus set of valid names that obey all constraints.

3. Compares seller output vs consensus and spec.

If seller clearly failed:

{
  "status": "SELLER_INVALID",
  "confidence": 0.94,
  "evidence": {
    "constraint_violations": [
      "3/10 names missing keyword X",
      "2/10 names exceed 30 characters"
    ],
    "consensus_alignment": 0.21
  }
}

The host protocol then executes its own settlement logic (e.g. refund buyer, penalize seller, update reputation).

---

Relationship to Delegation and Validation

You can think of the layers like this:

• Delegation – “Bardiel, please do this task for me (reliably and verifiably).”

• Validation – “Bardiel, please check this result (second opinion / pre- or post-action).”

• Arbitration – “Bardiel, two sides disagree. Given the spec and evidence, who is right enough to settle the bet?”

In practice:

• Most issues should be caught early by Validation-as-a-Service

  • especially pre-action checks in Virtual, or pre-/post-action checks in ERC-8004.

• Arbitration-as-a-Service is reserved for:

  • explicit disputes,

  • high-value or irreversible outcomes,

  • and cases where both sides accept Bardiel as a neutral oracle.

Bardiel’s job at this layer is to be a neutral, data-backed judge that:

• uses Cortensor’s redundant compute and validation rails, and

• gives Virtual and ERC-8004 ecosystems a standard way to close the loop when trust breaks down.