Coder Legion - Recent posts tagged polymarket

We ran an AI agent swarm on Claude Opus for $98. A single 2.5-cent call gave the same forecast

Mon, 26 Oct 2026 12:45:42 +0000

Multi-agent swarms are a popular way to get "more than one model" out of an LLM: generate dozens of personas from your documents, let them post and argue on a simulated social network, then read off what the crowd thinks. We tested one, the open-source MiroFish engine, as a forecaster on four live Polymarket markets, with Claude Opus 5.5 behind every agent. The full results are on our blog, and every forecast, prompt, seed file and persona correction is on GitHub.

Short version: the swarm landed 0 to 3 points from one direct Opus answer on all four markets, at 500 to 900 times the cost. This post is about how to evaluate an agent swarm so you can see that, and four things we would check in any multi-agent setup.

1. Always run the single-call baseline

The most important number in the whole test was not a swarm output. It was the same model asked the same question directly, with the same seed files and instructions, five times, median taken:

Market	Swarm on Opus (median agent)	Opus asked directly	Polymarket
Toronto mayor: Chow wins	52	49	65.5
Israel: Likud most seats	40	38	30.5
Bank of Canada holds	45	45	18.7
US x Iran: no strike	85.5	84	82.5

Without the baseline, a swarm result looks like an emergent crowd opinion. With it, you can see the crowd is the base model's view of the evidence, re-voiced 34 to 56 times. Sonnet showed the same pattern (50 vs 52, 49.5 vs 50).

In our first round, repeat runs of the same setup moved the median by up to 10 points, so a 0 to 3 point gap is noise. One run per configuration is a real limitation; we spent the budget on Opus instead of repeats.

Why it happens: every persona is written by the same model from the same documents. The agents share the same facts, framing and blind spots. Diversity of roles is not diversity of information.

2. Poll the agents, don't trust the summary

MiroFish ends a run with a report agent that writes a summary and its own probability. On the Bank of Canada market, three report agents said 89 to 93, and the Opus report had a chapter titled "Agent Consensus: Banks and Economists Converge on 'No Move'".

We asked each agent directly instead. Median: 45. Only 13 of 34 agents put YES above 50.

The cause was mundane: the report agent tries to interview the agents, but by then the simulation had shut down, so it wrote from the knowledge graph built from the seed files and never saw the agents' answers. If a framework gives you a "consensus" summary, check that it actually read the outputs it claims to summarize.

3. Validate generated personas against the source

Before each run we compared every generated persona with the seed files, first with a second model, then by hand. Opus 5.5 still produced about 130 factual errors across four markets. Several hit the exact fact a market resolves on:

six Israeli personas moved the election to November;
three reversed a poll result (the seeds had Eisenkot ahead of Netanyahu 49 to 41);
several said the Bank of Canada had just hiked, mixing it up with the Fed and the ECB;
one poll's district sub-result became its overall result in five personas;
the generator created an account for a mayoral campaign of a person who wasn't running.

It also liked to end the simulation setup with a verdict ("the narrative should drift toward cautious confidence that the pause holds"). That is the generator steering the outcome before any agent speaks. We removed those sentences and 11 opening posts with wrong facts or ready-made conclusions, and published originals and fixes.

One way to make this routine: for every persona, extract its factual claims as a list, check each against the seed files, and flag anything not supported. A cheaper model is fine for the first pass; a human for anything that touches the resolution criterion.

4. Meter the real cost, and cache

Every agent re-sends its persona, tool list and history on every turn, so cost grows fast with agents times rounds.

	Toronto	Likud	Bank of Canada	US x Iran
Agents	36	56	34	52
Swarm run on Opus 5.5	$13.73	$24.00	$13.63	$18.91
Swarm run on Haiku 5.5	$0.23	$0.56	$0.27	$0.45
Five direct Opus answers	$0.13	$0.14	$0.13	$0.12

Prompt caching cut the Opus bill by about 40%; without it a run would have been $23 to $40. The whole round, with preparation and persona checks, was $98.56.

Also worth doing: lock the forecasts publicly

A forecasting test is only honest if the numbers are fixed before the outcome. We pushed forecasts.csv to GitHub before any market resolved, and GitHub's event log records the push time. The scorecard (Brier score and absolute error per source, including the market price) comes after the last market closes on October 31.

What this does not show

Four markets this round, eight across two rounds: an illustration, not a ranking. One run per configuration. Hand-corrected personas, so an uncorrected swarm might behave differently. Accuracy comes after resolution.

The takeaway so far: putting a frontier model behind every agent did not make the swarm a different forecaster from the model it runs on. If you want what the model thinks, ask it once.

Originally published on orcalayer.com. OrcaLayer is an independent Polymarket analytics provider, not affiliated with Polymarket.

We pre-registered a Polymarket insider score. It passed, and we still didn't ship it

Thu, 22 Oct 2026 09:55:28 +0000

