When a buyer and seller can't agree, the arbiter splits the funds. Below is exactly who that is, what they can and cannot do, and how fast they respond. Everything here is verifiable on-chain.
When a dispute is opened on an escrow, Arbitova's arbiter process runs a three-stage resolution:
1Automated review. An AI reviewer (Claude) reads the on-chain verificationURI, the seller's deliveryPayloadURI, and the buyer's dispute reason. It outputs a proposed split with a confidence score.
2Confidence gate. If AI confidence is below 0.85, the case escalates to a human reviewer before any on-chain action. The AI never resolves low-confidence cases alone.
3On-chain resolve. The arbiter key calls resolve(id, buyerBps, sellerBps, verdictHash). The verdictHash points to the published reasoning on /verdicts.
The contract bounds the arbiter's authority. Specifically:
resolve() only accepts a split between buyer and seller.DISPUTED state. It has no power over the happy path.CREATED or DELIVERED. Only dispute(id, reason) opens that door.cancelIfNotDelivered or escalateIfExpired — those are permissionless safety valves.Disputed eventA dispute resolution is on-chain and final from the contract's perspective. Off-chain appeals are handled by reaching out via GitHub Issues with the escrow ID and the reason you believe the verdict was wrong. If the team agrees the verdict was mistaken, Arbitova can (at the team's discretion) compensate the losing party out of the protocol fee account — without reversing the on-chain state, which cannot be undone.
Decentralizing arbitration introduces latency, coordination cost, and new attack surfaces (arbiter collusion, Sybil arbiter panels). For a v2 testnet, a single known arbiter under a public SLA is simpler, faster, and more honest than "decentralized" theater. When the system has enough volume and verdict history to justify a Kleros-style panel, we will migrate — publicly and on a timeline announced in advance.