---
title: "Current resolution lifecycle snapshot for one market"
method: GET
path: "/v1/markets/{provider}/{market_id}/resolution"
tags: ["Resolutions"]
---

# Current resolution lifecycle snapshot for one market

`GET /v1/markets/{provider}/{market_id}/resolution`

## Request

- Base URL: `https://md.kairos.trade`
- URL: `https://md.kairos.trade/v1/markets/{provider}/{market_id}/resolution`
- Auth: one of:
  - none
  - API key in header `X-Client-Id` and API key in header `X-Api-Key` and API key in header `X-Api-Secret`

Returns the current resolution state for one market — status (e.g. proposed/disputed/resolved), the UMA-style proposal/dispute metadata, and (once resolved) the payout numerators. For kalshi-style providers the ticker identifies the market directly; for CTF venues (polymarket, predictfun, opinion) the market id is resolved to its on-chain condition id internally. Rate-limit bucket: LIGHT.

The response caches for a short window (`Cache-Control` header with a strong ETag / 304 support) because proposals move through a roughly 2-hour challenge window — a longer cache lifetime would routinely misreport "proposed" as already final.

## Path parameters

- `provider` 'kalshi' | 'polymarket' | 'opinion' | 'predictfun' | 'hyperliquid' | 'kalshi_offchain' | 'dome', required
- `market_id` string, required

## Response `200`

Resolution lifecycle snapshot.

- ResolutionStatus: One-row resolution lifecycle snapshot for a single market.
  - `provider` string, required: Canonical provider name.
  - `market_id` string, required: Echoes the requested market_id/ticker.
  - `condition_id` string, required: On-chain condition id (CTF venues); empty string for kalshi.
  - `status` string, required: Lifecycle status. Observed values include `proposed`, `disputed`, and `resolved`; not an exhaustive enum.
  - `proposed_price` number, nullable, required: Normalized proposed settlement price, or null if none proposed yet.
  - `proposed_at` string, nullable, required: ISO8601 UTC.
  - `challenge_window_ends_at` string, nullable, required: ISO8601 UTC. Null until a proposal starts the challenge window.
  - `proposer` string, required: Proposer address; empty string if none.
  - `disputer` string, required: Disputer address; empty string if undisputed.
  - `dispute_count` integer, required
  - `reset_count` integer, required
  - `payout_numerators` integer[], required: Empty array until resolved.
  - `resolved_ts` string, nullable, required: ISO8601 UTC. Null until resolved.
  - `last_event_ts` string, required: ISO8601 UTC timestamp of the most recent lifecycle event.

## Other responses

- `304`: Not Modified — `If-None-Match` matched the current ETag.
- `400`: Unknown provider.
- `401`: No valid credential presented. Every path returns `code: unauthorized`; the triggers differ: - An `Authorization` header on a deployment where bearer auth is not enabled (`bearer authentication is not enabled`). - A bearer token that fails verification (`invalid or expired session`), or whose token/session has been revoked (`session has been revoked`). - An incomplete or wrong API-key header set. Sending *any* of `X-Client-Id`, `X-Api-Key`, `X-Api-Secret` commits the request to the API-key path, so a partial set is rejected rather than silently degrading to anonymous limits (`valid X-Client-Id, X-Api-Key, and X-Api-Secret headers are required`). - No credential material at all while the anonymous free tier is unavailable — switched off for the deployment, forced off through the runtime kill switch, or not yet resolvable on a replica that has never read the flag (it fails closed).
- `403`: API key presented from a source IP not in that credential's whitelist.
- `404`: No resolution state row for this market (or, for CTF venues, no on-chain condition id mapping was found).
- `429`: Two different gates return this status, both with `code: rate_limited`: - **Per-credential (or per-IP, when anonymous) weighted budget exhausted.** The message is `rate limit exceeded`, or, for anonymous callers, `anonymous rate limit exceeded — request an API key for higher limits (…)`. `Retry-After` is the whole number of seconds until the current one-minute window rolls over, floored at 1. All four `X-RateLimit-*` headers are present. - **Per-IP admission gate.** An in-process, pre-authentication guard that keeps a flood off the shared credential cache and database. The message is `too many requests from this address` and `Retry-After` is a flat `60`. Because this fires *before* authentication, the response carries **no** `X-RateLimit-*` headers at all.
- `500`: The resolution status query failed.
- `503`: The rate limiter is unreachable. Fails CLOSED — the request is rejected rather than let through unmetered.

---

[API](https://skmtc.dev/kairos/apis/kairos-market-data-api.md) - [All operations](https://skmtc.dev/kairos/apis/kairos-market-data-api/llms.txt) - [OpenAPI document](https://skmtc.dev/kairos/apis/kairos-market-data-api/revisions/01e987f59a04?raw)