Polymarket insider trading makes headlines every few weeks, so an insider score sounds like an obvious feature for a Polymarket analytics site. We built one, called it the Early score, wrote the rules down before running it, and tested it on 355,732 wallets. It passed its own test, and we did not release it. The full results are on our blog and the aggregated data and a script are on GitHub.

This post is about the method: how to set up a wallet score so the test can actually fail, the traps we hit before the test, and the check that changed our mind.

1. Write the rules down first

Before computing a single score, we put the whole method in a pre-registration file: what an entry is, how the move is measured, the shrinkage constant, which markets are out, which periods are compared, and what counts as a pass. Every later change went in as a dated line with the reason.

The pass rule was simple: score wallets on October 2025 to March 2026 (period A), and the top 10% must still be positive on April to September 2026 (period B), also without the 5 largest events.

Without this file it is very easy to keep adjusting until something works. With it, every change you make has to be justified in writing before you see the outcome.

2. The score

If a wallet knows something first, the price should move its way after it trades. So for each entry we measured the price of the side the wallet holds 24 hours later, minus the price it paid, in cents. A wallet's score is the size-weighted average, pulled toward zero for wallets with few entries:

def shrunk_mean(moves, weights, k=5.0):
    """Size-weighted mean move, shrunk toward 0.
    weights are entry sizes capped at $10,000, so n_eff counts 'effective entries'."""
    total_w = sum(weights)
    if total_w == 0:
        return 0.0
    raw = sum(m * w for m, w in zip(moves, weights)) / total_w
    n_eff = total_w ** 2 / sum(w * w for w in weights)
    return raw * n_eff / (n_eff + k)   # 5 effective entries keep half the raw mean

Wallets within 1 cent of zero (one price tick) get a neutral 50; the rest become a percentile. Sports and short Up or Down markets are out: a day after a match the price is the result, so the score would just rank sports bettors.

3. Trap: wallets trading with each other at made-up prices

On one test day the top of our list was a group of related wallets passing the same shares back and forth in finished tennis matches. One bought at 0.02 and sold to a partner at 0.96 four minutes later. Read trade by trade, that is a +94 cent entry.

The fix was to define an entry as a wallet's net position change in one market over one UTC day, not as a single trade:

from collections import defaultdict

def daily_entries(trades):
    """Simplified. trades: dicts with wallet, market, day, side ('YES'/'NO'), shares (+buy/-sell), price.
    Selling NO counts as buying YES. A same-day round trip nets to zero."""
    net = defaultdict(lambda: {"yes": 0.0, "no": 0.0, "cost_yes": 0.0, "cost_no": 0.0})
    for t in trades:
        k = (t["wallet"], t["market"], t["day"])
        s = "yes" if t["side"] == "YES" else "no"
        net[k][s] += t["shares"]
        net[k]["cost_" + s] += t["shares"] * t["price"]
    for k, v in net.items():
        delta = v["yes"] - v["no"]
        if delta == 0:
            continue
        side = "yes" if abs(v["yes"]) >= abs(v["no"]) else "no"
        avg_price = v["cost_" + side] / v[side] if v[side] else None
        yield k, delta, avg_price

If you rank Polymarket wallets by anything trade-based, expect these pairs near the top of your list.

4. Trap: a thin "price after"

In one market a handful of trades of $1.50 to $15 at 0.15 set the price 24 hours later, though the market settled at 1. One tiny trade can fake a move. We now require at least $100 of other wallets' trades in that hour before using a price, and fall back to the final price only if the market has closed.

5. The test passed

Period A groups, measured on period B, with t-statistics clustered by event (many entries in one event are not independent):

Group from period A	24 h move in B, cents per entry	t
Top 10%	+0.83	7.9
Bottom 10%	-0.76	-4.7
All wallets	-0.01	-0.2

It held without the 5 largest events, without weather markets, and for every shrinkage constant from 0 to 100. By the rule we wrote, a pass.

6. The check that changed our mind: look at the mechanism

A pass tells you the score finds something that repeats. It does not tell you what. An insider and a wallet that simply buys cheaper both show a positive move, but with a different shape:

news spreading: the price keeps moving for hours;
a cheap fill: the gap is there at once and stops growing.

So we split each wallet's move into the first hour and the drift from 1 to 24 hours, and asked which part repeats between the two periods:

from statistics import correlation  # Python 3.10+

def ranks(xs):
    order = sorted(range(len(xs)), key=xs.__getitem__)
    r = [0] * len(xs)
    for i, j in enumerate(order):
        r[j] = i
    return r

def spearman(a, b):
    return correlation(ranks(a), ranks(b))

# per wallet, period A vs period B
rho_first_hour = spearman(first_hour_A, first_hour_B)   # 0.138
rho_drift      = spearman(drift_A, drift_B)             # 0.050

The top 10% were already +0.75 cents ahead after one hour and +0.83 after 24. The first-hour part repeats; the drift, the part an insider score exists to catch, barely does. The score was ranking wallets by fill quality.

This check was not in the pre-registration, and we label it exploratory everywhere. But it is the one that decided whether a label like "insider" would tell users the truth. It would not, so the score is not on the site, in the API or in MCP.

7. Money, not moves

