Skip to main content
← Back to the current changelog Newer: July 13-19, 2026 ← · Earlier: June 29-July 5, 2026 →

​
2026-07-12 - Event-scoped trades and dollar-size filtering

Trade feeds can now be scoped to a whole Polymarket event and filtered by dollar size. What’s new:
  • event_slug and event_id filters on GET /v3/trades and GET /v3/wallets/{address}/trades: one call returns trades across every market in an event, with pagination. Builder trades gain event_id alongside the existing event_slug.
  • min_amount_usd on global, market, market-slug, wallet, and builder trades: a dollar floor that matches the amount_usd field already present in every trade row. ?min_amount_usd=100 means “show me $100+ trades”. Decimals are accepted. The raw min_amount filter keeps working; min_amount_usd is the recommended one.
  • Trade rows across all trades endpoints are now enriched with event_slug and event_id, so any feed can be grouped by event client-side.
  • condition_id and market_slug filters on global trades are now documented for market-scoped feeds across all outcomes.
  • An event filter that matches nothing returns an empty page rather than falling back to unfiltered results, and invalid values return 400.
Docs: Global Trades, Wallet Trades, and Builder Trades

​
2026-07-12 - Faster wallet activity and builder statistics

Improved two aggregation-heavy V3 read paths without changing their request or response contracts. Release measurements:
  • Representative GET /v3/wallets/{address}/activity requests improved from 1.013 seconds to 51 ms and from 1.607 seconds to 26 ms.
  • A redemption-heavy wallet request that had previously timed out returned 200 in 16 ms.
  • A large GET /v3/builders/{code} statistics request improved from 131.7 seconds to 2.72 seconds.
  • Before-and-after checks returned the same row sets, values, timestamp ordering, and builder aggregates.
These are measured examples, not latency guarantees. Field names, event values, pagination, and endpoint limits are unchanged. Docs: Wallet Activity and Builder Detail

​
2026-07-11 - Credits API for rewards, yield, rebates, and referrals

Added a complete indexed history of the five ways Polymarket pays users: liquidity rewards, yield, maker rebates, taker rebates, and referral rewards. Wallet routes:
  • GET /v3/wallets/{address}/credits/totals returns per-program totals for all time or a start_ts/end_ts window.
  • GET /v3/wallets/{address}/credits returns individual payouts with program, time, amount, token, and transaction context. It supports time and amount filters plus time- or amount-based sorting.
  • GET /v3/wallets/{address}/credits/series returns chart-ready earnings buckets. Use interval=hour|day|week|month and fill=zero when a continuous series is needed.
Global routes:
  • GET /v3/credits/leaderboard ranks recipients by one program or combined credits over 24h, 7d, 30d, all time, or an explicit window.
  • GET /v3/credits/stats returns program-wide totals and time series.
  • GET /v3/credits/events is a cursor-paginated global payout feed; min_amount can turn it into a large-credit monitor.
  • GET /v3/credits/recipients/stats shows new earning wallets per time bucket.
  • GET /v3/credits/distributors lists the public payout addresses and their totals.
  • GET /v3/credits/txs/{hash} decodes one payout transaction into its typed recipient-and-amount breakdown.
Use reward, yield, maker_rebate, taker_rebate, and referral_reward in type or types; types accepts a comma-separated set or all. The history begins with each program’s first on-chain payout, and newly confirmed credits normally become queryable within about a minute. The dataset includes the program batches visible in Polymarket’s activity feed plus direct distributor payments that the feed omits. Transfers between payout-system addresses are excluded from aggregate surfaces. All payout amounts are dollar values; the token field distinguishes the settlement token. For global stats, unique_recipients is exact on all-time requests and null when a custom time window is supplied. Hourly stats require a window of seven days or less. Docs: Credits Overview, Wallet Credit Totals, Credits Leaderboard, Global Credit Stats, and Global Credit Feed

​
2026-07-11 - Batch identity resolution, username search, and identity-enriched credits

Added three V3 identity routes for turning Polymarket wallet activity into account-level context:
  • POST /v3/identities/batch resolves up to 1,000 trading wallets per call. Unknown wallets return null instead of failing the whole request.
  • GET /v3/identities/search?q=... searches more than five million known Polymarket usernames, supports partial matches, and ranks exact matches first.
  • GET /v3/identities/{address} works in both directions: a trading wallet returns its username, controlling EOA, wallet type, and related wallets; an EOA returns the Polymarket wallets it controls.
Credits responses are enriched at the same time: events include username; leaderboard rows include username, eoa, and wallet_type; wallet totals include an identity block and other_wallets. Fields remain null when an identity is unknown. The batch and search routes use the identity catalog refreshed daily. For a brand-new wallet that may not be in that catalog yet, GET /v1/resolve/{query} remains the deeper single-identity lookup. Docs: Batch Resolve, Username Search, and Identity Lookup

