Skip to main content
← Back to the current changelog Earlier: July 6-12, 2026 →

​
2026-07-19 - Opt-in orderbook sequence and checksum verification

Added PN1, an opt-in integrity protocol for clients that maintain a local copy of the Orderbook Stream. What’s new:
  • Connect to wss://ob.polynode.dev/ws?key=YOUR_KEY&integrity=1 to receive an ordered anchor for every subscribed token.
  • Every depth-changing frame carries a token-scoped prev_seq, seq, and deterministic post-update checksum. A client can detect either a missing frame or an incorrectly applied price level immediately.
  • Send {"action":"resync","markets":["TOKEN_ID"]} after a sequence or checksum failure. The stream gates that token, sends a replacement book_snapshot anchor, and confirms completion with snapshots_done and reason: "resync".
  • If an anchor is already being prepared, resync_in_progress includes retry_after_ms. If continuity can no longer be guaranteed, integrity_backpressure or integrity_internal_reset closes the connection so the client can reconnect with fresh anchors.
  • PN1 subscriptions use explicit market lists and are initially capped at 500 resolved token IDs per connection. markets: ["*"] remains available on the normal stream but is not supported with integrity=1. Existing account limits still apply when lower.
  • last_trade_price and other non-depth events do not advance the depth sequence or carry a checksum.
The normal stream is unchanged when integrity is omitted or set to 0. PN1 verifies the continuity and resulting state of PolyNode-delivered depth; it is not a Polymarket sequence number or a cryptographic signature. Launch verification covered 368 anchors, approximately 12,800 depth updates, 543 trade messages, targeted resync, compressed and uncompressed connections, and both Node.js and Python clients. These are release-validation measurements, not throughput guarantees. Docs: Orderbook Integrity (PN1), Orderbook Messages, and Orderbook Stream

​
2026-07-19 - Bounded concurrency for exact wallet P&L

Added a short, explicit concurrency bound to GET /v3/wallets/{address}/pnl so bursts of expensive wallet calculations fail quickly and predictably instead of building a long queue. Client behavior:
  • Each account can have up to two exact wallet P&L requests running at once.
  • An additional request waits for capacity for up to 750 milliseconds. If the account’s two requests are still running, it returns 429 with error: "wallet_pnl_busy", scope: "v3_pnl_account_concurrency", and Retry-After: 1.
  • A separate capacity response can return 503 with scope: "v3_pnl_global_concurrency". It uses the same wallet_pnl_busy error and one-second retry guidance.
  • This concurrency guard is separate from requests-per-minute limits. Successful responses still include the normal rate-limit headers.
  • GET /v3/wallets/{address}/pnl/events, leaderboards, batch wallet reads, and trade routes are not part of this guard.
Requests that proceed return the same P&L fields and values as before. In release validation, a three-request burst against a worst-case wallet returned the excess request in 781 milliseconds instead of leaving all three calculations running. Docs: Wallet P&L and Rate Limits

​
2026-07-18 - V3 pages now have a 1,000-item ceiling

Standardized the largest possible V3 response page at 1,000 rows or buckets. What’s changed:
  • No V3 endpoint returns more than 1,000 rows or buckets in one page. Requests above an endpoint’s cap are normalized to the cap instead of rejected.
  • GET /v3/wallets/{address}/pnl/events now defaults to limit=1000 and clamps there, replacing its former 5,000 default and 10,000 maximum.
  • GET /v3/markets/condition/{condition_id}/positions keeps a 300-row Starter cap; Growth and Enterprise keys can request up to 1,000. The former Enterprise maximum was 2,000.
  • Stricter endpoint caps remain in place. Most V3 lists still cap at 300 rows, and leaderboards retain their 100-row cap.
  • Values through each endpoint’s cap, cursor and offset behavior, filters, sorting, response fields, and row contents are unchanged.
For a complete history, continue paging with the returned offset or cursor. For deep trade history, bounded after and before windows are usually more efficient than very large offsets. Docs: Pagination Limits, Wallet P&L Time Series, and Condition Holders

​
2026-07-18 - Faster token-scoped wallet trade history

Improved GET /v3/wallets/{address}/trades when a request is narrowed to one outcome token. What’s improved:
  • Token-scoped maker, taker, and role=both reads now use a faster path while preserving one row per matching wallet role.
  • Pagination remains stable and non-overlapping, including single-side maker-only and taker-only requests.
  • Token, condition, market, event, time, role, amount, grouping, sorting, and ordering filters were checked together to ensure the optimization did not change composition behavior.
  • Request parameters, response fields, formulas, caps, and broader multi-market query behavior are unchanged.
In the release concurrency check, a 16-way request set improved from 51.5 ms p95 to 17.8 ms p95, with all 64 responses successful. This is a measured release result, not a latency SLA. Docs: Wallet Trades

​
2026-07-18 - Faster explicit-window P&L histories