A 24-hour move is not profit, so we also held every entry in a resolved market to settlement and subtracted the fee each wallet actually paid on-chain. The top 10% made +1.17 cents per entry after fees (t 2.9), on both mostly taker and mostly maker entries. One detail that matters if you repeat this: compare groups with all wallets, not with zero. On longer-dated markets every group drifts up, so zero is the wrong baseline.

Reproduce it

The repo has the aggregated tables behind every number and scripts/early_score_check.py (standard library only), which rebuilds entries, scores and the period test from the OrcaLayer API:

export ORCALAYER_API_KEY=sk_orca_...        # never commit it
python3 scripts/early_score_check.py --csv entries.csv        # first 1,000 markets of data/markets.csv
python3 scripts/early_score_check.py --load-csv entries.csv   # rerun the analysis, no API calls

The API's trade history starts on May 1, 2026, so the script scores on May and June and checks on July to September, on a fixed list of 1,000 markets. The script writes wallets only as salted hashes, and the repo publishes groups only, no addresses.

What this does not show

Sports, individual wallets, and copying these wallets (a copy trades after them and does not get their price). On the shorter API check, the groups did not separate when held to settlement, so treat the money part as the weakest result.

Originally published on orcalayer.com. OrcaLayer is an independent Polymarket analytics provider, not affiliated with Polymarket.

Backtesting live football on Polymarket: 6 traps in a recorded order book

Wed, 14 Oct 2026 11:44:45 +0000

We recorded the order book of every Polymarket football (soccer) market for three weeks and tested two in-play ideas: buying a team right after a late price jump at a level score, and protecting goal bets with a stop-loss. Neither paid. Buying the jump 2 seconds later lost $2.85 per $10 over 837 jumps (t -7.9), and every one of 28 stop settings did worse than holding on the replay. The full results are on our blog and the data is on GitHub.

This post is about the data side: six traps we hit while building the test. Most of them will bite anyone who backtests in-play markets on Polymarket.

1. You have to record the book yourself, then check the recording

Public Polymarket APIs give you trades and the current book, not the book as it was a second ago. For an in-play test you need the best bid and ask around every event, so we recorded the CLOB WebSocket market channel (book, price_change, last_trade_price) with exchange timestamps.

Before using it, check it against on-chain trades. Ours had 99.9% of on-chain trades, and 97.6% of them happened at the best price the recording showed at that moment. If your numbers are much lower, your replay will invent fills.

2. Events arrive out of order

The exchange can send the price_change for a level that a trade just ate before the last_trade_price of that same trade. Read events in arrival order and fills look about 25% worse than they were. Put each trade ahead of the book change it caused before you measure anything.

3. The mid is not a price you can trade

Our first detector watched the mid-price: if a team's mid jumps by 0.25 or more late in a level match, call it a goal. Many of those "goals" were sellers pulling their quotes. The mid doubles, the bid stays where it was, and the spread opens up.

One example from the data: the mid went from 0.24 to 0.505 in seconds, but the ask was 0.78 and the bid about 0.23. A bot buying 2 seconds later paid 0.81. Ten seconds after the jump the ask was back at 0.25, and the match ended in a draw.

Store the ask and the spread, not only the mid. The implied bid is easy to get back if you only kept mid and ask:

def spread_at_jump(mid: float, ask: float) -> float:
    bid = 2 * mid - ask          # implied bid
    return round(ask - bid, 2)   # e.g. mid 0.505, ask 0.78 -> 0.55

In our data 627 of 837 late jumps had a spread of 20 cents or more, and the jumping side won only 36% of those.

4. The "level score" can be fake too

Our rule also needed the draw to be the favorite 30 seconds before the jump. That condition is read from mids as well, so pulled quotes can fake it in a match one team already leads. When all three books of a 1X2 match are two-sided, the three mids add up to about 1.00. Check that before you trust the state:

def book_looks_clean(home_mid: float, draw_mid: float, away_mid: float) -> bool:
    return 0.95 <= home_mid + draw_mid + away_mid <= 1.05

In 51 of the 85 jumps that had a tight spread, the three mids before the jump added up to more than 1.10. One of them was a team that had led for 20 minutes: its bid disappeared for a moment, the score looked level, and the bid coming back looked like a late goal.

5. Daily batch files overlap

We ran the scan one day at a time, and each day file also covered the first hours after midnight UTC. Jumps after midnight landed in two files: 48 duplicates out of 885 raw rows. They did not change the conclusion, but they would have inflated every count and t-statistic. If you split a time series by day, check the joins.

6. The fastest entry is not reachable

Football markets have secondsDelay: 1 in the Gamma API: a taker order waits a second before it can match, and you cannot cancel it during that time. So a result "at +0 s" is not a strategy, it is a plot point. In our test the earliest entries lost the most (-$4.21 per $10 at +0 s, -$2.85 at +2 s), because the first seconds after a jump are when the price is most wrong in the direction you are buying.

