# Oracle Resolution

Strike supports **Pyth Price Feeds**, the **Flap AI Oracle**, and admin/fallback resolution depending on market type. This page focuses on Pyth and AI flows.

## Resolution Methods

| Method               | Used For                                               | Source                                             |
| -------------------- | ------------------------------------------------------ | -------------------------------------------------- |
| **Pyth Price Feeds** | Price markets ("Will BTC be above $X?")                | Cryptographically signed price data                |
| **Flap AI Oracle**   | AI-resolved markets, including Flap Token Pools        | LLM/tool reasoning with proof data where available |
| **Admin / fallback** | Curated sports/event pools, challenged/failed AI flows | Protocol admin action                              |

***

## Pyth Price Feed Resolution

Price markets are resolved by Pyth Network oracle price feeds. No human intervention, no subjective arbitration, no governance votes.

## Settlement Rule

Each market has an expiry timestamp `T`. Resolution uses the **earliest Pyth price update with `publishTime` in `[T, T+Δ]`**, where `Δ` is a protocol parameter (default: 60 seconds).

* The resolver fetches signed update data from Pyth's Hermes historical API
* The contract verifies it on-chain using `parsePriceFeedUpdates(updateData, priceId, T, T+Δ)`
* Pyth returns the update matching the window, and challengers can submit earlier `publishTime` updates to replace it
* The `price` field is used for settlement (not `ema_price`) — spot price for clean market semantics

## Confidence Interval Check

Pyth publishes a **confidence interval** with every price update. If the confidence is too wide relative to the price, the resolution is rejected:

```
Reject if: conf > confThresholdBps × |price| / 10000
```

Default threshold: 1% (100 bps). This prevents settlement on unreliable price data.

## Fallback Windows

If no Pyth update exists within `[T, T+Δ]`:

* The resolver can try `[T, T+2Δ]`, then `[T, T+3Δ]`, up to `K×Δ`
* This handles rare cases where Pyth publishing is delayed
* If no valid update exists within the maximum window → market cancels

## Finality Gate

Resolution is not instant:

1. Resolver calls `resolve()` with a Pyth update → `pendingResolution` is set, market enters `Resolving`
2. Protocol waits for a **90-second finality period** (`FINALITY_PERIOD = 90 seconds`)
3. During this window, anyone can submit an **alternative** Pyth update with an earlier valid `publishTime`, but only if it would **change the outcome** (e.g., flip the result from UP to DOWN)
4. After the finality window, `finalizeResolution()` is called → market enters `Resolved` state
5. **Admin fallback:** the admin can call `setResolved()` to skip the 2-step process in emergency situations

This "procedural challenge" mechanism ensures the deterministic rule (earliest update wins) is enforced even if the first resolver submits a suboptimal update.

## Resolver Incentives

* Resolution is **permissionless** — anyone can call `resolveMarket()`
* The protocol runs backstop keepers to ensure timely resolution
* If no one resolves within 24 hours, the market auto-cancels and all funds are refunded

## Why Pyth?

* **Pull oracle** — no continuous on-chain price pushing needed; only one update at resolution time
* **\~400ms update cadence** at the oracle network level
* **Cryptographic verification** — signed data is verified on-chain, not trusted from an EOA
* **Historical data available** — Hermes API serves signed updates for past timestamps
* **Low cost** — update fees are negligible on BSC (1 wei default)

***

## AI Oracle Resolution

AI markets are resolved by the **Flap AI Oracle**, which evaluates configured prompts and returns an outcome choice. Different market families use different resolver contracts, including `AIResolver`, `ParimutuelAIResolver`, and `NativeTokenPoolAIResolver`. The general lifecycle is:

1. **Request** — At market expiry, a keeper calls `resolveMarket()` which sends the prompt to the oracle
2. **AI/tool reasoning** — The oracle backend evaluates the prompt using the configured Strike/FLAP setup for that market family
3. **Callback** — The oracle calls back with a numeric outcome choice
4. **Liveness window** (30 minutes) — The proposed resolution can be challenged
5. **Finalisation** — If unchallenged, anyone calls `finalise()` to settle the market

### Challenge Mechanism

During the 30-minute liveness window, an AI proposal can be challenged by posting the configured challenge bond. Challenged markets move to admin review; the admin can confirm the original result or override it according to the resolver rules. Bond sizes/rewards are contract-specific.

### IPFS Verification

AI resolution proof data is exposed through the indexer or oracle/provider contracts where available. Availability and exact fields depend on the resolver path and market family.

For full details, see [AI Markets](/protocol/ai-markets.md).


---

# 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/oracle-resolution.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.