Grading determinism

The core design decision behind Props Oracle is that settlement should be deterministic. Given the same inputs — a canonical event ID, a set of public box-score rows, a defined market taxonomy — any honest party should arrive at the same output. This page explains why that matters, how the oracle enforces it, and how it differs from other uses of UMA that have seen manipulation incidents.

Why determinism is the product

UMA is a general-purpose optimistic oracle. It can be asked to resolve almost any question, from "who won this election" to "is this protocol exploited" to "did this NBA player score at least 25 points." The mechanism is the same in all three cases: someone asserts an answer, a challenge window runs, disputes escalate to DVM.

What varies is how easy it is for an honest disputer to know the correct answer. Questions with subjective or ambiguous inputs — what counts as an exploit, what counts as a fair election, whether a political statement is misleading — are hard to grade and produce contentious DVM votes. Questions with structured, publicly observable inputs are easy. Player-prop outcomes are in the second category, and Props Oracle is built to keep them there.

Structured JSON claims

Every Props Oracle assertion is a structured JSON object with machine-readable fields, not a natural-language statement. The difference matters. A natural-language claim like "Aaron Judge had a good game on April 22" requires interpretation. A structured claim with {"oracle_player_id": "0x7a3b...", "market_key": "batter_hits", "line_value": 1.5, "resolution": "YES"} does not — there is one correct answer, it is a yes-or-no, and a disputer can check it mechanically against the Arweave-archived source snapshot.

This eliminates the category of disputes that arise from ambiguity. Disputes can still happen when the underlying data is wrong or when the relayer makes a transcription error, but they cannot happen because two honest parties read the same claim differently.

Deterministic identifiers

Both the canonical event ID and the oracle player ID are derived from public inputs via keccak256. A consumer, a disputer, and the relayer all compute the same value from the same inputs. This means a consumer can verify at payout time that the assertion they are grading against actually refers to the event and player they think it does, without trusting any off-chain mapping table.

It also means disputers do not need to guess what a claim refers to — the canonical event ID, signal bucket, player identity, and resolution entries are encoded directly in the UMA claim. For registry-backed streams, EventRegistry provides the event-to-assertion mapping; for bucketed MARKET_RESOLUTIONS, indexers discover the assertion from UMA logs and verify the same deterministic identifiers inside the claim. There is no naming ambiguity to exploit.

Deterministic volatility classification

The volatility signal that drives each assertion's internal validation phase duration is also computed deterministically. The oracle reads the same public play-by-play data that anyone else can fetch, applies a fixed set of rules, and assigns exactly one signal. No operator discretion enters the process.

This matters because the signal is part of the assertion and affects how long the validation phase runs. If classification were subjective, the signal itself could be gamed. Because it is deterministic, a disputer who disagrees with the signal can recompute it from the public play-by-play and verify mechanically whether the oracle got it right.

Evidence archival

The raw MLB and ESPN source data, the full play-by-play, and the volatility report for each assertion are bundled together and uploaded to Arweave before the assertion posts. The assertion includes the Arweave transaction ID as arweave_evidence_tx. A disputer checking any entry in the claim fetches the Arweave bundle, looks up the corresponding value in the raw source, and compares. The archive is immutable; if a later official correction appears while the UMA window is still open, that correction can still be used to challenge the assertion and put the relayer's bond at risk.

Contrast with known UMA manipulation cases

Several widely reported manipulation incidents involving UMA OOV3 in 2025 targeted markets with natural-language claims and politically charged or subjective subject matter. The attack vector in those cases was fundamentally that DVM voters were being asked to interpret rather than verify. When interpretation is required, the voter with the strongest financial position can rationalize any interpretation they prefer, and the DVM becomes a signaling game rather than a fact-finding mechanism.

Props Oracle's claim format is designed to close that attack surface for its own domain. A claim that "player X went over 1.5 points in the game on April 22" is either mechanically true or mechanically false; no amount of voter signaling changes what the box score says. The MOOV2 whitelist mechanism UMA introduced in August 2025 (which restricts who can submit proposals to approved parties) adds a second layer: the attack would have to come from inside a whitelisted party, and that party would lose its whitelist status and its bond.

None of this is a claim that Props Oracle is unmanipulable. It is a claim that the structural choices — structured JSON, deterministic IDs, deterministic volatility classification, an internal validation phase before posting, and Arweave archival — are targeted at the specific attack patterns that have affected natural-language markets on the same underlying infrastructure. The domain is narrower and the verification is cheaper, and both are on purpose.