> ## Documentation Index
> Fetch the complete documentation index at: https://docs.polynode.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog - June 15-21, 2026

> Archived PolyNode API, WebSocket, and documentation changes from June 15 through June 21, 2026.

[← Back to the current changelog](/changelog)

[Newer: June 22-28, 2026 ←](/changelog-june-22-28-2026) · [Earlier: June 8-14, 2026 →](/changelog-june-8-14-2026)

## 2026-06-19 - WebSocket fan-out capacity and settlement latency guidance

Expanded public WebSocket delivery capacity for heavily subscribed event streams and clarified the best subscription shape for latency-sensitive settlement consumers.

What's improved:

* High-volume streams have more delivery headroom, improving resilience when many subscriptions are active at once.
* No event names, payload fields, filter syntax, or subscription messages changed.
* For the lowest settlement latency, use a dedicated `type: "settlements"` subscription. The broader `type: "trades"` preset intentionally multiplexes `settlement`, `trade`, and `status_update` events; preserving per-connection order can place a settlement behind other frames during a burst.
* Initial `type: "snapshot"` messages contain historical state and should be excluded when measuring live `detected_at`-to-receive latency.

In one post-release live-only validation window, a dedicated settlement subscription delivered 592 unique pending transactions at p50 `1ms`, p90 `4ms`, p99 `11ms`, and max `50ms`, with no samples above `100ms`. These measurements describe that validation window, not a latency SLA.

Docs: [WebSocket Overview](/websocket/overview) and [Settlement Event](/websocket/events/settlement)

***

## 2026-06-17 - 62-page V3 Query Catalog

Published an intent-based Query Catalog so developers can start from the result they need instead of first finding the underlying endpoint.

The catalog includes category guides and granular copy-ready recipes for:

* Trades: global, wallet, market-token, market-slug, builder-attributed, grouped-order, condition, and combo trade queries.
* Positions: wallet, open-wallet, global, token-holder, condition-holder, market-slug, and combo position queries.
* P\&L: all-time and time-window wallet P\&L, market/tag breakdowns, event history, batch reads, and leaderboards.
* Markets: search, condition and slug lookup, token details, prices, tags, resolutions, and candles.
* Wallet activity: unified activity, splits, merges, redemptions, negative-risk conversions, PolyUSD flows, fees, rebates, and rewards.
* Builders, combos, fees, tags, and categories, including additive `include_combos=true` query shapes.

The endpoint reference remains the source for complete parameter and response schemas; the Query Catalog is the shortest path to a working request for a specific product use case.

Docs: [V3 Query Catalog](/data/query-catalog/overview)

***

## 2026-06-17 - Fee, rebate, and reward data guide

Published a dedicated Fees section that distinguishes the API's accounting surfaces and points each question to the correct endpoint.

Documented query paths:

* Exact all-time trader-paid fees: `GET /v3/wallets/{address}?include_accounting_summary=true`.
* Fee-bearing wallet fills: `GET /v3/wallets/{address}/fees-paid`.
* Global and receiver-scoped fee events: `GET /v3/fees` and `GET /v3/fees/{receiver}`.
* Builder fee ranking and underlying attributed fills: `GET /v3/builders?sort=fees` and `GET /v3/builders/{code}/trades`.
* Maker rebates: `GET /v3/wallets/{address}/rebates`.
* Public reward-market configuration: `GET /v3/rewards/markets` and `GET /v3/rewards/markets/{condition_id}`.

Important conventions are now explicit:

* `page_total_fees_paid` is scoped to the returned page; use the opt-in wallet accounting summary for the exact all-time total.
* Fee-event raw amounts use six-decimal USDC units.
* Builder `total_fees` means protocol fees generated by attributed fills, not an off-chain builder revenue-share payout.
* Maker rebate lookups use the CLOB maker/signing address, and reward-market configuration is not a per-wallet earned-rewards ledger.

Docs: [Fees Overview](/data/fees/overview)

***

## 2026-06-17 - Full V3 market-candles reference

Published the complete public reference for trade-built V3 OHLCV candles across token, condition, and market-slug lookups.

Documented routes:

```http theme={null}
GET /v3/markets/{token_id}/candles
GET /v3/markets/condition/{condition_id}/candles
GET /v3/markets/slug/{slug}/candles
```

The reference covers:

* Resolutions `1m`, `5m`, `15m`, `1h`, `4h`, and `1d`, with maximum request sizes of 120, 180, 240, 300, 360, and 500 candle buckets respectively.
* Forward and backward windows with `direction`, `anchor_ts`, `start`, and `end`; timestamp parameters use Unix seconds.
* Backward history pagination through `pagination.older_end_ts`.
* Optional `gap_fill=true` carry-forward candles after a prior price exists.
* Token routes returning one `candles` series, while condition and slug routes return one `series` entry per outcome token. Use `token_id` to select one outcome from a condition or slug.
* OHLC, USD/share/buy/sell volume, trade count, VWAP, millisecond chart timestamps, and first/last fill timestamps.

Docs: [Market Candles](/data/markets/candles)

***

## 2026-06-15 - PM2 AutoRedeemer redemptions in WebSocket streams

PM2 AutoRedeemer redemptions are now surfaced in both the combo stream and the standard redemption stream.

What's new:

* AutoRedeemer `Redemption`, `BinaryRedemption`, and `NegRiskRedemption` logs emit customer-facing `combo_lifecycle` events with the wallet, exact raw payout, normalized payout, module name, and receipt log index. Binary and negative-risk redemptions also include the condition ID directly.
* Confirmed `combo_status_update` messages can include `lifecycle_events[]` for receipt-only AutoRedeemer lifecycle activity.
* The same AutoRedeemer payout is also bridged into the standard `redemption` event class, attributed to the user wallet instead of the AutoRedeemer contract.
* New `type: "redemptions"` WebSocket preset subscribes directly to `redemption` events. Existing `settlements` or `wallets` subscriptions with `event_types: ["redemption"]` continue to work.

No subscription change is required for existing redemption consumers.