​
2026-07-11 - Current all-time wallet P&L at request time

Strengthened current P&L responses so a recently sold, resolved, or repriced position cannot leave an all-time wallet result behind the latest wallet state. What’s improved:
  • An unwindowed GET /v3/wallets/{address}/pnl now computes against the current wallet state, including requests with market metadata filters.
  • The no-window summary returned by GET /v3/wallets/{address}/pnl/events uses the same current accounting.
  • A wallet that fully sold a position before resolution is no longer credited as though it held the winning outcome through settlement.
  • If the exact read cannot complete for an unusually large wallet, an unfiltered all-time request can use a certified current result only when it is complete and fully valued. Otherwise the API returns an unavailable response rather than stale P&L.
  • Response field names and numeric types are unchanged. Time-windowed P&L, leaderboards, block/transaction lookups, and combo routing keep their existing behavior.
Docs: Wallet P&L and Wallet P&L Time Series

​
2026-07-11 - Perps API consistency and coverage pass

A hardening pass across the whole perps surface, based on an external-style audit of the docs and live API. What’s new:
  • perps_klines WebSocket events now carry exactly one flat candle ([open_time, open, high, low, close, volume, trade_count]) and are sent only when the candle’s contents change. Empty and duplicate events are gone.
  • perps_statistics events are sent per instrument only when the statistics change, substantially reducing idle bandwidth.
  • WebSocket authentication failures are now visible: the connection opens, delivers one error frame, and closes with code 4401 for a bad or missing key or 4429 for a connection-limit failure instead of an unexplained disconnect.
  • GET /v3/perps/funding/{instrument} now accepts after/before in seconds or milliseconds like the other series endpoints, honors limit, and includes instrument_id and symbol. start_timestamp/end_timestamp keep working.
  • Klines responses now include instrument_id and symbol; /limit-tiers and /assets return the standard {"data": [...]} wrapper.
  • Timestamp field names are unified: timestamp for event/sample times and as_of for snapshot freshness.
  • Derived values such as aggregates, notionals, basis, and CVD are normalized to clean decimals; exchange-reported values retain their native precision.
  • Unknown query parameters now return 400 with the accepted parameter names, so a misspelled filter cannot silently return unfiltered data.
  • Transient upstream congestion returns 503 with a Retry-After header instead of a misleading 429.
  • Newly activated accounts now enter position coverage on the next normal collection cadence instead of waiting for a long full pass. Coverage drift also triggers a faster complete refresh. All listed instruments measured 99.6-100.0% in the post-release validation window; that measurement is not a coverage SLA.
  • Docs now include real response examples, automatic wallet resolution, clarified book/kline streaming semantics, and explicit sort order on every series endpoint.
Docs: Perps Overview, WebSocket Channels, Funding History, and Coverage

​
2026-07-10 - Exact wallet-position accounting and fractional resolutions

Corrected GET /v3/wallets/{address}/positions for several lifecycle cases where balance, cost accounting, resolution, and pagination could disagree. What’s improved:
  • A position sold completely before market resolution now keeps its actual sale P&L instead of being valued as though the wallet held the winning outcome through resolution.
  • Position accounting is brought current before applying cost-sensitive sorts or lifecycle pagination, so deep pages cannot mix a current balance with older cost values.
  • Positions present in wallet activity but temporarily absent from one response source are still returned when their current state can be established, without producing duplicate rows.
  • status=open|closed|redeemable|redeemed is classified before pagination using current market and payout state, making status pages consistent across offsets.
  • Resolved positions now honor the complete Conditional Tokens payout. Invalid, cancelled, or otherwise fractional resolutions use the actual payout fraction rather than assuming every result is exactly 0 or 1.
  • For a fractional payout, won is null while price, value, and realized P&L use the payout fraction. Ordinary binary winners and losers retain their existing true/false values.
  • Wallet-position envelopes now include additive next_offset; the endpoint continues to cap a page at 300 rows and reports the applied limit.
No request parameter or existing field name changed. A small displayed average-price difference can still remain when PolyNode and Polymarket use different historical cost-basis conventions; that difference does not change the terminal outcome or redeemable payout. Docs: Wallet Positions

​
2026-07-10 - Perps wallet resolution and position-state correctness

Improved account lookup and historical position behavior across the perps wallet and analytics routes. What’s improved:
  • Every perps wallet route can now resolve email/social-login proxy wallets to their controlling account automatically, alongside plain EOAs, deposit wallets, and Gnosis Safes.
  • A proxy not yet known to the resolver returns a repeatable 422 with guidance to pass the signer directly; repeated lookup no longer risks a server error.
  • Current positions, size/P&L leaderboards, large-position queries, and coverage now use the latest complete wallet observation. A complete empty portfolio closes prior positions instead of leaving stale rows marked open.
  • Position-change events use stable timestamp-and-ID ordering and a deterministic identity, preventing duplicate close/reopen transitions in historical pagination.
  • Liquidation and position-event feeds ignore incomplete predecessor observations rather than manufacturing a transition from partial data.
