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

# Changelog

> Notable changes to the Limitless Exchange platform, API, and SDKs

Welcome to the Limitless Changelog. Here you'll find important changes to the Limitless Exchange platform including API updates, SDK releases, and new features.

## Aug 5, 2026

### Embed Limitless markets on any site

You can now embed a live Limitless market widget on external sites. The builder at [embed.limitless.exchange](https://embed.limitless.exchange) turns any market or category link into a copy-paste snippet. Each snippet renders real-time odds, a price chart, and buy buttons in a sandboxed iframe, with layout, theme, and size controls.

* Three snippet formats: Default (styled iframe with SEO markup), Script (auto-sizing height), and Minimal (bare iframe for platforms like Notion).
* Category embeds rotate through the category's top live markets and replace resolved markets automatically; rotation speed, pool size, and sort are configurable.
* Crypto price markets show a live asset-price line with an Odds ↔ Price toggle; sports fixtures render as a live scoreboard.
* Every snippet carries a referral code. Use the code from your Limitless account to earn a share of referred users' trading fees (10–40% by tier, in USDC, paid daily) through the referral program.
* Embedding is free and requires no account; a Limitless account is needed only to collect referral rewards.

**Documentation:** [Embed Limitless Markets](/user-guide/embed-markets), [Referral Program](/user-guide/referral-program)

## Aug 4, 2026

### Paginated Unrealized PnL market leaderboard

The market-scoped Unrealized PnL leaderboard now supports page-based pagination, matching the realized-PnL leaderboard convention. Existing clients keep working unchanged: an omitted `page` is treated as `page=1` and the `limit` default remains `100`.

* `GET /leaderboard/pnl/unrealized/markets/{marketId}` accepts a new `page` query parameter (integer, `1..100`, defaults to `1`); `limit` is unchanged (`1..100`, defaults to `100`).
* Responses now include `page`, `totalRows`, and `totalPages`. `totalRows` reflects the committed Top-100 generation for that market.
* `rank` remains absolute across pages — with `limit=10`, page 2 starts at rank `11`.
* The `ETag` is page-scoped, so `If-None-Match` validators cannot cross pages.
* The `biggest-positions` route is unchanged.

**Documentation:** [Unrealized PnL leaderboard by market](/api-reference/leaderboard/unrealized-pnl-market)

### More packs stay quotable in thin orderbooks

Pack quoting now applies a consistent depth requirement across every leg side, so more packs price and stay available when orderbook depth is thinner.

* The quote response contract is unchanged (`eligible`, `ineligibleReasons`, `multiplier`, `potentialPayout`, `collateralRequired`, `legs`); only which quotes come back as `eligible: true` changes.
* No action required for existing integrations.

**Documentation:** [Packs](/user-guide/packs)

### Bug fix: Unrealized PnL leaderboard omits entries without a valuation

Live Unrealized PnL leaderboard responses now skip entries whose mark is temporarily unavailable, so ranking pages return only rows with a computable Unrealized PnL. Previously, a missing mark could leave a row in the response with an unusable valuation.

* Affects `GET /leaderboard/pnl/unrealized/markets/{marketId}` and `GET /leaderboard/pnl/unrealized/biggest-positions`.
* Rows with a valid `mark`, `marketValue`, and `unrealizedPnl` are returned as before; rows without an available valuation are excluded from that snapshot and reappear once a mark is available.
* Ranks remain absolute across the returned page. No positions, orders, or funds were affected. No action required.

**Documentation:** [Unrealized PnL leaderboard by market](/api-reference/leaderboard/unrealized-pnl-market), [biggest open positions](/api-reference/leaderboard/biggest-positions)

## Aug 3, 2026

### Programmatic AMM trading for server wallets

Partners can now execute AMM buy and sell trades — and manage the underlying token approvals — through the Programmatic API using a Privy server-managed wallet. This closes the gap between CLOB (already supported) and AMM markets for delegated trading flows.

* New endpoints: `POST /amm/buy`, `POST /amm/sell`, `POST /amm/allowances/check`, `POST /amm/allowances/approve`.
* Requires an HMAC-signed API token with both the `trading` and `delegated_signing` scopes. Legacy API keys are not accepted.
* Partners target an owned sub-account with `onBehalfOf` in the request body, matching the existing portfolio write endpoints.
* Only AMM markets in `FUNDED` state with a future deadline are tradable. Amounts are positive integer strings in the market's collateral base units; buy takes `collateralAmount`, sell takes `collateralReturnAmount`. Outcome `0` is YES, `1` is NO.
* Slippage defaults to 100 bps and is capped at 1000 bps. Execution bounds are computed from a fresh on-chain quote at submission time.
* Allowances are explicit and one-time per wallet/market/side: buy needs a collateral ERC-20 approval to the market, sell needs a CTF `setApprovalForAll`. `approve` returns `200` when already ready or `202` immediately after submission; poll `check` until confirmed. Buy and sell do not auto-approve.
* Each trade requires a partner `idempotencyKey` bound to the trade fingerprint for 24 hours. Replays of the same key return the original submission; mismatched reuse returns `409`.
* Successful submissions return Privy `transactionId`, `userOperationHash`, and/or `txHash` (sponsored user operations may not have a synchronous `txHash`).
* Rate limit: 10 requests per 10 seconds per caller.

**Documentation:** [AMM Trading guide](/developers/amm-trading), [Programmatic API](/developers/programmatic-api), [Derive API token](/api-reference/api-tokens/derive-token)

### Bug fix: Manual LP reward distribution records paid rewards correctly

Manual LP reward distribution now records paid rewards and the linked on-chain payout after the transaction confirms. Previously, the API returned an error and marked the payout as failed even after the Base transaction had confirmed, leaving reward rows without their payout link.

* Affects the manual LP reward distribution endpoint only.
* After a payout transaction confirms, the associated reward rows are now marked paid and linked to the payout in the same request.
* If the payout update does not affect exactly one row, distribution stops before rewards are marked paid and before any success event is published, so state stays consistent.
* No funds were lost. On-chain payouts that already confirmed prior to this fix are reconciled separately.
* No action required from traders or integrators.

**Documentation:** [LP Rewards](/user-guide/lp-rewards)

### Bug fix: LP reward distribution reliability restored

Daily LP reward distribution runs are reliable again. The scheduled distribution job had started failing on backlogs of unpaid rewards because a single aggregation query could time out against the database. The job now processes the same rewards across smaller bounded pages, so distributions complete within the request timeout even with large backlogs.

* Affects the scheduled LP reward payout job; no API contract, authentication, or payout-math changes.
* No funds were lost — unpaid rewards remained queued and are paid out on the next successful run.
* No action required from traders or integrators.

**Documentation:** [LP Rewards](/user-guide/lp-rewards)

## Aug 1, 2026

### Bug fix: Unrealized PnL leaderboard degrades gracefully under backpressure

The live Unrealized PnL leaderboard now isolates backpressure incidents to the leaderboard itself, so other endpoints stay unaffected. Clients continue to receive a response for `GET /leaderboard/pnl/unrealized/markets/{marketId}` and `GET /leaderboard/pnl/unrealized/biggest-positions`; the snapshot reports its recovery state until fresh data is available.

* Under pressure, incoming mark and position updates are dropped rather than written as partial state, so ranking data can go stale but never corrupt.
* Snapshots that haven't fully rebuilt continue to return `state: DEGRADED` with a `staleReason` (or `BUILDING` when there is no snapshot yet) instead of being promoted to `READY`. Existing clients that already branch on `state` need no changes.
* No positions, orders, or funds were affected. No action required.

**Documentation:** [Unrealized PnL leaderboard by market](/api-reference/leaderboard/unrealized-pnl-market), [biggest open positions](/api-reference/leaderboard/biggest-positions)

## Jul 31, 2026

### Live Unrealized PnL leaderboard

A new live leaderboard ranks traders by unrealized PnL across their open positions, updating in real time as marks move.

* Open-position state and leaderboard generations are maintained by a dedicated live projection, fed by finalized CLOB, AMM, split/merge, conversion, and resolution events
* The API exposes new leaderboard read routes (market-scoped rankings and biggest positions), and the WebSocket layer sends lightweight invalidation hints so clients know when to refetch

### Live markets on a whole team

User-created live markets can now target a **team**, not only the match or a single named player — for example "any Chelsea player to score, get a yellow, or get a red in the next 5, 10, or 15 minutes." Another user takes the other side, and the market settles from the same match events as existing live windows.

* Market types now form a grid: four event kinds (goal, card, yellow card, red card) across three scopes (match, team, player) — twelve types in total
* Own goals are excluded on every scope

### Live windows settle after full time

Live-window markets now settle once the match is **over**, not when the window's half ends. A market like "goal between 24' and 28'" previously settled at half time; it now settles roughly an hour after the final whistle.

* Why: the data provider keeps amending match events after the whistle (e.g. a late VAR reversal). Settling at the half could pay out on events that later changed; waiting for full time plus a delay means settlement reads the final record
* Suspended or interrupted matches retry until play resumes; matches that end with no result (postponed, cancelled, abandoned, awarded) settle on the events recorded in-window, after the same post-match delay

### Esports: `videogameSlug` on every market response

Esports market responses now expose the videogame slug (`cs-go`, `league-of-legends`, …) under a single key, `videogameSlug`, in the public market metadata — for both match groups and solo props. Previously groups carried the value only as `esportTitle` while solo props used `videogameSlug`, forcing consumers to branch on market kind. Additive change; `esportTitle` is untouched.

### Bug fix: Fee-module wallet excluded from holder lists

Market holder lists and top-holder queries no longer include the venue's fee-module contract wallet, which could previously appear as a large "holder" on fee-bearing markets. Display-only fix; no positions or funds were affected.

## Jul 30, 2026

### Tennis: total sets and total games markets

Tennis matches now get automatically created solo CLOB prop markets, following the same pattern as the football props:

* **Total Sets** — over/under (e.g. 2.5)
* **Total Games** — over/under lines (e.g. 21.5 / 22.5 / 23.5)
* Created automatically per match and resolved from official settlement data; carry `metadata.externalSlug` where a matching Polymarket market exists

### Bug fix: League-scoped tab counts on sport pages

On sport pages, the Matches/Props tab counts now reflect the league filter the visitor picked instead of whole-sport totals (e.g. filtering to one tennis league previously kept showing all-Tennis counts).

### X account connections now brokered through the platform

The X-account connect flow now runs on the platform's own OAuth handshake instead of being brokered through Privy. This removes a case where users who had signed in with X on any other Limitless account could not connect that same X account to a new profile.

* Connecting an X account that is already active on another profile now transfers it. The previous profile is marked disconnected in the same operation, and the new profile owns the connection.
* One active X connection per profile and one active profile per X account are still enforced. Simultaneous connect attempts return `409`; the losing caller is asked to retry.
* The connect and disconnect endpoints require a Privy or session-authenticated user. Machine API tokens cannot manage the X identity.
* Disconnect immediately clears stored credentials and best-effort revokes the refresh token at X; the connection row is retained so the account can be reconnected later.

## Jul 29, 2026

### Connect an X account to your Limitless profile

Profiles can now be linked to an X account. Once connected, the handle is exposed on the public profile connection resource so anyone can jump from a Limitless profile to the linked X profile.

* New endpoints on `/profiles`: `POST /x/connection/authorize` returns an `x.com/i/oauth2/authorize` URL to redirect the user to, `POST /x/connection` exchanges the returned `{ code, state }` for a stored connection, and `DELETE /x/connection` disconnects.
* Public read: `GET /profiles/:account/x-connection` returns `{ connected, xHandle }` for any caller, including logged-out visitors, and is CDN-cached.
* Owner-only fresh read: `GET /profiles/:account/x-connection/handle` returns the handle for the profile owner without CDN caching, so a user sees their own connect/disconnect immediately.
* Rate limits: 5 mutations per minute per profile, 120 public reads per minute per IP, 60 owner reads per minute per account.

### Partner-restricted market pages

You can now gate a market page to a specific partner and their sub-accounts, so a partner can preview hidden markets on a dedicated page before announcing them publicly. Public pages are unchanged.

* New `restrictedToProfileIds` allowlist on market page create and update. `null` or empty means the page stays public.
* A caller gets access when their own profile ID or `partnerId` appears in the allowlist. Listing the partner root admits existing and future sub-accounts automatically.
* Works for any authenticated caller, including HMAC API tokens and app sessions.
* Unauthorized or anonymous callers get a `404`, the same response as a nonexistent page.
* Restricted pages must be active, `navPlacement=hidden`, root-level, and childless, and list standalone hidden markets only (no groups, no `includeNextMarket=true`).
* Authorized responses are served with `private, no-store`; public pages keep their existing CDN caching.

**Documentation:** [Get Market Page by Path](/api-reference/navigation/get-page-by-path), [List Page Markets](/api-reference/navigation/list-page-markets)

### Direct-link pages for hidden partner markets

The market detail and historical-prices endpoints now return hidden markets when you request them by exact slug. Partners can share deep links to markets that aren't listed in public feeds (private launches, embedded surfaces, previews) without first flipping them to public.

* Applies to both AMM markets and CLOB markets fetched by slug.
* Slugs must match exactly; hidden markets still don't appear in search, category, or navigation feeds.
* Group-level pages continue to hide their non-visible child markets.
* This is separate from partner-restricted pages above: fetching a hidden market by slug works for any caller who has the exact slug, while a restricted page gates a whole curated page to an allowlist.

**Documentation:** [Get market details](/api-reference/markets/get-market)

### AMM market stats degrade gracefully during indexer downtime

Market detail and page listings no longer fail when upstream AMM indexing data is temporarily unavailable. Affected AMM markets return zero volume, liquidity, and open interest instead of an error, and real values come back automatically once indexing recovers.

* Applies to both direct market lookups and page-market listings.
* Failed enrichment reads are not cached, so recovery propagates as soon as the response cache expires.

### Split market resolution now supports manual AMM markets

Binary split resolution now works for manual standalone binary AMM markets, in addition to CLOB binary markets. A split resolves the market at a payout ratio (for example 70/30) instead of winner-take-all, and both sides remain redeemable at the split ratio in a single call. Existing integrations keep working.

* On a `RESOLVED` manual AMM market, a split is signalled the same way as on CLOB: `winningOutcomeIndex: null` with the ratio in `payoutNumerators`.
* Detect a split by reading `payoutNumerators` on resolved markets and redeem as usual — the redeem endpoint handles both sides at the ratio.
* Oracle-automated AMM markets continue to resolve winner-take-all and reject split payloads.
* Unrealized and realized PnL account for the split ratio automatically on both sides.

**Documentation:** [Get Market](/api-reference/markets/get-market) | [Positions](/api-reference/portfolio/positions) | [Redeem](/api-reference/portfolio/redeem)

### More resilient real-time streams during upstream latency

Ordered real-time publishes now ride out transient upstream latency instead of failing fast. Short latency blips on the messaging backbone briefly pause per-market ordering rather than dropping the handoff and forcing WebSocket clients into a reconnect/replay loop. Order and orderbook events keep their exactly-once, per-market ordering guarantees.

* No API or payload changes — the fix improves reliability under load only.
* Per-message send deadlines are unchanged; only the retry window around a stalled backbone is extended.
* Unordered publishes are unaffected.

**Documentation:** [WebSocket Events](/developers/websocket-events)

### Faster live order and orderbook updates under load

The real-time pipeline that drives order events and orderbook updates now scales further before it queues. Under heavy trading, live-order and orderbook WebSocket messages arrive with less delay, and per-market updates no longer stall behind a single busy market.

* Order and orderbook events flow through the same WebSocket channels — no API or payload changes.
* Bursts on one market no longer slow updates for other markets: each market has its own update lane.
* Order events keep exactly-once delivery.

**Documentation:** [WebSocket Events](/developers/websocket-events)

### Bug fix: Per-parlay PnL attribution on shared positions

When two or more parlays in the same pack shared a position and one redeemed first, the remaining parlays could be recorded at \$0, under-reporting their charted PnL. Each parlay's share is now credited only after the shared redemption is confirmed on-chain; if confirmation hasn't landed yet, attribution is deferred and retried automatically instead of being finalized too early.

* Display-level accounting only: pack-level payouts were always correct, and no funds were affected.
* Extends the earlier fix that covered NegRisk parlays to CLOB parlays, which now behave the same way.
* No API or client changes, and no action required.

## Jul 28, 2026

### Esports markets: Polymarket slug auto-sync for MM and arb

Esports markets now carry the matching Polymarket market slug on `metadata.externalSlug`, and Limitless populates it automatically. Previously the field was populated for football and tennis markets only.

* Applies to esports match-winner groups (both team markets share the event slug) and the new solo prop markets — map winner, total maps, and map handicap.
* Handicap markets are only synced when the favoured side can be unambiguously aligned with Polymarket's team ordering; anything ambiguous is skipped rather than guessed.
* Live in v1 for CS2. Other titles are skipped until their Polymarket slug convention is verified against a live event.
* Sync runs hourly and only writes when the corresponding Polymarket event actually lists the expected market — no unverified slugs are emitted.
* Cross-venue market makers and arb integrations can read `metadata.externalSlug` on esports markets to resolve the Polymarket counterpart without extra lookups.

### Esports slug sync: Dota 2, League of Legends, and Valorant match moneylines

The Polymarket `externalSlug` sync for esports now covers Dota 2, League of Legends, and Valorant match moneylines, in addition to CS. Cross-venue market makers and arb integrations can read `metadata.externalSlug` on these markets to resolve the Polymarket counterpart without extra lookups.

* Applies to match moneylines only. Prop-market sync (map winner, total maps, map handicap) stays CS-only.
* Dota 3-way moneylines resolve to their per-team Polymarket sub-markets; the CS/LoL/Valorant binary path is unchanged.
* The matcher now handles Polymarket's trailing instance digits (`100t1`, `g21`, `kru1`) and diacritics (e.g. `KRÜ`) when aligning team abbreviations.
* Ambiguous matches are skipped rather than guessed. Existence-gated: no slug is written unless the Polymarket event actually lists the expected market.

### Esports solo prop markets: map winner, total maps, map handicap

Esports match pages now surface standalone binary prop markets alongside the main match-winner group. Limitless derives these props from the match structure rather than mirroring third-party betting feeds, so coverage is uniform across every supported league. Live in v1 for CS2.

* **Map winner** — one market per guaranteed-played map in odd-format series (a best-of-3 spawns maps 1 and 2), so every market is decidable with no void path.
* **Total maps** — over/under lines strictly inside the achievable series total (e.g. 2.5 for a best-of-3).
* **Map handicap** — margin lines strictly inside the achievable margin range (e.g. 1.5 for a best-of-3).
* Props trade through the same CLOB stack as the match-winner group, with a 24-hour trading window from match start. Live updates flow over the existing WebSocket streams.
* Settlement uses per-game results from settled PandaScore matches; markets only resolve once the match is `settled` (interim `finished` states are not trusted).

**Documentation:** [WebSocket Events](/developers/websocket-events)

### Realized PnL: split/merge accounting and partition retries

Realized PnL now records qualifying split and merge activity that was previously skipped. The values returned by the public PnL endpoint reflect that activity going forward. Distant future partition maintenance timeouts now defer to the next hourly run instead of failing.

* No API changes — the fix affects data completeness only.
* Applies to new activity going forward; historical replay is not included.

**Documentation:** [Get PnL Chart (Public)](/api-reference/public-portfolio/pnl-chart)

### Unrealized PnL: fee-aware accounting

Unrealized PnL now consistently accounts for fees across the platform, so the open-position value you see reflects what you would actually walk away with. Portfolio and public-portfolio positions responses use the same shared calculation, keeping the app, API, and downstream analytics aligned.

* No response-shape changes — the same `unrealizedPnl` field is returned; only its value is adjusted to include fees.
* Applies going forward to all open positions across binary, split, and grouped markets.

**Documentation:** [Positions](/api-reference/portfolio/positions), [Public Positions](/api-reference/public-portfolio/positions)

## Jul 27, 2026

### Referral tier floors: `customTier` field

A referrer's USDC referral tier can now include a minimum floor assigned by Limitless. The floor acts as a minimum: if the referrer's trading volume later clears a higher tier, volume wins and they are promoted; if it falls back, the floor holds.

* `GET /referral/usdc/me` now returns an optional `customTier` field with the floor's ladder name when one is active. The response shape is unchanged when no floor exists, so existing clients keep working.
* Ladder widgets can read `customTier` to render the floor above the volume-derived tier.
* There is no public endpoint to set or remove a tier floor.

### Split market resolution for binary markets

Binary markets can now resolve to a payout split (for example 50/50) instead of a single winner. Both sides remain redeemable at the split ratio in a single call — no new endpoint, and existing integrations keep working.

* On a `RESOLVED` market, `winningOutcomeIndex: null` no longer means "not yet resolved" — it can also indicate a split, with the ratio carried in `payoutNumerators`.
* Integrators should detect a split by reading `payoutNumerators` on resolved markets and redeem as usual; the redeem endpoint handles both sides at the ratio.
* Applies to CLOB binary markets. AMM and NegRisk flows are unchanged.

**Documentation:** [Get Market](/api-reference/markets/get-market) | [Positions](/api-reference/portfolio/positions) | [Redeem](/api-reference/portfolio/redeem) | [Programmatic API](/developers/programmatic-api)

### WebSocket orderEvent: new timestamp fields

The WebSocket `orderEvent` payload now carries three additive timestamp fields — `matchedAt`, `occurredAt`, and `publishedAt` — across the EXECUTION, MATCHED, and MINED/FAILED lifecycle stages. The legacy `timestamp` field still ships on every event but is now marked deprecated.

* `matchedAt`: when the match occurred in the order matching engine.
* `occurredAt`: when the lifecycle event (execution, mine, fail) was produced.
* `publishedAt`: when the event was published to the WebSocket stream, useful for measuring stream latency.
* No changes required — new fields are additive. Migrate off `timestamp` at your own pace.

**Documentation:** [WebSocket Events](/developers/websocket-events)

### Maker rebates: current rates now on the rewards page

The Maker Rebates docs no longer hardcode a "current program parameters" table. Rates are per-market and change over time (recent example: BTC/ETH 15m and 5m tuned separately), so the docs now defer to the rewards dashboard as the source of truth and explain the mechanism only.

* Current rates: [limitless.exchange/rewards?view=rebates](https://limitless.exchange/rewards?view=rebates).
* The illustrative 100 percent example on the page is clearly labeled as an assumption for the walkthrough, not a live rate.

**Documentation:** [Maker Rebates](/user-guide/maker-rebates)

### Starter referral rate returns to 10 percent

The one-week Starter tier promo has ended. The Starter referral rate is back to 10 percent, and the tier ladder is now 10/18/25/32/40. Higher tiers are unchanged.

* New referral fills on the Starter tier earn 10 percent from the deploy onward.
* Promo-week fills that are still unresolved will be restamped at 10 percent when their markets resolve, so pending referral earnings on those positions will shrink. Already-resolved fills are not affected.
* No action is required from referrers or referred users.

### Settlement hardening against ERC-1155 receiver-griefing wallets

Failed CLOB settlements are now re-traced at the failure block to identify the exact wallet whose ERC-1155 receiver hook reverted the transfer. That wallet is then auto-blocked. This catches griefers that the earlier detector could miss, and keeps settlement reliable for everyone else.

* Only genuinely unattributable settlement failures are traced; known-benign reverts (balance, slippage, nonce, infra) are skipped, so RPC cost stays negligible.
* Attributed wallets are added to the trader blocklist for `erc1155_receiver_rejects`, and their resting orders are cancelled by the live-order sweep.
* No action is required from legitimate traders — this is a backend hardening. Applies to CLOB markets.

### Bug fix: Realized PnL stalled on standalone AMM markets

Realized-PnL updates for standalone AMM (binary) markets could stall when outcome-token mapping was incomplete, causing the PnL chart to fall behind for affected accounts. New events now flow through as expected.

* Applies to standalone AMM binary markets only. CLOB, NegRisk, and grouped markets are unaffected.
* The fix restores forward progress from the point of deploy; it does not automatically replay historical events that stalled before the fix.

**Documentation:** [PnL Chart](/api-reference/portfolio/pnl-chart)

### Bug fix: Extra-time corners could flip sports YES resolutions

Sports corners markets on fixtures that went to extra time or penalties could resolve YES using inflated regular-time counts. This happened when the stats provider had not yet split extra-time corners out of the regular-time bucket. Affected YES resolutions on such fixtures now route to the Limi Oracle for verification against sources like FIFA and ESPN.

* Only YES outcomes on corners markets for fixtures ending in AET or PEN are re-verified. NO outcomes and full-time fixtures settle as before.
* Cards markets are unaffected — the provider splits cards per period correctly.
* Expected volume of extra Oracle checks is on the order of one per month.

### Bug fix: Faster automatic blocking of ERC-1155 receiver griefers

Wallets that reject settlement transfers ("receiver griefers") are now detected and blocked within seconds of the first failed settlement. Previously, detection waited for a minute-level sweep, and fast-crossing griefer orders could slip past between sweeps.

* The first settlement failure for a griefer wallet still occurs — this fix reduces repeat exposure, not the initial hit.
* Confirmed griefers are added to the trader blocklist automatically after on-chain verification. Safe wallets are never blocked.
* No integration changes required. Order placement and successful settlement paths are unchanged.

## Jul 23, 2026

### Time-based LP reward schedules

A market's daily LP rewards budget can now be scaled up or down at specific hours or days of the week, evaluated in Eastern Time. Defaults are unchanged — markets without a schedule still pay a flat rate.

* Per-market boosts are applied within the market's daily cap, so total daily payout is bounded.
* Platform-wide dimming (a global multiplier) can also apply on top of the per-market schedule.
* The applied multiplier is recorded per minute for auditability.

**Documentation:** [LP Rewards](/user-guide/lp-rewards)

### Market listing endpoints: `includeNextMarket` for upfront-scheduled rounds

Market listing and search endpoints now accept an opt-in `includeNextMarket=true` query parameter. When set, each upfront-scheduled market includes a `navigation.nextMarket` object describing the successor round. Clients can then prefetch or subscribe to it before the current round expires.

* Response gains a `navigation.nextMarket` field with the next round's slug and metadata. Cursor pagination still walks the primary result set — `nextMarket` is attached to each item, not injected as extra rows.
* The `tradable` flag on `nextMarket` is intentionally conservative: it stays `false` until the successor is actually live.
* Opt-in only — omit the parameter and responses are unchanged.

**Documentation:** [Browse Active Markets](/api-reference/markets/browse-active) | [Browse Active by Category](/api-reference/markets/browse-active-category) | [Search Markets](/api-reference/markets/search) | [List Page Markets](/api-reference/navigation/list-page-markets)

## Jul 16, 2026

### SDK authentication: scoped API tokens (HMAC) are now the default path

Every SDK getting-started flow — TypeScript, Python, Go, and Rust — now leads with scoped API tokens (HMAC) as the recommended authentication path. The legacy `X-API-Key` / `LIMITLESS_API_KEY` path still works, but the docs now mark it as legacy and not recommended for new integrations.

* New integrations should authenticate with a scoped API token, configured on the SDK client via `hmacCredentials` / `hmac_credentials` / `WithHMACCredentials` / `HmacCredentials`, typically loaded from `LMTS_TOKEN_ID` and `LMTS_TOKEN_SECRET`.
* Existing API-key integrations are unaffected — no forced migration, no removal timeline.
* Scoped tokens give you granular scopes (`trading`, `account_creation`, `delegated_signing`, `withdrawal`) and are required for partner flows like delegated signing and sub-accounts.

**Documentation:** [Authentication](/developers/authentication) | [TypeScript SDK](/developers/sdk/typescript/getting-started) | [Python SDK](/developers/sdk/python/getting-started) | [Go SDK](/developers/sdk/go/getting-started) | [Rust SDK](/developers/sdk/rust/getting-started)

## Jul 13, 2026

### Trading restricted for Ontario and Alberta

Users in the Canadian provinces of Ontario (ON) and Alberta (AB) can no longer trade on the Platform. Ontario and Alberta now join the trading blocklist alongside the United States and the Republic of China. You can still browse markets, but you cannot place or fill orders.

* If you're located in ON or AB, you'll see a restriction when attempting to trade.
* Fully blocked jurisdictions (Russia, Belarus, Cuba, Iran, North Korea, Syria, and the Crimea, Donetsk, and Luhansk regions) are unchanged.

**Documentation:** [Terms of Service](/user-guide/terms-of-service)

## Jul 7, 2026

### Get market details: full response schema in the API reference

`GET /markets/{addressOrSlug}` now publishes its complete response schema, so the API playground renders a real example (instead of `<unknown>`) and integrators can generate clients directly from the spec.

* Covers all three market shapes returned by the endpoint — CLOB markets, NegRisk groups, and AMM markets — plus every nested object (venue, settings, tokens, resolution, creator, and more).
* No behavior change on the endpoint itself: fields returned in production are unchanged; this is a spec-completeness fix.
* If you generate types or clients from `openapi.json`, regenerate to pick up the concrete response types.

**Documentation:** [Get Market Details](/api-reference/markets/get-market)

## Jul 1, 2026

### Predictable, second-precision slugs for scheduled and recurring markets

Going live Wednesday, July 1. Recurring and upfront-scheduled CLOB market slugs become predictable, so market makers can precompute a slug before its market exists. This aligns the slug timestamp with Polymarket's convention and was driven by multiple MM requests.

* **Format change:** on recurring and scheduled markets, the slug timestamp suffix moves from a 13-digit millisecond value (set at creation time, carrying no real information) to a 10-digit Unix-second value taken from the slot's scheduled open time.
  * Before: `eth-up-or-down-5-min-1782716420095`
  * After: `eth-up-or-down-5-min-1782717300` (Polymarket parity: `eth-updown-5m-1782717300`)
* **Cadences:** applies to every recurring up/down series — 5-min, 15-min, hourly, daily, and weekly — plus upfront-scheduled markets. The suffix is the slot start in Unix seconds, so it aligns to the slot boundary (e.g. a multiple of `300` for 5-min, `3600` for hourly, `86400` for daily).
* **Ladder markets:** same second-precision suffix, taken from the market's start point (`openPriceAt`).
* **UGM markets:** still use a full millisecond timestamp (not precomputable), but now carry a dedicated `-ugm-` marker so they can be identified, e.g. `btc-above-dollar6024331-on-jun-28-1218-utc-ugm-1782648136065`.
* **Unchanged:** manually-launched markets and AMM markets keep the millisecond suffix.
* **Action:** if you parse or hardcode slug timestamps, switch to the seconds-based format. To fetch upcoming slot slugs without computing them, use the timeline endpoints.

**Documentation:** [Market Timeline](/api-reference/markets/timeline) | [Get Active Market Slugs](/api-reference/markets/active-slugs)

## Jun 29, 2026

### Market status values and `orderbookUpdate` payload documented

Two reference gaps closed for integrators reading market state and realtime orderbooks.

* `GET /markets/{slug}`: the market `status` enum is now documented — `FUNDED` (live and tradeable), `LOCKED` (trading paused, existing positions retained; typically just before resolution or an operator halt), `RESOLVED` (outcome known, winners can redeem), `FUNDED_FLAGGED` (live but flagged for review, treat as tradeable), and `DRAFT` (not yet funded, not tradeable). Treat any unrecognized future value defensively rather than assuming the market is tradeable.
* WebSocket `orderbookUpdate`: the payload is now spelled out with the concrete `bids`/`asks` schema and a field table, plus a precision/snapshot note pointing at `GET /markets/{slug}/orderbook`.

**Documentation:** [Get Market](/api-reference/markets/get-market) | [WebSocket Events](/developers/websocket-events)

## Jun 25, 2026

### Maintenance mode: detecting trading pauses

Production integrations can now detect and handle platform maintenance windows. During maintenance, trading can become post-only, cancel-only, or fully disabled, and trading endpoints may return `425 Too Early` with a trading-mode `code`.

* New `GET /maintenance/status` endpoint to check whether trading is currently restricted or a future maintenance notice is scheduled
* New **Maintenance Mode** developer guide covering when to check status, the trading modes, and `425` handling (do not retry a blocked action in a tight loop — refresh status and wait until the mode allows it)

**Documentation:** [Maintenance Mode](/developers/maintenance-mode) | [Maintenance Status](/api-reference/system/maintenance-status)

### Public portfolio: PnL chart endpoint

A public, read-only endpoint exposes an account's realized PnL over a timeframe — no authentication required for the read.

* `GET /portfolio/{account}/pnl-chart` returns a realized PnL series plus the current realized snapshot for the given account address, selected by a `timeframe` query (e.g. `1w`)
* Part of the public-portfolio read surface (alongside public positions and traded-volume); served read-only with caching, and the `account` address is normalized

**Documentation:** [Get PnL Chart (Public)](/api-reference/public-portfolio/pnl-chart)

### `/portfolio/orders`: cursor pagination

The authenticated `/portfolio/orders` read now supports keyset (cursor) pagination.

* Responses carry `nextCursor` (`null` on the last page) and an exact `total`
* Pass the returned cursor back along with `limit` to page forward — the cursor is opaque and resumes exactly where the previous page ended, with no duplicates across pages even when many orders share the same timestamp
* The legacy non-projection fallback is not paginated (returns the first `limit` orders with `nextCursor: null`) and is being retired

### Market creator: `username` and trade wallet

The `creator` object on market and group responses now includes the creator's `username` (alongside display name, image, and social link), and the creator `address` resolves to the creator's trade wallet (their smart wallet, or the signer EOA when the trade wallet is set to EOA).

**Documentation:** [Get Market](/api-reference/markets/get-market)

## Jun 24, 2026

### Packs: on-chain mechanics documented

The Packs guide now explains how a pack works on-chain. Each pack is a single Conditional Token (CTF) held in the user's own wallet, redeemable only if every leg resolves their way (otherwise it expires worthless). Buying a pack signs an EIP-712 intent covering the chosen pack, stake, and deadline, and winners claim permissionlessly on Base — there is no dependency on Limitless to release winnings. Risk is fixed to the stake.

**Documentation:** [Packs](/user-guide/packs#under-the-hood)

## Jun 22, 2026

### Market data clarifications and market pages discoverability

* Confirmed there is **no testnet or sandbox** — all integrations run against Base mainnet with real USDC. Rehearse a flow with small live orders on a low-volume market.
* Clarified that reported user volume is **lifetime** volume, and the fee difference between **claiming** a resolved win and **selling** a position before resolution.
* The **Market Pages** endpoints (category- and property-based filtering) are now surfaced in the API Reference navigation, and `GET /markets/active` points to them for structured filtering.

**Documentation:** [For Developers](/developers/introduction) | [Market Resolution](/user-guide/market-resolution)

## Jun 17, 2026

### Orderbook: deriving the NO book

`GET /markets/{slug}/orderbook` returns a single, YES-side book. The reference now documents the complementary-pricing identity — `price(YES) + price(NO) = 1` — so integrators can mirror the YES book into the NO book (flip bids and asks, replace each price `p` with `1 - p`) instead of assuming NO liquidity is missing. Native NO orders are already merged into the returned YES book. Multi-outcome (NegRisk) markets are covered too: each outcome has its own book and is derived independently.

**Documentation:** [Get Orderbook](/api-reference/trading/orderbook)

## Jun 14, 2026

### SDK WebSocket: authenticated subscriptions on HMAC

All four SDK WebSocket pages (TypeScript, Python, Go, Rust) now document authenticated subscriptions — positions, order events, and transactions — via `hmacCredentials` passed to the WebSocket client, which signs the handshake automatically. The Python page gained full authenticated-subscription examples to match the others. No `X-API-Key` is used on the WebSocket handshake.

**Documentation:** [TypeScript](/developers/sdk/typescript/websocket) | [Python](/developers/sdk/python/websocket) | [Go](/developers/sdk/go/websocket) | [Rust](/developers/sdk/rust/websocket)

## Jun 12, 2026

### Authentication docs standardized on HMAC

Active code examples across the developer docs now standardize on scoped API tokens with HMAC-SHA256 request signing (`lmts-api-key`, `lmts-timestamp`, `lmts-signature`). The legacy `X-API-Key` header has been removed from active examples. Existing API-key integrations continue to work, but new integrations should use HMAC scoped tokens.

**Documentation:** [Authentication](/developers/authentication)

## Jun 10, 2026

### Documentation accuracy pass

A sweep fixed copy-paste-breaking inaccuracies across the API and SDK references: scoped-token field names, SDK retry-timing units, WebSocket symbol and event names, and signing-payload details. It also clarified that `expiration` and `nonce` must both be `0` for standard CTF orders.

**Documentation:** [EIP-712 Signing](/developers/eip712-signing) | [Authentication](/developers/authentication)

## Jun 9, 2026

### Self-trade prevention on `POST /orders`

`POST /orders` now accepts an optional top-level `stpPolicy` for clients that want explicit self-trade handling. Available across the TypeScript, Python, Rust, and Go SDKs.

* Existing integrations keep the default `cancel_maker` behavior when `stpPolicy` is omitted.
* Supported values: `cancel_maker`, `cancel_taker`, `cancel_both`.
* `stpPolicy` sits outside the EIP-712 signed order payload (top-level request field).
* `cancel_taker` / `cancel_both` reject the incoming order with `execution.settlementStatus: "CANCELED"` and `execution.reason: "STP_TAKER_REJECTED"` on the `POST /orders` response.
* `cancel_maker` / `cancel_both` list the cancelled resting order ids in `execution.stpMakerCancels`; each cancelled maker emits a `CANCELLATION` order-event with `reason: "STP_MAKER_CANCELLED"`.
* Scope: blocks same-profile self-matches on the same token only; cross-token orders on the same profile are unaffected.

**Documentation:** [Create Order — Self-Trade Prevention](/api-reference/trading/create-order#self-trade-prevention)

## Jun 8, 2026

### Taker delay: async submission for marketable orders

Markets can now apply a **taker delay** — a short, per-market hold on marketable (taker) orders before the matching engine fills them. When a market has it enabled, order submission becomes asynchronous.

**What changes for integrators on a delay-enabled market:**

* A marketable order's `POST /orders` returns immediately with `execution.settlementStatus: "DELAYED"` and an `eligibleAt` timestamp — it no longer blocks until the trade is mined. Track the fill asynchronously over `subscribe_order_events` (provisional `MATCHED` → terminal `MINED` / `FAILED`), correlating by `clientOrderId` / `tradeEventId`.
* **`postOnly` orders are not affected** — maker quotes rest immediately, as today.
* Read a market's current delay from `settings.takerDelayMs` (milliseconds; `0` = none) on the market response.

**Documentation:** [WebSocket Events](/developers/websocket-events#subscribing-to-order-events)

## Jun 7, 2026

### Packs

A new product on Limitless. **Packs** are curated bundles of 2 to 3 predictions from different markets, presented as ready-made offers with a clear multiplier and a single buy-in window. A user wins only if every leg lands.

**What's live:**

* USDC collateral on Base, stake range \$1 to \$10, multiplier capped at 15x before vig
* 4% vig on crypto and sports packs, already baked into the displayed multiplier
* Pack listing states: Active, Hidden (no new buys; existing positions continue to resolve), Closed (terminal)
* User-held pack status: Active, Won, Lost; Won packs expose a Claim button until winnings are collected
* External wallets sign a one-time USDC approval for \$100 (covers up to 10 max-stake packs); each pack purchase needs a confirmation
* Limitless Safe wallets do not need ETH for gas; external EOA wallets need a small Base ETH balance when claiming

**Documentation:** [Packs](/user-guide/packs)

## Jun 5, 2026

### WebSocket order events: FAK/FOK terminal (`EXECUTION`) frame

Authenticated `subscribe_order_events` clients now receive a terminal `EXECUTION` frame the moment an immediate-or-cancel (FAK/FOK) order reaches its final state — no polling needed.

**What changed:**

* `source: "OME"` now carries a fourth `type`, `EXECUTION`, with a `status` of `FILLED`, `PARTIALLY_FILLED`, or `KILLED`
* `eventId` uses the string form `terminal:<orderId>`
* Delivered once, to the order owner; it carries no fee fields — read the `MINED` settlement frame or the `POST /orders` response for the realized fee
* A FOK that cannot fill is rejected with HTTP 400 and emits no terminal frame, so a FOK only ever appears as `FILLED`

**Documentation:** [WebSocket Events](/developers/websocket-events#subscribing-to-order-events)

## Jun 3, 2026

### WebSocket order events: pre-settlement `MATCHED` frame

Authenticated `subscribe_order_events` clients now receive a provisional `MATCHED` settlement frame the moment the matching engine fills an order — **before** the on-chain settlement transaction. This is the earliest "your order will be matched for N" signal. It is emitted per participant (the taker and each maker), each carrying its own side, token, fill size, and a fee **estimate** (`isEstimate: true`).

**What changed:**

* `source: "SETTLEMENT"` now carries three `type`s: provisional `MATCHED`, then terminal `MINED` or `FAILED`
* `MATCHED` uses its own `eventId` namespace `matched:<tradeEventId>:<orderId>`, distinct from the terminal `settlement:<tradeEventId>:<orderId>`, so the two never dedup-collide
* Correlate provisional → terminal by `tradeEventId` + `orderId`; settle accounting on `MINED` (realized fee + `txHash`), never on the `MATCHED` estimate

**Documentation:** [WebSocket Events](/developers/websocket-events#subscribing-to-order-events)

### Polymarket migration guide: updated for CLOB V2

Polymarket cut over to CLOB V2 around May 2026, deprecating the V1 SDKs and endpoints the original migration guide was built on. The entire **Migrate from Polymarket** page has been reframed against V2.

**What changed in the guide:**

* Polymarket collateral updated from USDC.e to pUSD
* New host `data-api.polymarket.com` documented for positions, trades, activity, and price history
* Cancel semantics, `/data/*` order endpoints, public search, and slug paths corrected to V2 conventions
* The Limitless side of every comparison table remains classic CTF (taker, expiration, nonce, feeRateBps)
* Getting Started navigation reordered to surface the migration guide earlier

**Documentation:** [Migrate from Polymarket](/developers/migrate-from-polymarket)

## Jun 2, 2026

### User-generated markets

Limitless now lets users propose and fund their own markets. A new user-guide page covers the flow end-to-end, and the Maker Rebates page has been updated alongside to reflect the current rebate eligibility surface.

**Documentation:** [User-Generated Markets](/user-guide/user-generated-markets) | [Maker Rebates](/user-guide/maker-rebates)

### Authentication: UI flow for scoped API tokens

The "Getting a Scoped API Token" section now documents the UI derivation flow (connect wallet, open the API token modal, derive) alongside the existing programmatic `POST /auth/api-tokens/derive` path. Most builders should use the UI; the programmatic path is for fully automated partner integrations that need to mint tokens on behalf of end users.

**Documentation:** [Authentication](/developers/authentication)

## Jun 1, 2026

### Markets: `winningOutcomeIndex` outcome mapping

The `winningOutcomeIndex` field on resolved markets is now explicitly documented as `0` = YES, `1` = NO. Integrators previously had to verify this convention empirically. The mapping is added to the `GET /markets/{slug}` reference, the Programmatic API guide, and the OpenAPI description for `winning_index`.

**Documentation:** [Get Market](/api-reference/markets/get-market) | [Programmatic API](/developers/programmatic-api)

## May 29, 2026

### Cross-market market making quickstart

A new dedicated quickstart for the agents-starter `cross-market-mm` strategy: quote on Limitless, hedge fills on Polymarket to stay delta-neutral. The page covers the one-key wallet model (EOA plus key-less ERC-1271 deposit wallet, pUSD held in it), a no-money dry-run flow that takes under 10 minutes, an honest 20 to 30 minute go-live path, the lifecycle commands, safety rails, and the economics.

**Economics callout:** Limitless charges takers only, so the maker bot pays no Limitless fee. Revenue is the cross-venue spread plus maker rebates (100% of eligible taker fees on Daily/Hourly Crypto and 15-min Crypto, fill-gated) plus LP rewards for resting orders near midpoint. Cost is the Polymarket hedge taker fee.

**Documentation:** [Cross-Market Market Making](/developers/cross-market-market-making) | [Build a Trading Agent](/developers/build-a-trading-agent)

### SDK retirement: Java quickstart removed

The Java quickstart has been removed from the developer documentation. It was unmaintained and out of line with current API behavior. The four supported developer quickstarts are now TypeScript, Python, Go, and WebSocket.

### Small audit fixes

* `GET /auth/api-tokens/capabilities`: profiles with no capability row return `tokenManagementEnabled: true` and `allowedScopes: ["trading"]`, not `false` and an empty array. The docs now match the backend handler.
* TypeScript SDK markets reference: `group.submarkets` corrected to `group.markets` (the field is `markets?: Market[]`). The previous samples would throw at runtime.

## May 28, 2026

### Market timeline endpoints

Two new endpoints let integrators pre-fetch upcoming recurring-market slots (5-minute crypto, hourly, etc.) before they open:

* `GET /markets/{slug}/timeline` for the schedule on a single recurring market
* `GET /markets/timeline` for the global upcoming schedule

**Documentation:** [Market Timeline](/api-reference/markets/timeline)

### Cancel authentication clarifications

`POST /orders/cancel` is not EIP-712 signed. It requires the `trading` scope. Cancels on behalf of sub-accounts via `onBehalfOf` additionally require the `delegated_signing` scope. The reference page now spells this out so partner integrations can scope their tokens correctly the first time.

**Documentation:** [Cancel Order](/api-reference/trading/cancel)

## May 27, 2026

### SDK update: current profile and partner account listing

All four official SDKs now expose helpers for authenticated current-profile reads and partner-owned sub-account listing/recovery.

**Current profile:**

* `GET /profiles/me` returns the authenticated caller's private profile without passing a wallet address
* SDK helpers:
  * TypeScript: `client.portfolio.getProfile()`
  * Python: `client.portfolio.get_current_profile()`
  * Go: `client.Portfolio.GetCurrentProfile(ctx)`
  * Rust: `client.portfolio.get_current_profile()`

**Partner account listing:**

* `GET /profiles/partner-accounts` lists child accounts owned by the authenticated partner or recovers one by `account`
* Requires HMAC authentication with the `account_creation` scope
* Do not send `x-on-behalf-of`; results are always scoped to the partner behind the HMAC token
* SDK helpers:
  * TypeScript: `client.partnerAccounts.listAccounts()`
  * Python: `client.partner_accounts.list_accounts()`
  * Go: `client.PartnerAccounts.ListAccounts(ctx, ...)`
  * Rust: `client.partner_accounts.list_accounts(...)`

**Documentation:** [Get Current Profile](/api-reference/portfolio/get-current-profile) | [List Partner Sub-Accounts](/api-reference/partner-accounts/list-partner-accounts) | [Programmatic API](/developers/programmatic-api) | [TypeScript SDK](/developers/sdk/typescript/partner-accounts) | [Python SDK](/developers/sdk/python/partner-accounts) | [Go SDK](/developers/sdk/go/partner-accounts) | [Rust SDK](/developers/sdk/rust/partner-accounts)

## May 25, 2026

### Pyth markets: full-precision open price and descriptions

New Pyth-resolved markets now expose the full oracle precision in `metadata.openPrice` and the auto-generated market description text. Chainlink-resolved markets are not affected.

* `metadata.openPrice` for new Pyth markets returns the full decimal value (e.g. `2132.21000000` instead of `2132.21`). Pyth crypto feeds typically use 8 decimal places.
* The strike price quoted inside the auto-generated market `description` text uses the same full-precision value.
* Chainlink markets continue to return the 18-decimal padded string in both `metadata.openPrice` and the description.
* No backfill — only Pyth markets created or activated after the cutover get the new shape. Existing markets remain as-is.

**Action for partners:** if you parse `openPrice` as a number, no change is needed. If you display it verbatim or regex-match against the rounded value inside descriptions, expect longer strings for new Pyth markets.

**Documentation:** [Market Resolution](/user-guide/market-resolution)

### Sports markets: updated titles and resolution wording

Football match markets get cleaner titles and more explicit resolution language. Existing markets are not affected; the changes apply to newly created markets.

* **Group titles** no longer include the match date. The scheduled date and time appears in the description body.
* **Solo market titles** are reformatted (e.g. "Both Home and Away score on Feb 17?" → "Home and Away both to score?"). Affects BTTS, TOTAL\_GOALS, CORNERS\_MATCH, CARDS\_MATCH, and SPREADS.
* **Descriptions** are expanded to a 3-paragraph format with explicit branches for: match completed on the pitch, match abandoned after kickoff (solo markets resolve based on official data recorded up to that point), and match canceled before kickoff or postponed beyond the resolution window.
* **Team-outcome markets** now explicitly recognize wins awarded by the competition authority when the match itself is not completed.

**Action for partners:** if you parse market titles for the match date, switch to the `deadline` field on the market object. If you regex-match descriptions for resolution wording, expect the new 3-paragraph format on newly created markets.

## May 20, 2026

### Receive window on `POST /orders`

`POST /orders` now accepts optional top-level `timestamp` (Unix ms) and `recvWindow` (ms) fields for clients that want order freshness checks. Both fields sit outside the EIP-712 signed order payload.

* Existing integrations are unchanged unless they send `recvWindow`.
* `recvWindow` must be between `1` and `10000` ms.
* A stale or future-dated timestamp returns HTTP `425 Too Early`. Build and sign a fresh order before retrying.

**Documentation:** [Create Order — Receive Window](/api-reference/trading/create-order#receive-window)

## May 7, 2026

### SDK update: partner withdrawal allowlist and expanded WebSocket coverage

All four official SDKs (TypeScript, Python, Go, Rust) now expose helpers for the partner withdrawal-address allowlist and a typed WebSocket subscription surface for the public realtime channels.

**Partner withdrawal-address allowlist:**

* `PartnerAccountService.addWithdrawalAddress()` — `POST /portfolio/withdrawal-addresses`
* `PartnerAccountService.deleteWithdrawalAddress()` — `DELETE /portfolio/withdrawal-addresses/:address`
* Both use a Privy identity token (`identity: Bearer <token>`), not API-token/HMAC auth
* `HttpClient.deleteWithIdentity()` exposed for identity-token authenticated DELETE requests
* `POST /portfolio/withdraw` continues to use HMAC auth with the `withdrawal` scope; `destination` is optional for child server-wallet withdrawals and defaults to the partner smart wallet (or partner account)
* Unit coverage added for identity-auth allowlist calls and explicit server-wallet withdrawal destinations

**WebSocket subscription / event surface:**

* Typed subscriptions for order events, live sports/esports, market lifecycle, oracle price data, and system messages
* Mirrors the `subscribe_*` channels documented on the WebSocket reference

**Documentation:** [TypeScript Partner Accounts](/developers/sdk/typescript/partner-accounts#withdrawal-address-allowlist) | [Python Partner Accounts](/developers/sdk/python/partner-accounts) | [Go Partner Accounts](/developers/sdk/go/partner-accounts) | [Rust Partner Accounts](/developers/sdk/rust/partner-accounts) | [Add Withdrawal Address](/api-reference/portfolio/add-withdrawal-address) | [Delete Withdrawal Address](/api-reference/portfolio/delete-withdrawal-address) | [WebSocket Events](/developers/websocket-events)

## May 5, 2026

### Combined cancel endpoints (orderIds + clientOrderIds)

A new `POST /orders/batch-cancel` endpoint accepts either internal `orderIds` or `clientOrderIds` (the value supplied at order creation time) in a single call. Provide exactly one identifier array — requests with both, or with neither, return `400 Bad Request`.

* `POST /orders/cancel-batch` remains supported for existing integrations and continues to accept `orderIds` only
* `clientOrderId` is also surfaced on the `subscribe_order_events` payload so partners can correlate WebSocket events to their own client-side IDs

**Documentation:** [Batch Cancel Orders (Combined)](/api-reference/trading/batch-cancel) | [Cancel Orders (Batch)](/api-reference/trading/cancel-batch) | [WebSocket Events](/developers/websocket-events#subscribing-to-order-events)

## May 4, 2026

### Withdrawal address whitelisting

Explicit treasury destinations for server-wallet withdrawals must now be allowlisted on the authenticated partner profile. Withdrawals to the partner account or partner smart wallet do not require allowlisting.

* `POST /portfolio/withdrawal-addresses` — add an allowlisted destination (Privy identity token)
* `DELETE /portfolio/withdrawal-addresses/:address` — remove an allowlisted destination (Privy identity token)
* `POST /portfolio/withdraw` — `destination` field now references allowlisted addresses for child server-wallet withdrawals; HMAC auth with the `withdrawal` scope unchanged

**Documentation:** [Add Withdrawal Address](/api-reference/portfolio/add-withdrawal-address) | [Delete Withdrawal Address](/api-reference/portfolio/delete-withdrawal-address) | [Withdraw](/api-reference/portfolio/withdraw)

## Apr 30, 2026

### Partner account allowance helpers

Server-wallet sub-accounts need delegated-trading approvals before they can trade. Two new endpoints (and matching helpers across all four SDKs) make the recovery flow explicit:

* `GET /profiles/partner-accounts/:profileId/allowances` — inspect approval state per target
* `POST /profiles/partner-accounts/:profileId/allowances/retry` — re-run any `missing` or `failed` retryable targets
* Both require HMAC credentials with `account_creation` and `delegated_signing`
* `409 Conflict` indicates a retry is already running; `429` returns `retryAfterSeconds`

Recommended flow: poll `checkAllowances` → if not ready and any target is retryable, call `retryAllowances` → on `submitted`, poll again after a short delay.

**Documentation:** [Check Allowances](/api-reference/partner-accounts/check-allowances) | [Retry Allowances](/api-reference/partner-accounts/retry-allowances) | [Programmatic API](/developers/programmatic-api)

### Restricted regions update

Russia and Belarus added to the list of restricted jurisdictions in the Terms of Service.

**Documentation:** [Terms of Service](/user-guide/terms-of-service)

## Apr 27, 2026

### Rust SDK v1.0.7: initial stable release

The official Rust SDK is now documented with full coverage for individual traders, bot builders, and partner integrations.

**Highlights:**

* Typed async client for CLOB and NegRisk markets
* Root `Client` entrypoint for markets, portfolio, market pages, API tokens, partner accounts, delegated orders, server wallets, and WebSockets
* Built-in EIP-712 order building and signing on Base
* API key and HMAC authentication support
* Async WebSocket streaming with reconnect handling
* Pluggable logging, retry helpers, and builder-style HTTP configuration

**Documentation:** [Rust SDK](/developers/sdk/rust/getting-started)

### Order execution: FAK orders added to signing and SDK docs

Fill-and-kill (FAK) orders are now documented across the developer guides. FAK orders use the same `price` and `size` inputs as GTC limit orders, match immediately against available liquidity, and cancel any unmatched remainder instead of resting on the book.

**Updated docs:**

* EIP-712 signing now includes FAK in the order type reference and amount-calculation guidance
* TypeScript SDK order docs include FAK examples and parameter reference
* Programmatic API delegated orders now show GTC, FAK, and FOK flows

**Documentation:** [EIP-712 Signing](/developers/eip712-signing) | [TypeScript SDK Orders](/developers/sdk/typescript/orders) | [Programmatic API](/developers/programmatic-api)

### WebSocket order events

Authenticated WebSocket clients can now subscribe to the CLOB order lifecycle with `subscribe_order_events`.

**New realtime stream:**

* Emits `orderEvent` messages for both off-chain matching-engine updates and on-chain settlement results
* OME events cover placement, updates, and cancellations
* Settlement events cover mined and failed transaction outcomes
* Auth failures are surfaced on the `exception` channel
* Clients should resubscribe on reconnect and treat OME and settlement events as independent streams

**Documentation:** [WebSocket Events](/developers/websocket-events#subscribing-to-order-events)

### Portfolio history cursor contract and partner position headers

Portfolio and partner account docs were updated for integrations that page through account activity or query positions on behalf of managed accounts.

**API documentation updates:**

* `GET /portfolio/history` now reflects the cursor-based pagination contract
* Position reads now document partner `onBehalfOf` usage for managed account flows
* Server-wallet redemption docs clarify the difference between API resolution state and on-chain conditional-token settlement

**Documentation:** [Portfolio History](/api-reference/portfolio/history) | [Get Positions](/api-reference/portfolio/positions) | [Programmatic API](/developers/programmatic-api#lifecycle-after-a-trade)

### Developer onboarding and partner flow updates

Developer onboarding now more clearly separates the individual trader/bot path from the platform/partner path.

**Updated guidance:**

* Individual traders and bot builders can use API keys or self-service scoped trading tokens without applying for partner access
* Platform partners should use backend-held HMAC credentials, sub-accounts, and delegated signing
* Programmatic API docs now include the partner application link and updated signing guidance

**Documentation:** [For Developers](/developers/introduction) | [Authentication](/developers/authentication) | [Programmatic API](/developers/programmatic-api)

### Brand assets and support contact

Brand assets were refreshed and the docs support link now points to `help@limitless.network`.

## Apr 14, 2026

### SDK v1.0.6: server wallet claim and full maker rebates

**Server wallet claim (all SDKs):**

* All three SDKs (TypeScript, Python, Go) now include helper methods for server wallet redemption and withdrawal
* `redeem` — claim resolved conditional-token positions from managed sub-accounts
* `withdraw` — transfer ERC20 funds from managed sub-accounts to partner wallets
* Previously these operations required direct REST calls; now fully supported in the SDK

**Maker Rebates program update:**

* Rebate rate increased to **100%** across all market types (daily, hourly crypto, 15-minute crypto)

**Documentation:** [Programmatic API](/developers/programmatic-api) | [TypeScript SDK](/developers/sdk/typescript/getting-started) | [Python SDK](/developers/sdk/python/getting-started) | [Go SDK](/developers/sdk/go/getting-started) | [Maker Rebates](/user-guide/maker-rebates)

## Apr 2, 2026

### Programmatic API: partner integrations, delegated signing, and FOK orders

Major new capability for partners building on Limitless. The Programmatic API enables platform integrations with sub-account management, server-side order signing, and both GTC and FOK order types — all through HMAC-authenticated scoped tokens.

**New API endpoints:**

* `POST /auth/api-tokens/derive` — Create scoped HMAC tokens with granular permissions (`trading`, `account_creation`, `delegated_signing`)
* `GET /auth/api-tokens/capabilities` — Check partner capability configuration
* `GET /auth/api-tokens` — List active tokens
* `DELETE /auth/api-tokens/:tokenId` — Revoke a token
* `POST /profiles/partner-accounts` — Create sub-accounts with server-managed wallets or EOA verification

**Delegated signing:**

* Partners with the `delegated_signing` scope can submit unsigned orders on behalf of sub-accounts
* The server signs orders using Privy-managed wallets — no private key management needed on the partner side
* Both **GTC** (limit) and **FOK** (market) order types are supported for delegated orders
* FOK orders use `makerAmount` (USDC to spend for BUY, shares to sell for SELL) instead of `price` + `size`

**Recommended architecture:**

* Store HMAC credentials on your backend — never expose them to frontends
* Use the SDK server-side to sign partner-authenticated requests
* Expose only your own app-specific endpoints to the frontend

**Documentation:** [Programmatic API guide](/developers/programmatic-api) | [Authentication](/developers/authentication#scoped-api-tokens-hmac) | [API Tokens reference](/api-reference/api-tokens/derive-token)

### SDK v1.0.4–1.0.5: programmatic API support (TypeScript, Python, Go)

All three official SDKs now include full support for the Programmatic API:

**New services across all SDKs:**

* `ApiTokenService` — Derive, list, and revoke scoped HMAC tokens
* `PartnerAccountService` — Create sub-accounts with server wallets or EOA verification
* `DelegatedOrderService` — Place GTC and FOK orders on behalf of sub-accounts, cancel orders

**New root `Client` entrypoint:**

* Composes all domain services (markets, portfolio, orders, API tokens, partner accounts, delegated orders) behind a single constructor
* HMAC credentials are configured once and applied to all requests automatically

**TypeScript SDK:**

* `Client` with `hmacCredentials` option
* `client.apiTokens`, `client.partnerAccounts`, `client.delegatedOrders`
* WebSocket HMAC authentication support
* [TypeScript SDK docs](/developers/sdk/typescript/getting-started)

**Python SDK:**

* `Client` with `hmac_credentials` option
* `client.api_tokens`, `client.partner_accounts`, `client.delegated_orders`
* WebSocket HMAC handshake support
* [Python SDK docs](/developers/sdk/python/getting-started)

**Go SDK:**

* `NewClient(limitless.WithHMACCredentials(...))`
* `client.ApiTokens`, `client.PartnerAccounts`, `client.DelegatedOrders`
* WebSocket HMAC authentication support
* [Go SDK docs](/developers/sdk/go/getting-started)

## Mar 23, 2026

### SDK v1.0.3: market pages navigation

All three SDKs now support the market pages navigation API for browsing markets by category.

**New capabilities:**

* Navigation tree discovery
* Market page resolution by path with automatic redirect handling
* Market listing with filters, pagination, and cursor support
* Property keys and options for dynamic filtering

**TypeScript:** [Market Pages](/developers/sdk/typescript/market-pages) | **Python:** [Market Pages](/developers/sdk/python/market-pages) | **Go:** [Market Pages](/developers/sdk/go/market-pages)

### Go SDK v1.0.3: initial stable release

First stable, production-ready release of the Go SDK with full feature parity.

**Highlights:**

* EIP-712 order signing with private key (Base mainnet)
* GTC and FOK order support
* WebSocket streaming with Socket.IO protocol, auto-reconnect, and typed event handlers
* Configurable retry with exponential backoff
* Functional options pattern throughout (`WithBaseURL`, `WithAPIKey`, `WithLogger`, etc.)
* Zero external dependencies beyond `go-ethereum` and `gorilla/websocket`

**Documentation:** [Go SDK](/developers/sdk/go/getting-started)

## Mar 2026

### WebSocket market lifecycle events

New WebSocket events for market creation and resolution, enabling real-time monitoring of market lifecycle changes.

* `market.created` — Fires when a new market is created
* `market.resolved` — Fires when a market resolves

**Documentation:** [WebSocket Events](/developers/websocket-events)

## Feb 2026

### SDK v1.0.2: stable LTS release (TypeScript and Python)

First stable, long-term support releases of the TypeScript and Python SDKs.

**Core features across both SDKs:**

* API key authentication with `X-API-Key` header
* EIP-712 order signing with venue-aware contract resolution
* GTC and FOK order creation with automatic signing
* Market data fetching with intelligent venue caching
* Portfolio and position tracking
* WebSocket streaming with auto-reconnect
* Retry mechanisms with configurable backoff strategies
* NegRisk market support with dual approval system

**TypeScript SDK highlights:**

* Full TypeScript type safety with comprehensive type definitions
* 17 production-ready code samples
* `@retryOnErrors` decorator and `withRetry` wrapper
* [TypeScript SDK docs](/developers/sdk/typescript/getting-started)

**Python SDK highlights:**

* Async-first architecture built on aiohttp
* Pydantic models for type-safe request/response handling
* `@retry_on_errors` decorator
* [Python SDK docs](/developers/sdk/python/getting-started)

### Python SDK v1.0.2: float precision fix

Fixed IEEE 754 float precision issues in order pricing that could cause incorrect `makerAmount`/`takerAmount` calculations (e.g., `0.95` scaling to `949999` instead of `950000`).

## Dec 2025

### API: cookie-based authentication removed

Cookie-based session authentication has been removed. All programmatic access now requires API keys (`X-API-Key` header) or scoped API tokens (HMAC).

**Action required:** If you were using cookie-based authentication, migrate to API key authentication. Generate keys at [limitless.exchange](https://limitless.exchange) under profile menu → API keys.

**Documentation:** [Authentication](/developers/authentication)

## Nov 2025

### Initial SDK releases (pre-release)

Pre-release versions of the TypeScript (v0.0.1) and Python (v0.1.0) SDKs launched with core trading functionality including market data access, GTC/FOK order creation, and portfolio tracking.