Settlement mechanics in prediction markets

Settlement in a prediction market is not a single moment. It is a sequence: the oracle reports, the venue processes the report, the venue flags the market resolved, the CLOB stops accepting new orders, and eventually positions become redeemable. Each step has a different latency and a different failure mode. Treating settlement as a binary flip is the most common source of reconciliation confusion.

What the oracle actually reports

On Polymarket, crypto up/down markets resolve against a Chainlink price feed. The oracle reports the price at a specific timestamp. That timestamp is the settlement reference, not the moment your bot receives the data. What matters for your strategy is whether the reference price is above or below the strike at the oracle's designated observation time, not at the time your process reads the feed.

The distinction is relevant for positions you enter near the settlement window. If your entry window is the last 30 to 60 seconds before expiry, the oracle price at expiry is being determined at roughly the same time you are executing. Your position's value is contingent on a price that has not yet been finalized.

Provisional marks are not settlement

During the final seconds of a market, the CLOB orderbook may still be active. Prices in the book during this window are market participant estimates of the settlement outcome, not the outcome itself. A YES contract trading at $0.95 with 10 seconds left means participants think the probability is around 95 percent. It does not mean settlement is confirmed.

Your bot should maintain a hard distinction between positions where settlement is final and positions where it is still provisional. Mixing them in your P&L accounting creates a misleading picture of realized versus unrealized.

The reconciliation gap

There is a window between when the venue marks a market resolved and when your bot's position state reflects that resolution. During this window your open position register may still show an exposure that no longer exists, or may not yet reflect the cash credit from a winning position.

A robust implementation handles this by maintaining a separate settlement state for each position: open, pending-settlement, settled-won, settled-lost. Transitions between states are driven by observable venue events, not by inferred timing. Your P&L calculation should only count positions as realized once they have moved to a terminal state.

Oracle corrections happen

Occasionally an oracle price is corrected after initial settlement. When this happens, the venue may re-resolve the market and reverse prior outcomes. This is uncommon but not theoretical. Your audit trail needs to record both the initial settlement guess and the correction event separately, so you can correctly attribute the P&L delta.

The licensed kits include reconciliation hooks designed for these mechanics. See products for the specific implementation details, or start with the Polymarket bots guide if you are evaluating the overall architecture.