The same delay hurts stops. Polymarket has no stop orders, so a stop is a bot watching trades and then market-selling after the delay, paying the taker fee a second time. In live football prices swing several cents within minutes, and a 3-cent stop fired on 86 to 96% of our replayed bets.

Reproduce it

The repo has data/late_goal_jumps.csv (one row per jump, with the asks 0 to 60 seconds after it and the result) and a standard-library script that recomputes every late-goal number:

python3 scripts/summarize_late_goals.py data/late_goal_jumps.csv

METHOD.md describes the recorder, the detection rule and each trap above in more detail.

What this does not show

About three weeks of football, mostly club leagues. Pre-match markets, other sports and stops on strategies whose entries already make money were not tested. Bets in the same match are not independent, so read t values near 2 with care.

Originally published on orcalayer.com. OrcaLayer is an independent Polymarket analytics provider, not affiliated with Polymarket.

Backtesting a Polymarket copy trading bot without fooling yourself

Sat, 10 Oct 2026 13:28:30 +0000

Copy trading is the most common bot idea on Polymarket: find the wallets that win and buy what they buy. We tested it on five sports (MLB, NFL, college football, League of Legends and Valorant) and it did not survive. The full results are on our blog and the data and script are on GitHub.

This post is about the backtest itself: how to set it up so it can tell you "no", and the one mistake that makes almost every copy bot backtest look better than it would be live.

1. Define a copy you could actually execute

A "copy" in our test is a wallet's first buy of at least $20 in a market, at a price between 0.30 and 0.85. We buy the same outcome for $10 at the wallet's price plus 1 cent, pay the sports taker fee and hold to resolution. Roughly, in code:

def copy_result(price: float, won: bool, stake: float = 10.0, slip: float = 0.01) -> float:
    p = price + slip                      # you never get the whale's exact price
    shares = stake / p
    fee = shares * 0.05 * p * (1 - p)     # Polymarket sports taker fee
    payout = shares if won else 0.0
    return payout - stake - fee

One cent is generous. In fast in-play markets the price moves much further before a copy fills. We also reran MLB at +3 cents: every result went negative, including the top 10.

2. Pick on one period, measure on the next

The rule: rank wallets by their copy results over the two months before the test month, then copy only in the test month. Nothing from the test month touches the selection. We used three rules fixed before the run:

ALL10: every wallet with at least 10 copies (the "average whale")
POS: at least 20 copies, mean above zero, t-statistic of 2 or more
TOP10: the 10 best by t-statistic

MLB, top 10, per $10 copied:

Test month	While picked	Month after
July 2026	+$3.65	+$0.16
August 2026	+$3.06	-$0.04
September 2026	+$2.72	-$0.47
Oct 1-4 2026	+$3.78	-$2.23 (n 7)

The same rule that showed +$3 in the pick window showed about zero the month after.

3. Check whether rank carries over at all

Before tuning thresholds, check if past performance predicts future performance for individual wallets. For MLB wallets with at least 10 copies in both periods, the Spearman correlation between the pick months and the next month was -0.01, +0.15, +0.08 and -0.03. NFL was between -0.09 and +0.03.

With correlations like that, picking "the best" is picking the luckiest. With thousands of active wallets, dozens will have a great two months by chance.

4. Look at the baseline before the winners

The average MLB whale, copied one cent worse than its own price, lost 31 to 63 cents per $10 in every test month. If the baseline is negative, a selection rule has to beat a loss before it makes anything. Check ALL10 first.

5. The trap: wallet labels computed today

This one is easy to miss. Analytics sites (ours included) label wallets: "smart money", "50+ resolved markets", win rate, profit factor. Those labels are computed today, on each wallet's full history, including the months you are about to backtest.

If you pick wallets with today's labels and backtest them on last summer, the selection already knows who survived. Wallets that blew up are not labeled "smart", so the backtest never copies them. It will always look better than it would have live.

We hit a mild version of this ourselves: one filter in our profile screen used each wallet's share of activity in the sport on its full history. We disclosed it in the methodology. It most likely flatters the pools, and they still showed no edge.

Rule of thumb: every feature used to pick a wallet must be computable from data strictly before the pick date.

6. Make it reproducible

The repo has scripts/copy_backtest.py (Python 3.9+, standard library only) that runs the same walk-forward on the OrcaLayer API for any league:

export ORCALAYER_API_KEY=sk_orca_...        # never commit it
python3 scripts/copy_backtest.py --league mlb --start 2026-05-01 --end 2026-09-30 --max-markets 800

To check that the API path and our internal database agree, we ran both on the same 800 MLB games: 161,094 copies in both, every wallet, price and result equal, total -$83,012.60 in both. The script output showed the same picture: top 10 from about +$3 per $10 to between -$1.29 and +$1.06 the month after.

The script needs a Premium API key. If you just want to look at a wallet's record before copying it, the free OrcaLayer MCP server works from Claude without a key.

What this does not show

Five sports, and picking by past results only. Slower markets like politics, where informed money can stay ahead for days, and picking wallets by how they trade rather than how much they made, were not tested.

