Overview

Settlement is the process by which a raw box score becomes a finalized on-chain assertion that a consumer can safely grade against. It has four stages: data collection, volatility analysis, evidence archival, and assertion posting followed by finalization. Each stage is designed to be deterministic and independently verifiable, so that the correct answer is the same for the relayer, for a disputer, and for UMA DVM voters if it ever gets that far.

The design priority is to make settlement boring. Player-prop outcomes are, in principle, among the easier things to resolve on-chain — the box score is public, the stat values are numbers, and disagreements are usually transcription errors rather than genuine ambiguity. Props Oracle is built to keep it that way: structured JSON rather than natural-language claims, deterministic identifiers rather than string matching, an internal validation phase that adapts to how volatile the game's stats actually are, and Arweave-archived evidence backing every assertion.

The rest of this section walks through the mechanics. Assertion lifecycle covers the sequence from game-end trigger to finalization. Challenge and disputes covers the relationship between the relayer's internal validation phase and the on-chain UMA dispute window, and what happens if anyone disputes. DNP and edge cases covers the less-common situations — players who don't play, games that don't finish, stats that are corrected after the fact. Timing documents the latency numbers a consumer should plan for. Grading determinism explains why the structural choices described above matter in practice, especially in the context of recent UMA manipulation incidents.