Docs: Wallet Mapping, Wallet Overview, Position History, and Position Events

​
2026-07-09 - Polymarket perps API

Full market and account data coverage for Polymarket perpetual futures is now available under the same /v3 surface and API keys as the rest of PolyNode. What’s new:
  • Live market data for every listed perps instrument: tickers, orderbooks, best bid/offer, trades, 24-hour statistics, klines, funding, and a cross-instrument screener.
  • PolyNode-exclusive history the exchange does not serve: trade archive with server-side filters, open interest, volume, basis, trade-flow/CVD, and cumulative funding series.
  • Wallet endpoints with automatic address resolution: pass a Polymarket profile address or the underlying account address, singly or in a batch.
  • Cross-account analytics: whale leaderboard, smart money, positioning, large positions, position history, position events, liquidations, and a coverage transparency metric.
  • On-chain collateral data: TVL, deposits, withdrawals, top depositors/withdrawers, and per-wallet flows.
  • WebSocket streaming at wss://perps.polynode.dev/ws: tickers, statistics, BBO, books, trades, and klines over one connection.
Docs: Perps Overview, Quickstart, and Perps WebSocket

​
2026-07-09 - Multi-wallet context in /resolve

Expanded GET /v1/resolve/{query} so one lookup can return every deployed Polymarket wallet associated with the account. What’s new:
  • The additive wallets object contains deposit_wallet, safe, and proxy_wallet, each set to its deployed address or null.
  • Queries can still start from a trading wallet, controlling EOA, or case-insensitive username.
  • Both standalone and upgradeable deposit-wallet variants are recognized and reported as type: "deposit_wallet"; callers do not need to distinguish “deposit” from “beacon” wallet naming.
  • If an account has a deployed deposit wallet, the legacy top-level safe field continues to return that preferred trading wallet. Otherwise it falls back to the existing Safe or proxy wallet.
  • Existing safe, eoa, username, and type fields remain backward compatible. eoa is populated for proxy wallets whenever the owner can be recovered and remains null in the rare unresolved case.
Docs: Resolve Wallet

​
2026-07-09 - Connection-preserving Orderbook Stream releases

Orderbook Stream releases can now move new traffic to an updated version without disconnecting established WebSocket clients. What’s improved:
  • Existing connections to wss://ob.polynode.dev/ws can continue naturally while new connections move to the updated service.
  • The updated stream must be warm and return matching subscription behavior before it receives new connections.
  • REST fallback follows the same active target as the WebSocket stream, avoiding stale routing after a release.
  • A brief burst of 502 responses from the REST fallback after the first transition was corrected the same day. Later failures return a controlled unavailable response instead of an abrupt empty connection.
The first complete release cycle preserved all 33 established public connections through the transition and drain. That was a rollout measurement, not a connection-count or uptime guarantee. Docs: Orderbook Stream

​
2026-07-06 - Visible activity and resolution times on wallet positions

Added the timestamps and resolution context needed to display and verify recent closed, redeemed, and redeemable positions. What’s improved on GET /v3/wallets/{address}/positions:
  • resolved_at is populated from current market resolution metadata with a historical fallback. At release, 99.8% of closed markets had a known resolution time.
  • New additive field last_activity_at exposes the time of the position’s latest on-chain balance activity, including redemption or settlement activity. It is available even when no direct wallet redemption event exists.
  • last_trade_at now exposes the most recent fill time for the position’s token.
  • winning_outcome_index is populated when the market’s payout is known.
  • include_combos=true rows gain last_update_block and last_activity_at for the same client-side recency workflow.
sort=recent already ordered rows by their latest balance-activity block and was not changed. The new last_activity_at field makes that ordering visible to clients instead of forcing them to treat missing timestamps as zero. Open positions continue to return resolved_at: null until resolution. Docs: Wallet Positions

​
2026-07-06 - Paid-plan REST limits standardized

Aligned paid-plan REST provisioning and published limits so new and existing keys receive the same documented allowance:
  • Starter: 1,000 requests per minute.
  • Growth: 2,000 requests per minute.
  • Enterprise: 4,000 requests per minute by default, with custom capacity by agreement.
Requests above the allowance return 429 Too Many Requests with a retry time. WebSocket connections are not counted as REST requests and keep their separate plan limits. This entry records the plan allowances introduced on July 6. They were initially enforced per API key; the July 17 release changed V3 REST sharing to one allowance per account without changing the numeric plan limits. Docs: Rate Limits