Originally published on orcalayer.com. OrcaLayer is an independent Polymarket analytics provider, not affiliated with Polymarket.

6 things that broke our Polymarket trading bot before it made a dollar

Wed, 07 Oct 2026 12:47:20 +0000

We spent a few weeks trying to build a profitable Polymarket bot. Arbitrage between linked markets, in-play market making, copying wallets that trade before goals, betting against miscalibrated prices. We recorded the full order book for every football market, indexed on-chain trades and replayed each idea.

None of them made money. The full research with numbers is on our blog, and the CSVs are on GitHub.

This post is the engineering side: six things about the Polymarket API and our own pipeline that would have broken the bot even if a strategy had worked.

1. Your taker order waits a second, and you can't cancel it

Sports markets have a field in the Gamma API called secondsDelay. Football is 1, NBA is 0. You can see it on any event:

GET https://gamma-api.polymarket.com/events?slug=fif-sri-mri-2026-10-05
... "secondsDelay": 1 ...

Per the Order Lifecycle docs, a marketable order waits out that delay before matching, and "during either delay, the order is pending and cannot be canceled". Resting limit orders can still be cancelled. Some crypto and finance up/down markets have a 250 ms version of the same thing.

What it did to us: our arbitrage detector found 369 mispriced sets across linked football markets in 18 hours. Of the 2c+ ones we rechecked one second later, all legs were still in the book in 3, worth $1.83 total. Makers pull their quotes inside your delay, or a faster taker takes the legs. If your bot sees a price and hits it, check secondsDelay first.

2. Fees are not a percentage

Only takers pay, and the fee depends on price:

def taker_fee(shares: float, price: float, fee_rate: float) -> float:
    # fee_rate from Gamma feeSchedule.rate, e.g. 0.05 for sports
    return shares * fee_rate * price * (1 - price)

It peaks at 0.50 (p * (1 - p) = 0.25) and goes to zero near 0 and 1. A 1c edge on a 50c contract is mostly eaten. Rates and maker rebates are in the fees docs.

3. The mempool gives you nothing

Orders and cancels are off-chain (EIP-712 signatures), only the settlement goes to Polygon. We measured:

Source	Lag behind matching
Order book WebSocket	~17 ms
On-chain settlement	~2 s median

By the time a trade shows up in the Polygon mempool, it already happened and the book already moved. Watch the WebSocket, not the chain.

4. WebSocket events arrive out of order

The exchange can send price_change (a level got eaten) before the last_trade_price event of the same trade. We replayed fills in arrival order at first, and every fill looked about 25% worse than it really was. Sort by the trade, not by arrival time, before you trust any replay.

For what it's worth, a plain WebSocket recorder (price_change, book, last_trade_price with tx hash) captured 99.9% of the trades that later appeared on-chain, so you don't need anything fancier to build a replay dataset.

5. Your backtest can lie with perfect data

This one wasn't the API, it was us. We picked wallets that bought right before goals and simulated copying them 1-5 seconds later: +$4.23 per $10. Then we noticed we had only selected the buys that came right before goals. In real time you don't know which buys those are.

Rerun on every buy by the same wallets, without looking at the outcome: -$0.41 per $10.

Any filter that uses something you only learn later (a goal, a resolution, a price move) has to be removed from the selection step. If the result survives that, then you can start believing it.

6. Some "Polymarket bot" repos want your private key

Before you reach for an existing open-source bot:

StepSecurity found 20+ fake repos with bought stars (polymarket-trading-bot-new, polymarket-copy-trading-bot-sports, ...) pulling typosquatted npm packages that steal keys and .env files.
SafeDep found 9 npm packages (polymarket-bot, polymarket-claude-code, ...) that ask you to paste your wallet key.

Read the code and the dependency tree before anything touches a funded key.

Smaller Gamma API notes

offset pagination returns 422 somewhere after 2,100-2,500 records. Use the keyset endpoints for a full crawl.
/events/keyset ignores the negRisk filter, filter on the market field instead. /markets/keyset respects end_date_min / end_date_max.
Some requests fail without a User-Agent header.

The data is CC BY 4.0. If you're building something on Polymarket and want to check our numbers, the repo has every CSV, and we'd like to hear where we got it wrong.

Originally published on orcalayer.com. OrcaLayer is an independent Polymarket analytics provider, not affiliated with Polymarket.

Polymarket Gamma API endDate Is Not the Resolution Deadline

Thu, 24 Sep 2026 17:36:25 +0000

Checked against the Polymarket Gamma API on 24 September 2026.

Short answer. OrcaLayer compared the endDate field with the written rules on 23 Polymarket markets. Polymarket's documentation describes a market's end date as the point when it becomes eligible for resolution. The field did not behave that way on sports markets: on NFL and soccer matches it was the kickoff, on esports the start plus 6 hours, on tennis the original start plus 7 days. The deadline that governs a market is in its description, and whether it still trades is in closed and acceptingOrders.

If you build on Polymarket data, this changes what your code should read. A bot that stops trading at endDate, a dashboard that counts down to it, and a model that treats it as the resolution time are all reading a field that means different things on different market types.

