# Market Lifecycle

Strike has two lifecycle models: FBA orderbook markets and parimutuel pool markets. Orderbook markets transition through these states:

```
Open → Closed → Resolving → Resolved
                          ↘ Cancelled
```

## States

### Open

* Orderbook accepts orders (place, cancel)
* Batch clearing runs at configured intervals (60s default)
* **Transition:** automatically enters `Closed` when `block.timestamp + batchInterval >= expiryTime`

### Closed

* **No new orders accepted** — the final batch has cleared
* Existing orders can still be cancelled (to free collateral)
* **Transition:** anyone submits a valid Pyth resolution via `resolve()` → enters `Resolving`

### Resolving

* Resolution has been submitted with signed Pyth price data
* **Finality gate:** the protocol waits for a 90-second finality period (`FINALITY_PERIOD = 90 seconds`) before finalizing
* **Challenge window:** during this period, anyone can submit an alternative Pyth update that would **change the outcome**; the contract deterministically picks the earliest valid `publishTime` within the settlement window
* **Transition:** `finalizeResolution()` called after finality window → enters `Resolved`

### Resolved

* Outcome is final (UP or DOWN)
* Winning positions pay out automatically at $0.01 per lot
* Losing positions are worthless

### Cancelled

* Triggered if no valid Pyth update is submitted within the maximum resolution window (24h)
* Also triggered if confidence interval exceeds threshold at resolution time
* All collateral is refunded

## Admin Fallback

The admin can call `setResolved()` as a fallback to skip the 2-step resolve/finalize process. This is intended for emergency situations only (e.g., Pyth feed failure, stuck resolution).

## Timeline (5-minute market, 60s batch interval)

```
0:00    Market created, strike price captured from Pyth
0:00    Orderbook open — batches clear every 60s
        ...
4:00    Last batch clears (< 60s remaining → trading halts)
5:00    Expiry timestamp reached — market enters Closed
5:00+   Resolver submits Pyth update for [T, T+60s] window → resolve()
        Finality period (90 seconds)
        Challenge window open during finality period
~6:30   finalizeResolution() → market Resolved
6:30+   Winning positions settled automatically
```

## Parimutuel Pool Lifecycle

Parimutuel markets use a separate pool lifecycle:

```
Open → Closed → Resolving → Resolved
                    ↘ Invalid/Cancelled
```

### Open

* Users can buy into any outcome pool.
* Buying is allowed until `tradingCloseTime`.
* Pool probabilities and projected payouts update as users buy.

### Closed

* No new buys are accepted.
* The market waits until `resolutionTime` before resolver paths can finalize the outcome.
* This split lets betting close before the event itself is over.

### Resolving

* Admin, AI, or Pyth resolution determines the winning outcome.
* AI markets can go through request/proposal/challenge/finality before confirmation.
* Pyth markets evaluate the configured feed/thresholds at `resolutionTime`.

### Resolved

* The winning outcome is final.
* Winners claim principal plus their pro-rata share of losing pools.

### Invalid / Cancelled

* Used when the market cannot be fairly resolved or is explicitly invalidated.
* Users refund principal.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.strike.pm/protocol/market-lifecycle.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.