Skip to main content

​
2026-09-02 - Initial replay for fill subscriptions

fills subscriptions now return recent matching fills immediately after the subscription acknowledgement, using the same flat event shape as live fills. What’s new:
  • snapshot_count returns up to the requested number of flat fill events, subject to the account tier limit.
  • since returns matching fills after a Unix-millisecond timestamp within the account tier’s lookback window and takes precedence over snapshot_count.
  • Wallet, token, side, and size filters apply consistently to replayed and live fills.
  • A replay with no matching fills completes explicitly with {"type":"snapshot","count":0,"events":[]}.
  • Existing live fill messages remain unchanged. Each replay item uses the same {"type":"event","data":{...}} envelope.
Docs: Subscriptions and filters and WebSocket reconnection

​
2026-09-01 - Builder profiles and trader analytics

Builder profiles now expose daily activity, buy/sell composition, attributed trades, and a dedicated trader leaderboard from one public surface. What’s new:
  • GET /v3/builders is the canonical Builder directory and accepts an exact, case-insensitive name filter. A documented loop prints every public name and stable Builder code.
  • Builder detail, trades, daily activity, and trader leaderboard paths accept a code or exact public name. Names, hexadecimal digits, and the optional code prefix are case-insensitive. Shared display names return HTTP 409 and require a code to disambiguate.
  • GET /v3/builders/{code}/activity/daily returns daily volume, fills, active traders, trader-paid fees, buy/sell mix, and bounded recent market/category composition. GET /v3/builders/activity/daily compares up to 20 codes.
  • GET /v3/builders/{code}/leaderboard supports 1d, 7d, 30d, and all, plus P&L and Builder-attributed activity sorts. Period, sort, and order are case-insensitive and responses use canonical lowercase values.
  • Trader leaderboard pages contain at most 100 rows and cover the first 500 ranks through offsets 0, 100, 200, 300, and 400.
  • All-Time P&L sorts add opt-in pagination=cursor. Signed cursors bind the Builder, filters, limit, both returned snapshots, and already-returned identities so one pinned traversal does not repeat a wallet. Historical offset requests and response bodies remain available unchanged.
  • Cursor continuations carry next_cursor, as_of, and pnl_as_of. If either snapshot advances, HTTP 409 tells the caller to restart at offset 0.
  • P&L remains global Polymarket wallet P&L for the Builder-active cohort. The activity columns remain Builder-attributed.
Docs: Builder directory, Builder daily activity, and Builder trader leaderboard

​
2026-08-29 - Combo P&L leaderboard

A dedicated Combo leaderboard now ranks eligible wallets by realized P&L over 1-day, 7-day, 30-day, or custom windows and by marked All Time P&L. What’s new:
  • GET /v3/combos/leaderboard supports All Time realized, unrealized, and total P&L plus realized-only fixed and half-open custom windows.
  • Custom windows accept after, before, or both as Unix seconds and use [after, before) when both bounds are present.
  • Every response discloses eligible, excluded, transfer-incomplete, and unmarked wallet counts. Excluded wallets are omitted, never zero-filled.
  • Open positions use the latest Combo fill mark; terminal positions use 1 or 0. Arbitrary wallet-to-wallet transfer basis is not inferred.
  • Signed-order maker fills are counted once, and their exchange fees are included in weighted-average cost basis and realized proceeds.
  • The route is global and does not accept tag or category filters.
Docs: Combo P&L Leaderboard

​
2026-08-28 - Stable perps activity pagination

Archived perps trades, position events, likely liquidations, and wallet collateral flows now support stable cursor pagination. What’s new:
  • Responses return has_more and an opaque next_cursor. Archived trade responses also preserve the existing more field.
  • Reusing the same route and filters keeps pages disjoint while new activity arrives. Cursors expire after 24 hours.
  • Wallet-flow deposit and withdrawal totals and counts stay identical across every page in one traversal.
  • Malformed, expired, route-mismatched, and filter-mismatched cursors return clean HTTP 400 errors.
  • Cumulative volume delta remains a bounded single-page series and is not part of this cursor contract.
Docs: Archived trades, Position events, Liquidations, and Wallet flows

​
2026-08-27 - Complete market, event, and leaderboard discovery

New V3 discovery routes make it possible to walk the full market and event catalogs and build rolling leaderboard navigation without guessing scope names. What’s new:
  • GET /v3/markets and GET /v3/events provide cursor pagination, open, closed, and inactive status filters, and exact event-slug filtering.
  • GET /v3/markets/stats and GET /v3/events/stats return complete catalog and status counts independent of any one page.
  • GET /v3/leaderboard/scopes lists and searches the categories or tags available for 1-day, 7-day, and 30-day realized-P&L rankings.
  • GET /v3/rewards/markets adds nullable title, slug, image, event, category, and tag context to every listed reward market.
Docs: Market Catalog, Event Catalog, and Leaderboard Scopes