Improved GET /v3/wallets/{address}/pnl/events for long explicit after/before windows without changing P&L calculations or response ordering. Release measurements:
  • A heavy full-history control improved from 6.466 seconds to 560 milliseconds.
  • A replay of 141 previously slow request shapes completed with HTTP 200 throughout: 72 ms median, 1.483 seconds p95, 2.393 seconds p99, and 6.272 seconds maximum.
  • Responses before and after matched on deterministic fields, values, types, and ordering.
The 1,000-bucket page ceiling introduced the same day applies to these histories. Use successive windows or pages when more buckets are needed. Docs: Wallet P&L Time Series

​
2026-07-17 - Wallet type, deployment, and current status are separate

Identity responses can now distinguish what kind of wallet an address is, whether its contract exists on Polygon, and whether it is the account’s currently selected trading wallet. What’s new:
  • wallet_type reports deposit_wallet, safe, or proxy when known.
  • deployed reports whether the wallet contract currently exists on Polygon.
  • current reports whether the address is the account’s selected trading wallet.
  • The fields are additive on GET /v3/identities/{address}, POST /v3/identities/batch, GET /v3/identities/search, and identity-enriched credits responses.
  • GET /v1/resolve/{query} now includes wallet_details, which lists the current address and the account’s other deployed wallets with wallet_type, deployed, and current on each item.
The existing wallets object remains deployed-only for compatibility. This means a current deposit-wallet address can appear in wallet_details with deployed: false and current: true while its wallets.deposit_wallet value is still null. Legacy identities can return null where a status is genuinely unknown. No existing resolver or identity field was renamed or removed. Docs: Resolve Wallet, Identity Lookup, Batch Resolve, and Username Search

​
2026-07-17 - V3 account-level rate limits

V3 REST limits now apply once per account, not once per API key. What’s new:
  • All API keys owned by the same account share the plan’s rolling standard V3 REST allowance.
  • Keys can be used at the same time, but creating more keys does not increase the account’s throughput.
  • Heavy trade-history endpoints keep their separate allowance, which is also shared across the account’s keys.
Existing API keys, request formats, numeric plan allowances, and rate-limit response headers continue to work without client changes. Docs: Rate Limits

​
2026-07-15 - Lower settlement, status, and confirmed-trade latency

Corrected two independent delivery stalls affecting the public event WebSocket. What’s improved:
  • Settlement frames no longer accumulate behind periodic connection bookkeeping and then arrive in a burst. In a 210-second public check covering 3,743 settlements, measured delivery was 1 ms median, 3 ms p90, 15 ms p99, and 214 ms maximum.
  • Confirmed status_update and trade delivery recovered from a post-restart regression whose p90 had risen to approximately 23.7 seconds. Later windows measured status p90 at 530-842 ms and trade p90 at 491-1,066 ms.
  • Pending settlement notifications continue to lead confirmed status delivery. Follow-up windows measured a 2.9-3.3 second p90 lead.
  • A 180-second public soak delivered 4,336 settlements and 4,317 status updates across 121 blocks with no socket or parsing errors; embedded confirmation latency measured 3.096 seconds p95 and 3.794 seconds maximum.
  • A paired validation matched 257 of 257 observed pending transactions to their confirmed updates, with arrival latency of 3.003 seconds p95 and 3.221 seconds p99.
Payloads, metadata enrichment, routing, compression, subscription behavior, and free-tier rules are unchanged. Docs: Settlement Events, Status Update Events, and Trade Events

​
2026-07-14 - Clearer checkout returns and support feedback

Improved two customer-facing website flows. What’s changed:
  • After a successful card checkout returns to the dashboard, the page now refreshes account status for up to 30 seconds until the selected paid plan is visible. This avoids briefly showing the old plan while activation finishes.
  • The support widget now shows an on-page acknowledgement only after a message is accepted. The acknowledgement disappears when a real support reply arrives; signed-in users are also told that a reply can follow by email while they are away.
  • New USDC checkout buttons and sign-in handoffs were temporarily removed from the website. Previously stored USDC handoffs are cleared so an old browser session cannot reopen that purchase flow.
  • Existing USDC-paid access and its displayed expiration date are unchanged. Card checkout remains available.
No API endpoint, API key, plan name, or existing paid entitlement changed as part of this website update. View current pricing

​
2026-07-14 - Faster recent wallet-position pages

Improved GET /v3/wallets/{address}/positions performance for recent, not-yet-redeemed positions, especially on wallets with long histories. One previously slow release sample improved from approximately 194 ms to 24.3 ms. Public position samples remained successful, and a combined positions/trades enrichment check passed without response differences. The endpoint’s 300-row page cap, lifecycle filters, fields, values, and pagination contract are unchanged. Docs: Wallet Positions

​
2026-07-13 - V3 service incident resolved

Some core V3 data requests returned 503 responses beginning at approximately 22:20 UTC, with the main service interruption lasting from approximately 23:00 to 23:51 UTC. Service was restored during the same window. Post-recovery checks returned 200 across the affected surfaces, including approximately 100 ms for a representative trades request and 36 ms for a representative positions request. Normal live-data processing also resumed. No client request, endpoint, or response-format change was required after recovery.