Challenge and disputes

The phrase "challenge window" can mean two different things in oracle systems. In Props Oracle, the bulk of the work is done by an internal validation phase — the relayer's own pre-publication check that the box score has stabilized — and the on-chain UMA dispute window is a short formal layer on top.

This page covers both layers and how they relate.

Internal validation phase

Before any assertion goes on-chain, the relayer runs a validation phase. This is the actual mechanism that catches incorrect box-score values and late stat revisions. It has three components:

  1. Baseline snapshot. Taken at T+15 minutes for CLEAN games, T+75 minutes for any other signal. This is the proposed set of values for the assertion.
  2. Preclose snapshot. Taken later (timing depends on the signal — see Timing). If the preclose values match the baseline, the data is considered stable and the assertion proceeds.
  3. Drift handling. If the preclose snapshot differs from the baseline, the relayer takes a fresh baseline, recomputes the volatility signal — which can ratchet upward as new revision indicators appear, but never downward — and restarts the preclose timer with the new signal's window. This continues until either the data stabilizes or the per-signal cap is reached, at which point the game goes to manual review.

When validation succeeds, the relayer archives a bundle to Arweave containing the official evidence package and posts the assertion to UMA with the Arweave transaction ID embedded in the claim.

This phase is where the oracle does its actual work. By the time an assertion is on-chain, the values have been confirmed stable. The on-chain UMA layer that follows is a formality, not the primary check.

UMA finalization window

Each assertion carries a liveness parameter that determines the on-chain UMA window. Props Oracle sets this to a short value — currently 15 minutes — because the substantive verification is already done. Any party with the required bond balance can still dispute during the window, escalating the assertion to UMA's DVM.

The 15-minute target depends on UMA's MOOV2 whitelist policy accepting it for sports-identifier assertions. If the whitelist application returns a longer minimum, the window will be set to 2 hours instead, with a corresponding shift in expected disputes (which would still be rare for the same reason).

The volatility signal is embedded in the assertion's JSON claim as volatility.signal and is also surfaced in the volatility.uma_metadata summary field for UMA DVM voters.

Who can dispute

Any Ethereum address with the required bond balance can dispute. There is no whitelist, no approval process, and no relationship to the relayer. In practice, the disputer population is expected to be some mix of the consumer protocols themselves (who have direct economic incentive to catch bad data), independent monitoring bots running on cheap infrastructure, and UMA ecosystem participants who dispute as a service.

The bond required from a disputer equals the bond the relayer posted. If the disputer wins, they receive the relayer's bond as reward; if they lose, they forfeit their own. The economics are symmetric.

How a dispute verifies

A disputer's job is to show that at least one value in the asserted claim is wrong. The structured JSON claim makes this concrete: pick an entry, fetch the corresponding value from the Arweave-archived snapshot referenced by the assertion's arweave_evidence_tx, and compare. No subjective interpretation is needed — the question "did player X record Y hits" has a single correct answer visible in the official source.

For edge cases where the public box score itself is in question (a stat that was corrected between the relayer's snapshot and the disputer checking later), the Arweave archive is the authoritative reference for what the relayer asserted and when. If a later official correction appears while the UMA window is still open, a disputer can use it to challenge the assertion and the relayer remains economically accountable through its bond.

What happens after a dispute

When a dispute is filed, UMA escalates the question to the DVM, the decentralized voting mechanism operated by UMA token stakers. DVM votes typically resolve within 48 to 96 hours. During that time, the assertion is neither finalized nor rejected — consumer markets that reference it should remain unresolved.

If DVM voters agree with the asserter, the assertion is marked truthful and finalization proceeds. The disputer loses their counter-bond. If DVM voters agree with the disputer, the assertion is marked untruthful and the relayer loses its bond. The corrected value can then be asserted by any party under the same canonical event ID, after going through its own validation phase.

Consumers should not refund or auto-resolve markets on a lost dispute. The correct behavior is to keep markets unresolved and wait for a corrected assertion.

DVM manipulation risk

UMA's DVM is secured by the economic value of staked UMA tokens. Manipulating it requires controlling a majority of those tokens, which is both expensive and detectable. This risk is inherent to UMA's security model and not something Props Oracle can change. What the oracle can and does do is minimize the DVM's exposure: structured claims with deterministic grading, an internal validation phase that catches errors before posting, and Arweave archival of the evidence. Together these mean disputes should rarely reach the DVM in the first place, because genuinely wrong assertions are caught by validation before they post and correct ones attract no disputes.