​
2026-08-27 - Rolling realized-P&L leaderboards

Trader leaderboards now support 1-day, 7-day, and 30-day realized-P&L rankings across all markets, one category, or one tag. What’s new:
  • Set period=1d, 7d, or 30d on GET /v3/leaderboard or GET /v3/tags/{slug}/leaderboard.
  • Rolling rows are ranked by realized_pnl descending and include realized profit, loss, win, position, event, and market counts. Historical unrealized P&L is not included.
  • Each request returns up to 100 rows. Rolling pagination is capped at rank 1,000 and shorter rankings end at their last returned row.
  • A valid category or tag with no realized results in the selected window returns HTTP 200 with an empty leaderboard.
  • Omitting period, or using period=all, preserves the existing all-time leaderboard and its sort options.
Docs: Leaderboard and Tag Leaderboard

​
2026-08-19 - Builder volume aligned with Polymarket’s V2 convention

Builder volume now counts locally indexed outcome shares, with one share represented as $1 of par notional. This matches Polymarket’s builder-volume convention over the same CLOB V2 history without importing Polymarket’s leaderboard totals or pre-V2 attribution. What’s new:
  • GET /v3/builders and GET /v3/builders/{code} add volume, buy_volume, and sell_volume aliases.
  • volume_scope=clob_v2_onchain and volume_semantics=outcome_share_par_notional make the coverage and unit explicit.
  • Existing fill count, fees, raw maker/taker totals, timestamps, profile metadata, and compatibility fields remain available.
  • sort=volume uses only Polynode’s local builder aggregate. Public Polymarket volume is not used as a fallback or ranking input.
Docs: Builder Leaderboard and Builder Detail

​
2026-08-18 - Query sports games by event or market ID

Sports game endpoints can now be queried by Polymarket event ID or market ID. What’s new:
  • Use /v2/sports/games/by-event/{event_id} for an event ID.
  • Use /v2/sports/games/by-market/{market_id} for a market ID. The response contains the full parent event and its canonical event slug.
  • Append /state, /context, /prices, or /history to either identifier route for the corresponding game data.
  • Existing slug-based routes are unchanged.
Docs: Game Detail

​
2026-08-18 - Connect Wallet to user-owned V2 orders

The TypeScript, Python, and Rust SDKs now provide one documented platform flow from wallet connection through an actual zero-attribution user-owned V2 order. What’s new:
  • TypeScript polynode-sdk 0.14.2 provides a browser-memory session, standard viem provider typing, wallet-confirmed USDC.e to pUSD funding, exact order preview/signing, a durable pre-submit order-hash callback, and authenticated open-order reconciliation.
  • TypeScript 0.14.2, Python polynode 0.14.1, and Rust polynode 0.17.1 share one browser-safe signing-request and encrypted backend-vault bundle contract. Prepared orders expose the canonical exchange order hash before transport so open orders and fills can be reconciled by exact identity instead of an amount/time heuristic.
  • Platforms can authorize each connected wallet once, retain wallet-scoped credentials in an encrypted vault, prepare one short-lived order on any worker, send only typed data to the browser, and consume submission state exactly once.
  • User-owned orders contain zero builder attribution and do not consume a platform’s shared builder allowance. Market rules, collateral, API rate limits, and ordinary service limits still apply.
  • The default fresh deposit-wallet path requires three setup signatures: one ownership message, one EIP-712 approval batch containing all four base-order permissions, and one EIP-712 ClobAuth signature. Wallet deployment itself does not require a signature.
  • A first order therefore requires four total signatures when pUSD is already funded, or five when an SDK-confirmed USDC.e to pUSD conversion is also needed. A returning wallet restored from the encrypted vault has no setup signatures and signs only the exact order.
  • The guide covers credential sensitivity, account and chain binding, ownership-conditional atomic storage, exception-safe cleanup, minimal dependency installs, and conservative ambiguous-submit reconciliation.
Docs: Connect Wallet to order and User-owned execution

​
2026-08-18 - Faster confirmed trade delivery

Confirmed trade events and status_update.confirmed_fills now arrive promptly during high-volume periods. What’s improved:
  • The confirmed-trade payload, receipt-derived values, order hashes, deduplication, and status ordering are unchanged.
  • A release investigation reproduced 10 to 28-second confirmed-trade delays while status delivery remained current. The corrected path removed that accumulated delay.
  • The first complete post-release comparison covered 1,886 confirmed trades. Observed delivery measured 246.7 milliseconds ahead at the median, 318.2 milliseconds behind at p90, and 492.4 milliseconds behind at p99.
  • A separate acceptance window covered 13 consecutive Polygon heads, 340 settlements, and 178 status updates with no gaps, duplicates, reversals, or parse errors.
No subscription or parser change is required. Docs: Trade events, Status updates, and Trade tracking

​
Earlier releases

Older entries are grouped into Monday-through-Sunday archive pages for fast, reliable loading.