Skip to main content

​
2026-11-05 - Pending settlements exclude matches that cannot settle

Since November 4, fake Polymarket match transactions naming real traders’ wallets have been broadcast to the network. They looked like real pending trades but could never settle on chain. polynode now leaves them out. What’s new:
  • Pending settlement events no longer include match transactions that Polymarket’s exchange would reject, such as matches sent by a wallet that is not allowed to settle trades.
  • A status_update for a transaction that was included in a block but failed now carries execution_status: "FAILED" and no confirmed_fills. Before, it could have looked like a normal confirmation.
Compatibility:
  • Successful confirmations are unchanged and omit execution_status.
  • Subscriptions, filters and delivery latency are unchanged.
  • Treat a trade as final once its status_update arrives without execution_status: "FAILED".
Docs: Status Update Event

​
2026-10-27 - Combo win rate by time window

The Wallet Combo Summary can now count a wallet’s combo wins and losses inside a time window, so you can see its win rate over the past day, week or month. What’s new:
  • GET /v3/wallets/{address}/combos/summary accepts period=1d, 7d, 30d, or custom with after (inclusive) and before (exclusive) Unix seconds, the same window rules as the Combo P&L Leaderboard.
  • With a window, win_count, loss_count, resolved_count and win_rate count only the combo positions that settled inside it, and the response adds top-level period and window. A combo settles at its first payout to any holder.
  • P&L and position counts on the summary stay all time.
Compatibility:
  • Without a window the response is unchanged.
  • An invalid window, or window= (use period), returns 400 invalid_request.
  • Leaderboard rows keep their all-time win and loss counts.
Docs: Wallet Combo Summary

​
2026-10-26 - Combo win and loss counts

The Combo wallet summary and every Combo leaderboard row now include each wallet’s win count, loss count and win rate. What’s new:
  • GET /v3/wallets/{address}/combos/summary and each GET /v3/combos/leaderboard row add win_count, loss_count, resolved_count and win_rate.
  • win_rate is win_count / resolved_count as a 4-decimal fraction string ("0.6964" = 69.64%), or null when the wallet has no resolved combo.
  • A combo position is won or lost once its legs resolve. The counts are all time, whether or not the position was redeemed, and on the leaderboard they are not window-scoped (like open_combo_count).
  • GET /v3/wallets/{address}/combos/positions now filters by outcome: status=resolved_win, status=resolved_loss, or status=resolved for both.
Compatibility:
  • Every existing field is unchanged; these are new fields only.
Docs: Wallet Combo Summary, Combo P&L Leaderboard, Wallet Combo Positions

​
2026-10-22 - Combo leg market metadata and CLOB token IDs

Combo WebSocket events now include market metadata on every leg, and each leg’s market.token_ids now carries the market’s CLOB token IDs. What’s new:
  • In combo_execution, combo_status_update and combo_lifecycle, legs[].market.token_ids holds the leg market’s CLOB token IDs (Polymarket’s clobTokenIds) in outcome order. These are the IDs used for CLOB order books, prices and orders, so market.token_ids[outcome_index] is the CLOB token ID of the leg’s selected outcome.
  • legs[].market (title, slug, image, event title and slug, outcomes and CLOB token IDs) is filled on every leg. Leg market metadata is resolved ahead of trading, so it never delays an event. A market Polymarket listed in the last couple of minutes can briefly arrive without it.
  • For Polymarket Protocol V2 markets, Polymarket’s CLOB trades by position ID, so market.token_ids carries the market’s position IDs for those markets.
Compatibility:
  • Event shapes, subscriptions and filters are unchanged.
  • legs[].position_id and leg_position_ids still carry the leg position IDs used by the combo contracts.
  • The TypeScript, Python and Rust SDK types already include these fields, so no SDK upgrade is needed.
Docs: Combo leg market

​
2026-10-21 - Owner addresses on V3 wallet endpoints

V3 wallet endpoints now accept an owner EOA. Pass the EOA and the response combines its Polymarket wallets (Safe, proxy, deposit wallets) that have data, so one call covers an account that holds funds in more than one wallet. What’s new:
  • Pass an owner EOA to GET /v3/wallets/{address}, /pnl, /pnl/events, /positions, /trades, /activity, /splits, /merges, /redemptions, /fees-paid, /nrc, the wallet combo routes and the wallet credits routes, as wallet on /v3/combos/activity and /v3/combos/redemptions, or inside POST /v3/wallets/batch.
  • Combined responses add a wallets array of {wallet, type} objects, with type one of eoa, safe, proxy or deposit_wallet. In POST /v3/wallets/batch it sits inside each combined element. List rows add wallet, the wallet each row belongs to.
  • Totals, counts and time-series buckets are summed across the combined wallets. Lists keep their usual sort order and pagination fields, and combining covers the first 10,000 rows (offset + limit).
Compatibility:
  • Passing a Safe, proxy or deposit wallet returns just that wallet, exactly as before. So does an EOA that owns no wallets with data.
  • The new fields are additive. If you key positions by token_id or fills by id, add wallet to the key for combined responses, since two of an owner’s wallets can return the same token or fill.
  • Rebates, rewards, Copy PnL, webhooks, WebSocket filters and the V1 and V2 endpoints are unchanged.
Docs: Owner addresses

​
2026-10-11 - Polymarket Protocol V2 markets

Polymarket is moving newly created markets to Polymarket Protocol V2, its new market system, from around November 2, 2026 (tentative, per Polymarket). Its test markets have traded since October 5, 2026 and run until October 30, 2026. Polymarket Protocol V2 is separate from Polymarket’s April 2026 exchange upgrade, which these docs and the exchange_version: "v2" field call “V2”. Current markets behave exactly as before. What you need to do:
  • REST and WebSocket: nothing. Same endpoints, same subscriptions, same response shapes.
  • Trading, split, merge or redeem with our SDK: upgrade to polynode-sdk 0.15.0 (npm), polynode 0.18.0 (crates.io) or polynode 0.15.1 (PyPI) before November 2, 2026. Older versions keep working on current markets, but Polymarket rejects their orders on Protocol V2 markets and no funds move.
  • SDK short-form market discovery and the redemption watcher: upgrade to the same versions.
  • Storing outcome ids yourself: use strings, up to 78 digits.
What’s new:
  • Protocol V2 markets appear in the same REST routes and WebSocket streams. Their rows and events add protocol_version: "v2" and module ("binary" or "neg_risk"). Rows and events without these fields are current markets.
  • REST rows for Protocol V2 markets also carry structural_condition_id, on multi-outcome markets neg_risk_event_id, and on resolved markets the exact payouts_ppm.
  • WebSocket trades settled on ExchangeV3 carry exchange_version: "v3". The exchange field keeps its two existing values, so typed decoders keep working.
  • Protocol V2 results arrive as condition_resolution oracle events with the usual payouts, plus the exact payouts_ppm and a derived flag.
  • Condition id parameters and filters accept both the 66-character form and Polymarket’s 31-byte form.
  • The SDKs sign each order for the right exchange automatically, set up the Protocol V2 approvals on the first Protocol V2 order, support split, merge and redeem on Protocol V2 markets, and add getMarketProtocol().
  • Polymarket’s test markets (slugs starting with polyv2) appear in wallet, trade and market-id routes and on the streams.
Docs: Polymarket Protocol V2 markets

​
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.