Polymarket's resolved_at field comes after at least six distinct on-chain states. Of 159,133 Oracle Settle events, only 75,284 have a later adapter terminal log in the same transaction. Roughly half the settlements therefore remain unconsumed in the block where they are recorded. Nechepurenko reconstructs the full chain from Polygon logs, event by event, for every initialized adapter question through a frozen cutoff.

The clocks live one level down

The mechanism operates at two levels. An adapter question stores the rule text, called the "ancillary data," prepares a two-outcome condition on the Conditional Tokens Framework and submits a price request to a UMA Optimistic Oracle. Each request generation is a particular oracle request, carrying separate records for creation, proposal, liveness, dispute and settlement.

A bonded proposer submits a value. Once liveness expires without a dispute, the request can be settled and consumed. A dispute causes modern adapters to reset the question and issue a successor request, giving the same question another generation and another set of clocks. If the successor is disputed, it can escalate to UMA's Data Verification Mechanism backstop.

Question-level state cannot recover this path. Two questions may both show "proposed," although one remains in its first generation while the other is a post-reset successor whose next dispute reaches the Data Verification Mechanism backstop. Their feasible next transitions differ. The paper formalises this with a short proof: coarse state that omits request generation is not Markov.

The reconstruction decodes adapter logs under frozen ABIs. It retrieves oracle lifecycle events using exact filters for oracle address, event topic and the indexed requester adapter. At the freeze point, Polygon block 79,721,080 (last included log 2025-11-30 23:59:30 UTC), the population contains 185,550 initialized adapter questions across five adapter families and 350,703 decoded adapter logs.

The oracle records contribute 504,332 decoded lifecycle events: 184,148 RequestPrice, 159,447 ProposePrice, 1,604 DisputePrice and 159,133 Settle. The totals reconcile exactly. There are 182,671 questions with at least one request, plus 1,477 successor generations, while 2,879 legacy questions have no request at all. Every link uses the exact requester, identifier, timestamp and ancillary-data fields, without a nearest-time or question-ID-only fallback.

Why the legacy route appears so fast

Median request-to-first-proposal time is 182 seconds for the legacy adapter, compared with 176,388 seconds for Standard V4 and 744,151 seconds for the original NegRisk adapter. A literal reading makes legacy appear a thousand times faster than Standard V4 and four thousand times faster than NegRisk. Yet modern adapters create the request during initialization, before contractual decidability, and the paper cannot date decidability at all.

Reset timing exposes the problem. Median reset-to-successor-first-proposal time is 300 seconds on V4, 934 on V3.1, 2,713 on V2 and 2,909 on NegRisk. The contested route, expected to be slower, takes minutes. Initial requests take days. After an undisputed liveness window expires, median time to Oracle Settle ranges from 84 seconds on V3.1 to 598 seconds on V4.

The data contain 1,604 first disputes. V4 records 144 from a 55,132 risk set (0.26%), while V2 records 711 from 27,831 (2.6%). A dispute on a modern route usually triggers a reset: 606 of 625 on NegRisk and 588 of 711 on V2. All 22 legacy first disputes instead proceed directly to a settlement endpoint with zero resets.

Second disputes move much more slowly. In a frozen risk set of 253 successor generations, median time to Settle runs from 242,262 to 322,682 seconds. These figures are upper bounds because the exact DVM result time is unobservable. The paper leaves it that way rather than midpoint-imputing a timestamp.

The missing clock

The abstract concedes the central limitation: those clocks remain unmeasured population-wide, covering all 185,550 questions. Mechanism timestamps are rejected as substitutes. Its own qualification on the timing comparison reads, "This descriptive contrast does not establish causal efficiency."

No clock in the data says when the answer became knowable.

The body defends these intervals in two places. Section 4.5 treats them as valid measurements of mechanism time that do not become truth-to-resolution latency. Section 8.2 grounds the direct evidence for the two-level representation in exactly linked successor generations, rather than the magnitude of the timing gap. The argument holds on those terms.

Comparisons across the five routes still combine differences in adapter version, oracle family (legacy OO, OO V2, Managed OO V2) and calendar period. We did not find an adjustment for any of the three. The legacy estimates are especially thin: a first-proposal risk set of 3,006 and 22 disputes. Its initialization-to-terminal Kaplan-Meier median is 80,033,650 seconds, reached with 2,941 terminal events and 2,888 censored among 5,829 legacy questions.

Rule text can change after the oracle request is live. Among 1,711 exact clarification-to-generation relations, 1,426 (83.34%) occur after request creation and before the first proposal. Every cutoff question has an initial on-chain rule version. The ledger also contains 1,570 observed updates, including 1,549 creator-authoritative updates affecting 1,350 distinct questions. Another 51 relations occur after Oracle Settle for the linked generation, and the paper declines to classify them as retroactive.

The Part I boundary becomes visible in the Settle-to-adapter gap. Only 75,284 of 159,133 Settle events include a later adapter terminal log in the same transaction. The remainder are consumed through later transactions or lack an identified endpoint.

Concentration is also measurable. On Managed OO in September 2025, one proposer address supplied 0.664770 of 13,707 proposals across 87 addresses (HHI 0.454111), despite documentation describing proposal as open to anyone. By comparison, 64 November dispute events were distributed among 39 addresses (HHI 0.040527). Historical whitelist state contains 2 observed configuration events, leaving access unresolved for 61,595 request rows. The paper therefore attempts no access-regime comparison.

A usable state vector

Part I reports no result for price or liquidity. It defines price, spread, depth and convergence estimands, then leaves them unexecuted, with the related version-locked hypotheses marked unmeasured or transferred. Payout recording and redemption are deferred to a companion Part II.

For pricing or margining event claims, the usable output is a state vector: active generation, proposal value, dispute and reset history, plus whether Settle has been consumed.

Re-parsing already-frozen nested Gamma event pages increased exact stable-ID coverage from 654 questions (0.35%) to 104,032 (56.07%). Another 81,518 remain unmatched, with none ambiguous. Coverage varies sharply by route, reaching 98.94% on V4 and 0% on the original NegRisk adapter, the largest family with 76,271 initialized questions. Any study conditioned on human-readable market metadata therefore uses a route-selected cohort. We discussed the same hazard in our note on Polymarket longshot losses.

We could not test any of these results on our own data. Reproducing the reconstruction requires Polymarket adapter, Conditional Tokens and UMA oracle event logs from Polygon, together with versioned rule metadata, and we hold none of those series. The paper says the contrast does not establish causal efficiency. A within-route comparison over a common calendar window would change my view of the timing section, and we did not find one in the paper.