What is endDate in the Polymarket Gamma API?

endDate is a UTC timestamp on every market in the Polymarket Gamma API. The API does not document what it represents, and it is not the resolution deadline. In OrcaLayer's sample it was kickoff on NFL and soccer matches, start plus 6 hours on esports, and original start plus 7 days on tennis. The binding deadline is in description.

Every market returned by https://gamma-api.polymarket.com/markets/{id} carries endDate at the top level. If you are new to these endpoints, start with our Polymarket REST API guide for developers.

The response usually tells you what kind of market you are looking at. Sports matches carry gameStartTime, eventStartTime, gameId and sportsMarketType (for example "moneyline"). Markets that belong to a group carry groupItemTitle, which can be a label such as "Match Winner" or a date such as "September 30". Closed markets add closedTime and umaEndDate. The rules are in plain English in description.

Polymarket's own resolution documentation puts it plainly: "Always read the resolution rules before trading." The rest of this article shows what happens when code reads endDate instead.

Polymarket endDate by market type

Market type	Markets	What endDate was	What the rules say	Closed before or after endDate
Esports (CS2, LoL, Dota 2)	4	Scheduled start + exactly 6 hours, 4 of 4	A postponed match must be rescheduled to start within 14 days, or the market resolves 50-50	All 4 before, by 19 minutes to 3 h 18 min
Tennis (ATP, ITF)	4	Original scheduled start + exactly 7 days, 4 of 4	A winner must be determined within 14 days, or the market resolves 50-50	All 4 before, by 6.3 to 6.8 days
NFL, college football, soccer matches	4	Kickoff, 4 of 4	No fixed deadline: open until the game is completed	All 4 after, by 2 h 17 min to 4 h 57 min
MLB match	1	Start + 7 days	No fixed deadline	Before, by about 7 days
Sports futures	3	Varies	A "postponed after" backstop	Still open
Deadline and price markets	7	Matched the rules in 4 of 7	"By" a date, or a date in the title	Mixed

The sample is 23 hand-picked markets covering each type, so read each row as an observed pattern, not a platform-wide rate.

Esports: endDate is the start plus six hours

All four esports matches had an endDate exactly six hours after gameStartTime. The Counter-Strike match between QUAZAR and Misa Esports started at 08:00 UTC on 23 September, carried an endDate of 14:00 UTC, and closed at 13:41 UTC.

Six hours is a fair guess for when a best-of-three finishes, but the rules for the same market allow far longer:

If the match is postponed, it must be rescheduled to a start time on or before October 7, 2026 at 11:59 PM ET (14 calendar days after the originally scheduled start of September 23, 2026 at 4:00 AM ET). If, by that deadline, the most recently announced rescheduled start time is on or before the deadline, this market resolves based on the result of the match as played. Otherwise, this market resolves 50-50, regardless of whether the match is subsequently played.

The 14 days apply to the rescheduled start, not to the result. A match rescheduled to start on 7 October can resolve later still, long after endDate has passed. You can see current esports markets on OrcaLayer's esports page.

Tennis: seven days after the original schedule, and it does not move

Every tennis match in the sample had an endDate exactly seven days after its originally scheduled start. Here the 14-day rule applies to the result:

If the match is canceled (not played at all), ends in a tie, or a winner has not been determined by October 6, 2026, 11:59 PM ET (14 days after the scheduled start), this market will resolve to 50-50.

Rescheduling is where it goes wrong. In two ATP matches, gameStartTime was later than the start printed in the rules. The US Open match between Ben Shelton and Carlos Alcaraz was scheduled for 8 September at 15:30 UTC and started on 9 September at 03:00 UTC. Its endDate was 15 September at 15:30 UTC: seven days after the original slot, not the new one.

A countdown built on endDate for a tennis market counts from a schedule that may no longer exist. Take the start from gameStartTime and the deadline from the rules.

NFL and soccer markets: endDate is kickoff, not the end of the game

On the Broncos vs Chiefs NFL game, the SMU vs Louisville college football game, a La Liga match and a Romanian Liga I match, endDate was equal to kickoff to the second. All four markets closed after it, between 2 h 17 min and 4 h 57 min later, which is how long the games took.

The rules on these markets set no deadline at all:

If the game is postponed, this market will remain open until the game has been completed.

A kickoff is the one moment when a match market is certainly not ready to resolve. Code that compares the current time with endDate would have marked all four of these markets as finished at kickoff, while the games were being played and the markets were still trading.

Across the 16 closed markets in the sample, 6 closed after their endDate. Four were these matches. The other two were a Bitcoin price market that closed 14 minutes after its reference time and a Fed rate market, covered below.

Sports futures: sometimes the event, sometimes the backstop

League and tournament winner markets followed no single rule. On Shakhtar Donetsk winning the 2026-27 UEFA Champions League, endDate was 30 May 2027 at 23:59 UTC, while the rules fall back to "Other" only if the season is "postponed after June 19, 2027, 11:59 PM ET", about twenty days later. The New York Yankees World Series market had an endDate of 31 October 2026, and its rules allow postponement until 31 December 2026. The Boston Celtics NBA Finals market matched its rules to the minute.

