Polymarket Up/Down Markets: Slugs, Resolution and the Order Book 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 what survives it.

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. If you have a slug in hand and want its outcome, paste it into the market lookup.

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.
• Resolution runs on a Chainlink TWAP, not a snapshot. Since 7 August 2026 crypto Up/Down markets settle on a time-weighted average rather than a single price at the bell, and since 14 August all 5-minute markets use a 60-second window (it was 30 seconds for the week in between). Both the price to beat and the settlement price come from that TWAP. This changes the endgame materially: a spike in the final ten seconds barely moves a 60-second average, so late reversals are far weaker than they look on a spot chart.
• 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.

What Polymarket keeps after a market resolves

This decides whether you can research these markets at all. Polymarket keeps the market record and a thin price series after resolution. It does not keep the order book. We checked six resolved BTC 5-minute markets on 29 September 2026, from 4 days old to about six months.

TOK=<token_id_of_a_resolved_market>
START=1790466900          # the number at the end of btc-updown-5m-1790466900
END=$((START + 300))

# 1. The order book: gone, at every age we tried.
curl -s "https://clob.polymarket.com/book?token_id=$TOK"
# {"error":"No orderbook exists for the requested token id"}     HTTP 404

# 2. The price series: thin, but there if you give it a window.
curl -s "https://clob.polymarket.com/prices-history?market=$TOK&startTs=$START&endTs=$END&fidelity=1"
# {"history":[{"t":...,"p":0.365}, ...]}          6 points for this 5-minute market

# 3. The same call with interval=max: empty for the six-month-old market we tried.
curl -s "https://clob.polymarket.com/prices-history?market=$TOK&interval=max&fidelity=1"
# {"history":[]}                                                  HTTP 200

So the price series is not gone, but it is thin. For btc-updown-5m-1790466900 Polymarket returned six points, from 11 to 316 seconds after the window opened, and the final minute got one of them. PolyTest holds 2,552 snapshots of the same market, about one every 0.12 seconds, each with the book on both sides. One price a minute is enough to see who won and roughly when the price moved. It cannot tell you what a 500-share order would have filled at, and it barely covers the last minute, where these markets are decided.

Polymarket's newer Data API has a second route, GET /v2/prices-history, that returns 60-second buckets. In our test it had data for markets up to 8 days old and nothing for markets 15 days or older, so it is no substitute for an archive.

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 Polymarket does not keep: 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.

Recording what Polymarket does not keep

The only way around a missing order book is to have recorded it while the market ran. 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: 240M+ 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 3-day free trial if you want to check the data before committing to anything.