The rule layer that determines what a market's outcome actually means: initial on-chain rule text, creator clarifications, and versioned rule updates. It is distinct from the technical act of requesting or settling a resolution, and it can change after an oracle request exists but before any proposal is made.
Cluster: Oracle & Resolution
The rule layer that determines what a market's outcome actually means: initial on-chain rule text, creator clarifications, and versioned rule updates. It is distinct from the technical act of requesting or settling a resolution, and it can change after an oracle request exists but before any proposal is made.
Referenced in 2 articles
Polymarket and Kalshi each resolve through layered states — oracle adjudication, adapter consumption and redemption on one side; venue determination, public finalization and REST settlement on the other — so 'settled' is not a shared timestamp. The author proposes a comparison certificate: a cross-venue duration holds only when payoff semantics, endpoints, calendar support, censoring and observation grades align. Evidence spans 108,638 exact-linked Polymarket conditions and 7,357,576 Kalshi MVE endpoints, yet a matched contrast awaits blind adjudication and a semantic registry.
Polymarket markets don't resolve at one moment. They move through a chain: rules written, oracle asked, answer proposed, disputed or not, answer final, payout recorded, money collected. Each step takes its own time. Asking the oracle can start days before a market is answerable; on newer routes the median wait to a first answer is 2 to 8.6 days, while a post-dispute reset resolves in 5 to 48 minutes. Rules also keep changing mid-resolution. Disputes are rare, about 1% of proposals. The lesson for leverage builders: don't use a countdown timer, treat each state separately. Part I of two.