Skip to main content

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