DEV Community: ekocam

Polymarket Gamma API endDate Is Not the Resolution Deadline

ekocam — Thu, 24 Sep 2026 17:27:28 +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.

Giving Claude live Polymarket data with an MCP server

ekocam — Sat, 25 Jul 2026 19:05:56 +0000

Large language models are good at reasoning about numbers and bad at knowing them. Ask Claude which Polymarket wallets are actually profitable and you will get a confident answer assembled from training data that was already stale when the model shipped.

The Model Context Protocol fixes that by letting the model call your data directly. This post walks through a working example: a small MCP server that puts live Polymarket whale analytics into Claude Desktop, Cursor, or any other MCP client.

The server is open source and MIT licensed, so you can read the whole thing: github.com/orcalayer/orcalayer-mcp.

What MCP actually does

An MCP server exposes three kinds of capability to a model:

Tools the model can call, with typed arguments and structured results
Prompts the user can pick from a menu, which orchestrate several tools at once
Resources the model can read directly as context, without spending a tool call

That third one matters more than people expect. A methodology document loaded as a resource means the model knows how your numbers are defined before it starts interpreting them.

Setup

The server is a stdio wrapper over the Python SDK, so there is nothing to deploy. Add it to your claude_desktop_config.json:

{
  "mcpServers": {
    "orcalayer": {
      "command": "uvx",
      "args": ["orcalayer-mcp"]
    }
  }
}

On Windows the file lives at %APPDATA%\Claude\claude_desktop_config.json, on macOS at ~/Library/Application Support/Claude/claude_desktop_config.json. Restart the app after editing.

That is the whole install. uvx fetches and runs the package on demand, so there is no virtualenv to manage.

The tools

Five tools, four of which need no key at all:

Tool	What it does	Key
`leaderboard`	Rank smart-money whales by P&L, win rate or volume	No
`wallet_overview`	A wallet's profile and performance summary	No
`wallet_positions`	A wallet's largest open positions	No
`markets`	Search markets where smart whales are clustering	No
`whale_alerts`	Live feed of recent smart-whale trades	Premium

For the Premium tool, pass the key through the environment rather than hardcoding it:

{
  "mcpServers": {
    "orcalayer": {
      "command": "uvx",
      "args": ["orcalayer-mcp"],
      "env": { "ORCALAYER_API_KEY": "your_key_here" }
    }
  }
}

Prompts do the orchestration

The part worth stealing for your own server is the prompt layer. Rather than making the user chain tool calls by hand, ship prompts that encode the workflow you actually want:

Prompt	What it does
`analyze_wallet`	Full wallet analysis: smart money or farmer?
`find_divergence`	Markets where smart money disagrees with the current price
`hedge_check`	Whether a wallet's profit was real alpha or a hedge structure
`territorial_markets_review`	Ukraine territorial markets with an ISW frontline overlay

hedge_check is the one I would point at if you are building something similar. A wallet that holds both sides of the same market can post a spectacular profit number that means nothing directionally. A naive integration reports that as alpha. Encoding the check as a prompt means the model runs it every time instead of only when the user thinks to ask.

That is the general lesson: your domain knowledge belongs in the prompts, not in the user's head.

Resources for definitions

Three resources load as plain context:

orcalayer://methodology covers how smart money is separated from farmers, hedgers and market makers
orcalayer://glossary is a prediction-markets glossary
orcalayer://api-reference is the REST API reference, including auth and rate limits

If your data has any non-obvious definitions, and analytics data always does, put them in a resource. It costs nothing at query time and stops the model from inventing its own interpretation of your columns.

One design note on honest nulls

The Premium stream now tags every event with a settlement_type of MINT, MERGE, COMPLEMENTARY or null, describing how a match settled rather than what the trader intended.

The null is deliberate. It means the pipeline could not determine the settlement type, not that the trade was something else. It is tempting to collapse an unknown into a default, and it is almost always the wrong call: a model reading your data cannot tell a real zero from a missing one, so it will treat your guess as fact. Return the honest null and let the caller decide.

Try it

Which Polymarket wallets have the best win rate right now,
and are any of them just farming near-settled markets?

Ask that in Claude Desktop with the server connected and it will call leaderboard, then run the farmer check from the methodology resource, and tell you which of the top names are not what they look like.

The server is MIT licensed at github.com/orcalayer/orcalayer-mcp, and the underlying REST API is documented at orcalayer.com/docs/api. Data is for informational purposes only and is not financial advice.

A REST API for Polymarket Whale Data: A Developer Guide

ekocam — Sun, 19 Jul 2026 12:34:32 +0000

If you want Polymarket whale data in your own code, a dashboard, a trading model, or an AI agent, you need an API, not a website. Here is what the OrcaLayer REST API exposes and how to start.

How do developers access a Polymarket REST API?

Through the OrcaLayer API. It is a plain REST API over the same index the site runs on: over 1.2 billion trades read directly from the Polygon chain, farmer-filtered. Full access is on the Premium tier (19.99 dollars a month) at 600 requests per minute. Some read endpoints, wallet profiles, market search and the leaderboard, need no key at all, so you can prototype before paying anything.

Quickstart

Sign up and upgrade to Premium.
Go to Settings, API Keys, and generate a key. It uses the sk_orca_ prefix and is shown once.
Call the API:

curl -H "Authorization: Bearer sk_orca_XXXXXX" \
  "https://orcalayer.com/api/public/v1/whales/leaderboard?limit=10"

Authentication works either as a Bearer token in the Authorization header or as an x-api-key header. Premium endpoints under /api/v2 expect x-api-key specifically. A missing or invalid key returns 401, a non-Premium plan on a Premium endpoint returns 403, and passing the rate limit returns 429 with a Retry-After header.

