docs/protocol/judge-and-commitmentsv1 · testnet

The judge & commitments

Every market resolves against a spec and an evidence plan that were frozen before the first trade. This page explains what gets committed, when, and why that is the entire trust model.

What gets committed

When an asker creates a market, the claim and its resolution rules are hashed and written on-chain before trading opens. From that moment they cannot be edited, not by the asker, not by the judge, not by us.

The claim

The exact yes/no statement, with every term defined. A price claim pins the venue, the field, and the deadline read; "above $100" resolves against a specific committed number, not a vibe.

The resolution spec

Which sources the judge may consult and how it reads them, captured as a hash, the judgeSpecHash, committed on-chain. Sources must come from the source registry.

The evidence plan

The exact source requests the judge will make, URL, method, and the committed field to read from each, hashed into the snapshot commitment. The judge reads the world through those pinned requests, not through whatever anyone describes later.

The judgeSpecHash and snapshot commitment appear on every market page. Any party can recompute the snapshot commitment from the published evidence plan; if the frozen evidence does not match what was committed, it does not resolve the market.

How the judge works

At the deadline, the judge, a model whose spec is pinned by the committed judgeSpecHash, receives two inputs: the committed spec, and the frozen deadline snapshot of each listed source. It reads the snapshot, not the live web, and it has no knowledge of the market's price or who holds which side.

For a deterministic claim it reads the committed field out of the snapshot (for a Hyperliquid price, the mark price; for weather, the °C temperature) and compares it to the committed threshold. It returns an outcome, a confidence, and the field it read, published as the verdict receipt.

verdict.json · illustrative

{
  "market": "MKT-0016",
  "outcome": "YES",
  "confidence": 0.98,
  "judgeSpecHash": "0x8f2c…a41e",
  "snapshot": "keccak:0x7d41…9e33",
  "read": [
    { "source": "hyperliquid-api", "field": "markPx", "value": "62414.0" }
  ], 
  "challengeWindow": "48h"
}

NOTEThe judge never sees the order book. A market at 95¢ and a market at 5¢ with the same spec and snapshot produce the same verdict.

Why freeze before trading

Most resolution disputes are not about facts, they are about wording that shifted after positions were taken. Freezing the spec and the evidence plan first removes the two classic attacks:

Spec drift

An asker "clarifies" the question toward the side they hold. Impossible here: the committed hash would no longer match, so the reinterpretation cannot bind the judge.

Evidence shopping

A trader surfaces a friendly source at the last minute. Impossible here: the judge only reads the sources pinned in the committed evidence plan.

What remains contestable is the judge's reading, and that is exactly what the challenge process covers.

Timeline

t = 0Claim, spec, and evidence plan are hashed and committed. Trading opens.

deadlineTrading halts. A snapshot of each source is pinned at the deadline; the judge proposes an outcome from it.

+ 48 hChallenge window. Anyone may post a bond against the proposed outcome with a cited counter-reading.

settleUnchallenged (or upheld) outcomes finalize and pay out. The receipt is permanent.

← Previous

Overview

Challenges