DNP and edge cases

Most assertions follow the clean path — a game finishes, stats are available, the volatility assessment classifies the cells as CLEAN or LOW, the validation phase confirms stability, the assertion posts, the formal UMA window closes, the callback fires. The remainder of this page documents the less clean cases and how the oracle handles each.

Did-not-play (DNP)

A player who was expected to appear (based on the pre-game prop lines posted against them) but did not appear in the box score at all is included in the relevant MARKET_RESOLUTIONS assertion with stat_value: "DNP". Internally this is represented as -1, but public JSON claims emit the string value. The DNP encoding is stable across assertions and across leagues.

DNP is different from a zero. A player who appeared and had zero hits is reported with stat_value: 0; a player who was scratched before first pitch and never appeared is reported as "DNP". Consumers grade the two differently according to their own rules — a common pattern is to treat DNP as a push and zero as a graded loss on an over, but this is the consumer's choice, not the oracle's.

Mid-game injury or substitution

A player who enters the game and then exits before it ends — an injury, a pitching change, a substitution — is graded against their actual accumulated stats at the moment they stopped participating. They are not flagged as DNP. A starting pitcher who exits in the 3rd inning with three strikeouts is graded against final_stat_value: 3.0, not as DNP. This matches how most sportsbooks grade the same markets.

Postponed or suspended games

A game that does not reach final produces no market-resolution assertion. The oracle waits for the terminal status; if that status is postponed or suspended, nothing is posted until the game is completed. Explicit GAME_VOID assertions for cancelled games are part of the contract design, but are not live in the current beta posting path. Consumer markets that reference the canonical event ID for that game remain unresolved unless they implement their own void policy.

If a postponed game is later rescheduled, it is treated as a new event with a new commenceTime, which produces a different canonical event ID. The oracle resolves the rescheduled game under the new ID. Consumers that locked markets against the original ID will need their own governance process to void and refund; the oracle cannot retroactively link the two IDs because the event ID derivation is deterministic by design.

Suspended games completed later

A game that is suspended (e.g., a rain delay that pushes play to the next day) and then resumed under the same scheduled start time retains its original canonical event ID. The oracle asserts on the final combined box score once the resumption completes and the game reaches final. The validation phase and volatility assessment apply to the final combined state, not to the original suspension.

Retroactive stat corrections

Official-league scorers occasionally change a stat after the initial box score is published — a hit reclassified as an error, an assist retroactively credited, an RBI corrected. The oracle's defense is the T+15m/T+75m timing gate, volatility classification, preclose snapshot, hard caps, and internal validation before posting.

A correction that arrives after the assertion has posted is the residual case. Because the formal UMA window is short, the preclose and drift-handling system is the primary protection before posting. If a correction is discovered while the UMA window is open, the relayer can self-dispute or an external party can dispute through UMA. If the correction is genuine, the assertion is cleared and a new assertion can be posted with the corrected values.

Validation phase failure

The planned internal validation phase has a hard cap measured from game final: CLEAN at 2 hours, LOW at 6, MEDIUM at 12, and HIGH plus CRITICAL at 18. If the preclose snapshot keeps disagreeing with the baseline past the cap, the cell is routed to manual review rather than asserted automatically. This is rare — most games' stats stabilize well before the cap — but it can happen when a contested call is being revised repeatedly, or when a league issues multiple rounds of scoring changes.

During manual review, the operator confirms correct values against a third independent source and either posts the assertion manually or, if the data cannot be reliably determined, declines to assert. Consumer markets referencing a cell in manual review remain unresolved until the operator acts.

Relayer downtime

The relayer is a convenience, not a liveness requirement. If the relayer is offline when a game ends, no assertion is posted until it comes back. Markets referencing that game remain unresolved until then. If the relayer is offline for an extended period, any party with the required bond can post an assertion themselves using the same public data — there is no permission system restricting who can assert. Consumer markets are never at risk of forced incorrect resolution because of relayer downtime; they simply wait.