What the API exposes

Whale leaderboards, farmer-filtered, with win rate, profit and profit factor
Individual wallet profiles and full trade histories
Recent whale trades and whale position flips
Per-market whale activity
Whale alerts data, the same stream that powers the alerts feed
ISW Ukraine territory data

The numbers match what the site shows, because it is the same index and the same published methodology, including the farmer filter and NegRisk correction.

Clients and tooling

You do not have to start from raw REST:

Python SDK: pip install orcalayer
MCP server for AI agents: uvx orcalayer-mcp, so Claude or any MCP-capable agent can query whale data directly
Claude Code agent skill for terminal workflows
A whale watchlist monitor and a backtest cookbook as ready-made starting points
OpenAPI spec at https://orcalayer.com/api/openapi.json for generating typed clients in any language

All of them are linked from the API docs at orcalayer.com/docs/api.

What to build on it

At 600 requests per minute you can poll a watchlist of wallets every few seconds and drive your own alerting, mirror the leaderboard into your own database, backtest wallet-following strategies against real resolved markets, or feed an AI agent live whale context through MCP.

FAQ

Is there a REST API for Polymarket whale analytics?
Yes. The OrcaLayer REST API serves whale leaderboards, wallet profiles and trades, whale alerts, market whale activity and ISW territory data over plain REST. Full access is on the Premium tier at 600 requests per minute; some read endpoints such as wallet profiles, market search and the leaderboard need no key at all.

How do I authenticate?
Generate a key in Settings, API Keys, then send it as a Bearer token in the Authorization header or as an x-api-key header. Keys use the sk_orca_ prefix and are shown only once at creation.

Is there a Python SDK?
Yes, pip install orcalayer. There is also an MCP server for AI agents (uvx orcalayer-mcp), a Claude Code agent skill, a whale watchlist monitor and a backtest cookbook.

What are the rate limits?
Premium runs at 600 requests per minute. Exceeding the limit returns HTTP 429 with a Retry-After header.

Originally published on orcalayer.com.

Most "top traders" on Polymarket are farming win rate. I backtested it.

ekocam — Tue, 30 Jun 2026 13:42:21 +0000

If you've looked at a "top traders" leaderboard on Polymarket and thought about copy-trading the top wallets, I have some bad news: a lot of those flawless 95%+ win-rate records are farmed, not earned. I pulled the on-chain data and backtested it, and the raw leaderboard turns out to be a pretty bad signal to copy. Here's the breakdown, with reproducible notebooks at the end.

The farming trick

It's simple. You only ever buy outcomes that are already basically decided, priced around 95-99c.

Think of a market like "Will X happen?" sitting at 99c the day before it resolves. You put up 99c to make 1c. You win almost every time. Do this across enough near-decided markets and you end up with a 95%+ win rate and a clean, green, very impressive-looking record.

But the edge is basically zero, and more importantly for a copy-trader: it's unfollowable. You can't get filled at 99c at any real size, and you're risking 99 to make 1. The win rate is real in the data and useless in practice.

Raw P&L and win-rate leaderboards reward exactly this behavior. So the wallets that look best are often the ones you least want to copy.

Measuring it properly

A few things matter when you compute this from raw on-chain data, or the numbers come out wrong:

NegRisk consolidation. Polymarket's multi-outcome markets settle through a NegRisk adapter. If you don't consolidate the legs, you double-count and P&L inflates. (The public data API's cashPnl has this problem - I don't use it as cost-basis truth.)
FIFO cost basis, per wallet per market. Matching sells against buys in order, not averaging blindly.
Win rate per resolved market, not per trade. A wallet that makes 40 trades in one market that resolves in its favor didn't win 40 times.

With that in place, I split the leaderboard into two cohorts to copy:

Raw top 8 by cumulative P&L (farmers included).
Filtered top 8 - same board with farmers and hedgers removed.

Then I backtested copying each one as an equal-weight equity curve across resolved markets.

The result

Honest read: for most of the window the two curves basically track each other. The filtered cohort only pulls ahead near the end, and not by a huge margin (~33M vs ~27M in this run). I'm not going to oversell "filtering wins on P&L" - that gap is small and probably sample-dependent. Both curves are lumpy too; a few big resolutions carry most of the move, which is kind of the point - these are near-decided markets resolving.

What I'd actually stand behind: the raw leaderboard is built on those unfollowable ~99c fills, so copying it is a bad idea regardless of the cumulative number. The win rate on those boards is mostly noise. If you're building a copy-trading strategy, "who has the highest win rate" is close to the worst possible wallet-selection signal.

Small sample (8 per cohort), so take the exact numbers with a grain of salt. The interesting part isn't the dollar figure, it's the mechanism.

Reproduce it

The notebooks are open source (MIT) so you can re-run this on a different set of wallets or a different time window and check whether the filtered edge holds out of sample - genuinely curious if it does:

github.com/orcalayer/polymarket-backtest-cookbook

Three notebooks: follow one wallet's resolved bets as an equity curve, follow a smart-money cohort by category, and the raw-vs-filtered comparison above.

The data comes from OrcaLayer, which is a data layer I build over Polymarket (every trade read straight from the Polygon chain, then classified - farmer filtering, NegRisk-correct win rates, FIFO P&L). The leaderboard endpoint is keyless so the notebooks run free; per-wallet backtests use an API key.

If you go deeper into prediction-market data, I'd love feedback on the methodology - especially the NegRisk and FIFO handling, which is where most of the subtlety lives.