> ## Documentation Index
> Fetch the complete documentation index at: https://docs.b3iq.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Historical — Reputation And Disputes

B3IQ reputation inputs, challenge jobs, disputes, and the remedies a validated failure can trigger.

**Historical pilot reference — retired October 3, 2026**

This page preserves earlier public protocol and request-payout pilot
  descriptions. It is not the current service contract, a current availability
  report, or instructions to restart a public serving pool. Public explorer
  pages and third-party provider fallback are retired. Historical records
  remain; owner inference is free and optional current earnings come from
  capacity rented by the hour. Read [current operating evidence](/protocol/overview)
  and [current status](/operations/current-status) first.


B3IQ reputation should be evidence-led. A node earns trust from public-safe
signals such as route readiness, successful receipts, benchmark freshness, health
history, payout finality, and dispute outcomes.

## Reputation inputs

| Input | Meaning |
| --- | --- |
| Uptime | Fresh heartbeat, online history, route health, and tunnel health |
| Benchmark freshness | Control-plane-observed benchmark evidence and stale-proof prompts |
| Success rate | Accepted work, failed dispatches, router errors, and receipt acceptance rate |
| Receipt count | Volume of completed work with signed evidence |
| Payout finality | Payout rows batched and finalized through settlement evidence |
| Dispute rate | Challenge outcomes, appeal status, and validated failures |

## Dispute defaults

A validated failure is handled through the operational remedies B3IQ already
controls:

- Refund customer.
- Release reservation.
- Withhold payout.
- Suspend node or profile.
- Lower reputation score.
- Require fresh benchmark or attestation.
- Escalate to operator review.

A remedy should only apply when policy clearly defines the violation, the
evidence standard, the decision path, and the appeal window.

## Challenge jobs

Challenge jobs can support disputes without exposing raw customer prompts or
outputs. Public-safe evidence can include:

- Challenge class.
- Node and model commitment.
- Expected evidence hash.
- Observed result hash.
- Timestamp and receipt hash.
- Decision reason string.
- Appeal state.

It should not include raw prompts, raw outputs, customer IDs, API keys, exact
private routes, or raw TEE material.

## Snapshot shape

Future `b3iq-reputation-snapshot-v1` summaries can include uptime, benchmark
freshness, success rate, dispute rate, receipt count, payout history, and
operator status. Raw logs and sensitive payloads stay off public settlement surfaces.

**Current reputation is readiness-led**

Today, reputation is read directly from the signals above: route readiness,
  receipt history, health history, benchmark evidence, and payout finality. The
  aggregated reputation snapshot and dispute contracts are future protocol
  work.

## Related

**[Route readiness](/operators/route-readiness)**

See the current public-safe operator diagnosis.
  **[Receipts and settlement](/protocol/receipts-settlement)**

Understand settlement roots and payout evidence.
  **[Privacy](/protocol/privacy)**

Review what public protocol payloads must omit.