> 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/core-concepts/arbitration-as-a-service.md).

# 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 **Base**, **ERC-8004**, and other onchain agent marketplaces, Bardiel can act as a **first-class dispute oracle**.
* 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

***

### Ecosystem Positioning

#### Base and Other Onchain Agent Markets

In Base-native and other onchain agent ecosystems, Bardiel can act as a **neutral dispute oracle** for:

* agent-to-agent marketplaces
* app-level execution disputes
* buyer-seller workflows with escrow or deferred settlement
* any market where an evidence-backed result is needed before value moves

Typical pattern:

* funds or rewards are held until Bardiel returns a verdict
* `SELLER_VALID` → release funds
* `SELLER_INVALID` → refund, slash, or apply reputation penalties
* `INCONCLUSIVE` → fall back to market-specific rules

This is where Bardiel’s arbitration role is the clearest: a **shared judge** for onchain agent economies.

#### Virtual (GAME + ACP)

* ACP already includes its own evaluators and dispute logic as the **primary** path for resolving disagreements.
* Bardiel Arbitration is **optional / additive** 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-Compatible Ecosystems

* ERC-8004 defines agent, validator, and marketplace coordination surfaces, but does **not** prescribe a built-in dispute oracle.
* Bardiel can be registered or integrated 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 registry / validator / settlement flows
* Bardiel becomes the neutral judge for complex or high-value agent jobs
* verdicts feed into reputation, payout, and dispute resolution logic

***

### High-Level Flow

Below is a reference flow for a Base-native, ERC-8004-style, or ACP-like marketplace.

1. **Dispute Raised**

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

   ```
   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 or application uses Bardiel’s verdict to:

   * release payment or refund buyer
   * apply slashing or penalties (if rules specify)
   * update reputation for buyer, seller, or agents

Bardiel **does not move funds itself**.\
It provides a judgment; the host system 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 or 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 a Base-native market, 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 the seller clearly failed, Bardiel may return something like:

```
{
  "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, for example refunding the buyer, penalizing the seller, or updating 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 before I act on it.”
* **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 Base and Virtual, or pre-/post-action checks in ERC-8004-compatible markets.
* **Arbitration-as-a-Service** is reserved for:
  * explicit disputes
  * high-value or irreversible outcomes
  * 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 **Base, Virtual, ERC-8004, and other onchain agent ecosystems** a standard way to close the loop when trust breaks down.