Polymarket Up/Down Markets: Slugs, Resolution and the Data Cliff

Polymarket's crypto Up/Down markets settle every five minutes, run around the clock, and turn over serious volume — the single five-minute BTC market used as the example below traded $638,615. They are the closest thing prediction markets have to a high-frequency instrument.

They are also the hardest markets on the platform to study, for a reason that has nothing to do with their design and everything to do with what happens to them after they close. This post covers all three parts: reading the slugs, understanding resolution, and the data cliff.

Decoding the slug

Every Up/Down market has a slug in a fixed, entirely predictable format:

{coin}-updown-{timeframe}-{unix_start}

btc-updown-5m-1775181000
│   │      │   └── Unix timestamp: window START, in UTC
│   │      └────── Timeframe: 5m | 15m | 1h | 4h | 24h
│   └───────────── Always "updown"
└───────────────── Coin: btc | eth | sol | xrp | doge | bnb

That trailing integer is the useful part. It is the Unix timestamp of the moment the trading window opens, in UTC. Decode it and you know exactly which five minutes the market covers:

from datetime import datetime, timezone

slug = "btc-updown-5m-1775181000"
coin, _, timeframe, ts = slug.split("-")

start = datetime.fromtimestamp(int(ts), tz=timezone.utc)
print(coin.upper(), timeframe, start)
# BTC 5m 2026-04-03 01:50:00+00:00

# The market's own title renders this in US Eastern:
# "Bitcoin Up or Down - April 2, 9:50PM-9:55PM ET"

Because the format is deterministic, you can construct slugs rather than search for them. Every 5m BTC market starts on a five-minute boundary, so the slug for any window is btc-updown-5m- plus that boundary's Unix timestamp.

How resolution works

The mechanics are deliberately simple. The market asks whether the coin's price at the close of the window is higher than at the open. Two outcomes, Up and Down, and one of them settles at $1.

A few consequences of this design that matter for anyone modelling these markets:

• Ties resolve Down. The question is whether the close is higher than the open. Not higher — including exactly equal — is Down. On a 5-minute window this is rare but not negligible, and it introduces a small structural asymmetry that a naive coin-flip model misses.
• The reference price is not the exchange price you are watching. Resolution uses a designated reference feed, not whatever your terminal shows. Basis between your feed and the settlement feed is a real source of backtest error near the boundary.
• Probability compresses hard as expiry approaches. With sixty seconds left and the coin flat, both sides converge toward 50¢ and the spread does the deciding. With ten seconds left after a decisive move, one side is pinned at 97–99¢ and there is almost nothing left to trade.
• The spread is the whole game. A quoted 0.01 spread on a market that pays $1 is a 1% round-trip cost on a binary outcome. Most strategies that look profitable on mid-price are not profitable after crossing it — see below.

The data cliff

Here is the part that determines whether you can research these markets at all. When an Up/Down market resolves, its trading history becomes unavailable through Polymarket's public API. Not deprecated, not paginated, not behind a paid tier — gone.

You do not have to take this on faith. Two commands reproduce it against a real resolved market:

TOK=43327618351213667646391460691177105630991180325414735346402735306929604801558

# 1. The order book for a resolved market — gone.
curl -s "https://clob.polymarket.com/book?token_id=$TOK"
# {"error":"No orderbook exists for the requested token id"}     HTTP 404

# 2. Surely the price history survives? It does not.
curl -s "https://clob.polymarket.com/prices-history?market=$TOK&interval=max&fidelity=1"
# {"history":[]}                                                  HTTP 200

That second result is the one people find hardest to believe. /prices-history returns 200 OK with an empty array — a successful response containing nothing. There is no error to catch and no status code to branch on. A pipeline that assumes 200 means data will silently record zero rows and carry on.

Why base rates are not enough

A common instinct at this point: if outcomes are retrievable, why not just study resolution frequencies? Count how often 5m BTC resolved Up over the last thousand markets, find a skew, trade it.

The problem is that any such skew is quoted into the price long before you see it. If SOL 5m markets resolved Up 52% of the time last month, market makers know, and Up opens at 52¢. The base rate is not an edge; it is already in the price. What you would need in order to find an edge is the thing that got deleted: what the book looked like when the price was wrong.

This is the honest reason Up/Down strategies are hard to validate. It is not that the markets are efficient — it is that the evidence required to test the claim either way is not in the API.

Working with the data that does survive

The only way around a data cliff is to have recorded the data before it fell off. That is what PolyTest does: continuous point-in-time snapshots of Polymarket crypto Up/Down markets, captured while they run and kept after they resolve — 90M+ snapshots with 8 levels of book depth per side and sub-second timestamps.

import os, requests

BASE = "https://api.polytest.io/api/v1"
H = {"X-API-Key": os.environ["POLYTEST_KEY"]}

# Resolved markets are still here — that is the whole point.
markets = requests.get(f"{BASE}/markets",
                       params={"coin": "sol", "market_type": "5m", "limit": 50},
                       headers=H).json()["markets"]

for m in markets:
    snaps = requests.get(f"{BASE}/markets/{m['id']}/snapshots",
                         params={"include_orderbook": "true"},
                         headers=H).json()["snapshots"]

    # The final minute is where 5m markets are actually decided.
    endgame = snaps[-12:]
    for s in endgame:
        print(m["slug"], s["timestamp"], s["midPrice"], s["spread"])

Three things worth testing

1. Does your edge survive the spread? Re-run any promising result using the actual ask you would have lifted instead of mid-price. On a 1¢ spread in a $1 market this frequently converts a winning strategy into a losing one. Do this first — it kills most ideas cheaply.
2. How does depth behave in the last 60 seconds? Up/Down markets thin out dramatically near expiry. A size that fills at 3 minutes remaining may not fill at 30 seconds, and that is invisible in any mid-price series.
3. Does anything transfer across coins? BTC, ETH and SOL 5m markets share a design but not a liquidity profile. A strategy tuned on BTC's book frequently falls apart on SOL's thinner one — which is worth knowing before you fund it, not after.

The backtesting guide covers fill simulation in more depth, and there is a free tier if you want to check the data before committing to anything.