Timing
A consumer integrating Props Oracle should plan for two latency numbers: how long after a game ends before a finalized assertion is readable, and how long a dispute adds to that if one occurs.
Normal path — adaptive by volatility signal
Settlement timing adapts to how volatile the game's stats are. Most games are classified CLEAN and settle on a fast track; the remaining minority take progressively longer as the volatility signal rises.
| Volatility | Game end → finalized assertion | Frequency (MLB) |
|---|---|---|
CLEAN | ~30 minutes | ~65-70% of games |
LOW | ~3 hours | minority |
MEDIUM | ~5 hours | uncommon |
HIGH | ~7 hours | rare |
CRITICAL | ~13 hours | very rare |
The CLEAN fast-track timing breaks down as: 15 minutes for the relayer's internal validation phase to confirm the box score is stable, a few minutes for Arweave evidence archival, and a 15-minute formal UMA window before finalization.
Non-CLEAN games run a longer internal validation phase: a baseline snapshot at T+75 minutes, then a preclose snapshot at T+2h45min for LOW, T+4h45min for MEDIUM, T+6h45min for HIGH, or T+12h45min for CRITICAL. If the two snapshots match, archival and posting follow the CLEAN pattern. If they disagree, the relayer takes a fresh baseline, recomputes the volatility signal (which can ratchet upward -- never down), and restarts the preclose window at the new signal's duration. Total time is capped per signal: CLEAN at 2 hours, LOW at 6, MEDIUM at 12, and HIGH plus CRITICAL at 18. Games that exhaust the cap go to manual review.
A consumer that expects to resolve markets within the same session as the game should assume roughly half an hour for the majority of games, with occasional games taking up to several hours. A consumer that resolves the next day, or that runs a daily batch, is unaffected by the timing entirely.
Disputed path
The UMA finalization window is short by design -- 15 minutes -- because the heavy lifting happens in the internal validation phase, which is finished by the time the assertion posts. The bond is in place so anyone who genuinely believes the asserted values are wrong can still escalate to UMA's DVM. In practice, escalations are rare: by the time the data has survived validation, the asserted values are extremely unlikely to be wrong.
If an assertion is disputed, finalization pauses until the DVM votes. DVM voting cycles typically resolve within 48 to 96 hours. During that window, the UMA assertion is not truthful yet and consumer markets should remain unresolved. On resolution, UMA marks the assertion truthful if the asserter won or untruthful if the disputer won. In the latter case, any party can repost a corrected assertion, which then runs its own short UMA window after a fresh validation cycle.
If UMA's MOOV2 whitelist policy requires a longer minimum liveness for sports identifiers -- currently under application -- the formal UMA window will be set to 2 hours instead of 15 minutes, with a corresponding shift in the timing table above. The internal validation phase is unaffected.
Why timing is adaptive
The biggest driver of end-to-end timing is the volatility signal. Fixed-window oracles face a tradeoff: a short window optimizes for fast settlement on clean games but risks asserting on pre-revision data for messy ones, leading to disputes and slower net finalization; a long window avoids that problem but makes every game slow. The adaptive approach takes both — fast settlement when the play-by-play shows nothing revision-worthy, longer windows when the specific events known to produce revisions are present.
The signals driving the classification are all structural features of the play-by-play data. The classification is fully deterministic — no operator discretion — so the timing a consumer observes is reproducible from the same play-by-play data anyone else can fetch.