For futures, the field alone does not tell you whether you are looking at an expected event date or the formal backstop.

Deadline markets: right in 4 of 7, once wrong by 92 days

Markets that ask whether something happens "by" a date came closest to what most people assume endDate means. Two of them, "Will Anthropic or OpenAI IPO first?" and the Clarity Act market, matched the deadline in the rules, one with a one-minute offset (05:00 instead of 04:59 UTC). The two Bitcoin price markets also matched, though their rules point to "the date specified in the title" or "the month specified in the title", so the deadline lives in the market name.

Three did not match:

"Will the US confirm that aliens exist by September 30?" The rules say "by September 30, 2026, 11:59 PM ET", which is 1 October at 03:59 UTC. endDate was 1 January 2027 at 04:59 UTC, 92 days later. That is exactly the endDate of the parent event the market belongs to, which runs to the end of 2026, so the market appears to carry its event's date rather than its own. Two other fields in the same response point the right way or the wrong way: groupItemTitle is "September 30", which matches the rules, and hasReviewedDates is true, which shows that a reviewed flag does not guarantee the date matches the rules.
The Fed rate market for the September 2026 meeting. endDate was 16 September at 00:00 UTC, which is 8 PM ET on 15 September, the evening of the first day of a two-day meeting. The market closed 20 hours after its endDate.
The market on the next Russian parliamentary election. endDate was 30 September 2026 at 00:00 UTC. The rules fall back to "Other" only if results are not known by 30 September 2027. The market closed on 21 September.

On grouped date markets, check groupItemTitle before you trust endDate.

Why endDate changes, and why the Gamma API returns old values

Two markets returned different endDate values depending on which snapshot the API served.

For the aliens market, a response with updatedAt of 21 September showed endDate as 1 October 2026 at 03:59 UTC, which matches the rules. A fresh response on 24 September showed 1 January 2027. For the IPO market, a response with updatedAt of 8 August showed 31 December 2027 at 00:00 UTC, 29 hours before the written deadline, and the fresh response showed 1 January 2028 at 04:59 UTC, which matches the rules. Between those snapshots, the IPO market was corrected and the aliens market moved 92 days away from its own rules.

updatedAt will not tell you when that happened. It changes often and in bulk: at one point on 24 September the aliens, IPO, Celtics and Bitcoin markets all carried the same updatedAt to the microsecond. Store your own fetch time instead.

The older values reached us through cached responses. In three cases in the sample, a plain request to /markets/{id} returned an older snapshot, and adding an unused query parameter returned the current one. If your code reads endDate once when a market is listed, it may be holding a value the platform has since changed.

endDate vs gameStartTime vs closedTime vs umaEndDate

Field	What it held in the sample	Safe use
`endDate`	Kickoff, start + 6 h, start + 7 days, or a deadline, depending on market type	A hint, never a deadline
`gameStartTime`	Start of the sports event, updated when a match was rescheduled	Event start
`closedTime`	When the market actually closed	After-the-fact close time
`umaEndDate`	Identical to `closedTime` on all 16 closed markets	Same as `closedTime`
`description`	The written rules, including any deadline in ET	The real deadline

The formats differ. gameStartTime and closedTime come as "2026-09-23 08:00:00+00", while endDate and eventStartTime use "2026-09-23T08:00:00Z". datetime.fromisoformat rejects both forms before Python 3.11, so normalize first:

from datetime import datetime

def parse_ts(s: str) -> datetime:
    """Parse any Gamma API timestamp into an aware UTC datetime."""
    s = s.replace(" ", "T").replace("Z", "+00:00")
    if s.endswith("+00"):
        s += ":00"
    return datetime.fromisoformat(s)

How to tell if a Polymarket market is still trading

Do not use endDate for this, and do not use active either. The closed CS2 market in the sample returned "active": true together with "closed": true and "acceptingOrders": false. Read closed and acceptingOrders, and for the resolution state read umaResolutionStatus, which was "resolved" on that market.

def is_tradable(m: dict) -> bool:
    return not m.get("closed") and bool(m.get("acceptingOrders"))

This is not bulletproof. In January 2026 a public report on Polymarket's Rust SDK repository showed finished Africa Cup of Nations markets still returning active=true, closed=false and acceptingOrders=true, with endDate equal to kickoff (issue #199). On our September sample the two flags were reliable, but treat them as the best signal available, not a guarantee.

Closing and resolving are separate steps. After a market closes, the outcome is proposed to the UMA Optimistic Oracle, and according to Polymarket's documentation an undisputed proposal resolves after a 2-hour challenge period.

How to find the real resolution deadline of a Polymarket market

Read description. That is the contract. Sports matches say "on or before … ET" or "by … ET (14 days after the scheduled start)". US match markets say they "remain open until the game has been completed". Futures say "postponed after …".
Check the title and groupItemTitle on price and date markets. "On September 17" or a groupItemTitle of "September 30" is the deadline.
Take the start from gameStartTime, not from endDate minus a guess.
Use closedTime or umaEndDate to know when a market actually closed. Both are empty until it does.
Re-fetch before you act. Add a cache-busting parameter and store your fetch time next to every value you keep.

