S09 — Arbitration
Three-level dispute resolution for conflicting acknowledgements.
What is arbitrable
- Commitment quality assessment
- Acceptance criteria interpretation
- Force majeure claims
What is NOT arbitrable
- Cryptographic facts (signatures, hashes)
- Protocol state machine transitions
- Constitutional axioms
- Reputation math (reputation = f(events))
Escalation levels
| Level | Panel size | Stake multiplier | Finality |
|---|---|---|---|
| 0 | 3 arbiters | 1× | Appealable |
| 1 | 5 arbiters | 2× | Appealable |
| 2 | 7 arbiters | 5× | FINAL |
Arbiter selection
- VRF-based random selection weighted by arbitration reputation
- 1 unweighted slot per panel (entropy injection)
- Max 15% participation cap per arbiter per epoch
- Correlation penalty for arbiters who serve together repeatedly
Voting
Commit-reveal scheme:
- Arbiters submit
hash(vote + salt)(commit phase) - After all commits received, arbiters reveal
vote + salt - Majority wins. If no quorum, status quo prevails.
Arbiter constraints
Arbiters cannot:
- Delete events
- Reset reputation
- Act outside the dispute window
- Retroactively modify open disputes
- Assign consequences beyond the scope of the dispute
Implementation Status
Verified against source: 2026-04-06
| Claim | Status | Notes |
|---|---|---|
| Three-level escalation (L0/L1/L2) | Spec-only | No escalation or panel-size logic in src/. Roadmap item at data/roadmaps/peer-to-peer/content/topic@finality-arbitration.md. |
| VRF-based arbiter selection | Spec-only | No VRF, weighted random selection, or participation cap code in source. |
| Commit-reveal voting scheme | Spec-only | No commit-reveal, vote hashing, or quorum logic in source. |
| Arbitrability scope (what is/is not arbitrable) | Spec-only | Design constraint only; no enforcement code exists. |
| Arbiter constraints | Spec-only | No arbiter role or constraint enforcement in source. |