Python: parse the resolution deadline from a market description

This parser found the deadline on every market in the sample whose rules state a full date and a clock time in Eastern Time:

import re
from datetime import datetime
from zoneinfo import ZoneInfo

MONTHS = "January|February|March|April|May|June|July|August|September|October|November|December"
DEADLINE = re.compile(
    rf"\b(?:on or before|by|after) ((?:{MONTHS}) \d{{1,2}}, \d{{4}}),? (?:at )?(\d{{1,2}}:\d{{2}} ?[AP]M) E[DS]?T\b"
)

def rule_deadlines_utc(description: str) -> list[datetime]:
    """Return every ET deadline stated in a Polymarket market description, in UTC."""
    found = []
    for day, clock in DEADLINE.findall(description):
        local = datetime.strptime(f"{day} {clock.replace(' ', '')}", "%B %d, %Y %I:%M%p")
        local = local.replace(tzinfo=ZoneInfo("America/New_York"))
        found.append(local.astimezone(ZoneInfo("UTC")))
    return found

Use America/New_York rather than a fixed offset: ET is UTC-4 until 1 November 2026 and UTC-5 after, so a hard-coded offset will be an hour wrong for several months of every year. The parser returns nothing on US match markets, because their rules contain no deadline, and nothing on price markets, where the date is in the title. It does not handle "noon", "p.m." or abbreviated months, and it does not tell a start deadline from a result deadline, so read the sentence around each match.

What this sample does not tell you

Twenty-three markets show that endDate means different things on different market types. They do not show how often each case occurs across Polymarket, or that every esports market uses exactly six hours. Valorant is not in the sample, and there is a single MLB game.

We did not establish why the aliens market moved, or whether that change was deliberate. All markets here come from the international Polymarket Gamma API. Polymarket US is a separate exchange with its own contract rules, and nothing in this article applies to it.

Data: 23 markets fetched one by one from gamma-api.polymarket.com/markets/{id} on 24 September 2026. The full sample is downloadable as JSON.

Originally published on orcalayer.com. OrcaLayer is an independent Polymarket analytics provider, not affiliated with Polymarket.

Planning to Build a Scalable Prediction Market Platform Using a Polymarket Clone Script?

Fri, 31 Jul 2026 12:35:20 +0000

Many businesses are now showing interest in prediction market platforms because they create new ways for users to participate and generate revenue. Building a platform from the beginning takes more time, money, and technical work. To make the process easier, many businesses choose a Polymarket Clone Script because it helps them launch a prediction market platform faster while supporting future business growth.
The Growing Demand for Prediction Market Platforms
Prediction market platforms are becoming more popular across different industries. People like to predict the outcome of sports, politics, crypto, finance, and other real-world events. As more users join these platforms, businesses are finding new opportunities to enter this growing market.
Building a Scalable Prediction Market Business
Starting a prediction market business requires proper planning and the right technology. Businesses need a platform that is easy to manage, secure for users, and ready to handle future growth.
Core Business Advantages
Every business wants a platform that is easy to manage, supports business growth, and provides a better experience for users. A well-developed prediction market platform offers several advantages that help businesses grow in a competitive market.
Rapid Platform Launch with Ready-to-Deploy Solutions
Ready-made solutions help businesses reduce development time and launch their platform much faster. This allows companies to enter the market quickly and start attracting users without waiting for a long development process.
Cost-Effective Development for Startups and Enterprises
Building a platform from scratch can be expensive. Using a ready solution helps businesses reduce development costs while still getting the important features needed to run a prediction market platform.
Blockchain-Powered Transparency and Security
Users always expect a secure and transparent platform. Blockchain technology helps record transactions safely and improves trust between the platform and its users.
Scalable Infrastructure for Business Growth
As more users join the platform, the system should continue to work smoothly. A scalable infrastructure supports higher traffic and larger trading activities without reducing platform performance.
Enhanced User Experience and Market Performance
An easy-to-use platform helps users participate without confusion. Simple navigation, fast loading speed, and smooth performance improve user satisfaction and encourage them to return.
Multiple Revenue Opportunities for Platform Owners
Prediction market platforms can generate income in different ways. Businesses can earn through transaction fees, market listing fees, premium services, and other platform-based revenue models.
Expanding Your Business
A growing prediction market platform gives businesses more opportunities to reach new users and enter different markets. As the business expands, new features and services can be introduced to improve user engagement. A strong platform also helps businesses build customer trust, increase platform activity, and create long-term growth opportunities in the prediction market industry.
Conclusion
The prediction market industry continues to grow, creating new business opportunities for startups and established companies. Choosing a Polymarket Clone Script helps businesses launch their platform faster, reduce development costs, and prepare for future growth. Working with an experienced development company like Maticz can help businesses build a reliable prediction market platform that supports long-term business success.