docs: sync with official Polymarket docs (2026-07-09)

Updates across 25 files:
- api-reference/core: get-user-combo-activity, get-user-combo-positions
- dev-tooling/python
- polymarket-learn/FAQ: wen-token, what-are-prediction-markets, why-do-i-need-crypto
- polymarket-learn/deposits: coinbase, how-to-withdraw, moonpay, usdc-on-eth
- polymarket-learn/get-started: how-to-deposit, how-to-signup, making-your-first-trade, what-is-polymarket
- polymarket-learn/markets: dispute, how-are-markets-clarified, how-are-markets-created, how-are-markets-resolved
- polymarket-learn/trading: holding-rewards, how-are-prices-calculated, limit-orders, liquidity-rewards, market-orders, no-limits
- resources/error-codes

docs/api-reference/core/get-user-combo-activity.md

@@ -71,6 +71,14 @@ paths:
             default: 0
             minimum: 0
             maximum: 10000
+        - in: query
+          name: cursor
+          schema:
+            type: string
+          description: >-
+            Opaque continuation token from a previous response's
+            pagination.next_cursor. When present it supersedes offset (which is
+            ignored). Invalid, tampered, or cross-endpoint tokens return 400.
       responses:
         '200':
           description: Success
@@ -198,7 +206,12 @@ components:
         next_cursor:
           type: string
           nullable: true
-          description: Opaque cursor for the next page; null when has_more is false.
+          description: >-
+            Opaque signed cursor for the next page; null when has_more is false.
+            Pass it back verbatim as ?cursor= on the next request (keep the same
+            sort where the endpoint has one). Never parse or construct it. On
+            cursor-enabled endpoints this makes deep pagination O(page) and
+            stable against concurrent inserts.
     ComboLeg:
       type: object
       properties:

docs/api-reference/core/get-user-combo-positions.md

@@ -62,6 +62,7 @@ paths:
               - first_entry_desc
               - entry_cost_desc
               - resolved_at_desc
+              - updated_asc
             default: current_value_desc
         - in: query
           name: market_id
@@ -81,14 +82,43 @@ paths:
             type: integer
             default: 20
             minimum: 0
-            maximum: 100
+            maximum: 1000
         - in: query
           name: offset
           schema:
             type: integer
             default: 0
             minimum: 0
-            maximum: 10000
+            maximum: 100000
+        - in: query
+          name: updatedAfter
+          schema:
+            type: integer
+          description: >-
+            Incremental-sync watermark (epoch seconds, inclusive): only rows
+            whose updated_at is at or after this time. Positions mutate on
+            resolution and redemption, so this catches changes a creation-time
+            filter cannot. In sync mode
+            (updatedAfter/updatedBefore/sort=updated_asc) every live row is
+            returned regardless of balance, and the effective upper bound is
+            clamped ~90s behind now (commit-visibility safety lag) — very recent
+            rows appear on the next poll. Rows at the boundary may re-deliver:
+            upsert by (combo_condition_id, combo_position_id).
+        - in: query
+          name: updatedBefore
+          schema:
+            type: integer
+          description: >-
+            Optional upper bound (epoch seconds, inclusive) for updated_at;
+            clamped to the safety lag. Must be >= updatedAfter.
+        - in: query
+          name: cursor
+          schema:
+            type: string
+          description: >-
+            Opaque continuation token from a previous response's
+            pagination.next_cursor. When present it supersedes offset (which is
+            ignored). Invalid, tampered, or cross-endpoint tokens return 400.
       responses:
         '200':
           description: Success
@@ -193,6 +223,13 @@ components:
         resolved_at:
           type: string
           nullable: true
+        updated_at:
+          type: string
+          description: >-
+            Last-modified time (UTC, ISO 8601). Bumps on any recompute of the
+            row (trade, redemption, resolution classification) — the
+            incremental-sync watermark field. Omitted on responses served by the
+            legacy backend.
         legs_total:
           type: integer
         legs_resolved:
@@ -218,7 +255,12 @@ components:
         next_cursor:
           type: string
           nullable: true
-          description: Opaque cursor for the next page; null when has_more is false.
+          description: >-
+            Opaque signed cursor for the next page; null when has_more is false.
+            Pass it back verbatim as ?cursor= on the next request (keep the same
+            sort where the endpoint has one). Never parse or construct it. On
+            cursor-enabled endpoints this makes deep pagination O(page) and
+            stable against concurrent inserts.
     ComboLeg:
       type: object
       properties:

docs/dev-tooling/python.md

@@ -1102,6 +1102,10 @@ Secure clients expose the API credentials created for the authenticated session.
 
 ## Changelog
 
+### `0.1.0b16`
+
+* Fixed Deposit Wallet trading setup approvals to use the current Protocol V2 auto-redeem operator.
+
 ### `0.1.0b15`
 
 * Added support for Perps.

docs/polymarket-learn/get-started/making-your-first-trade.md

@@ -208,7 +208,7 @@ GTD orders auto-expire at a specified time. Useful for quoting around known even
       .size(dec!(10))
       .side(Side::Buy)
       .order_type(OrderType::GTD)
-      .expiration(Utc::now() + TimeDelta::hours(1))
+      .expiration(Utc::now() + TimeDelta::minutes(1) + TimeDelta::hours(1))
       .build()
       .await?;
   let signed = client.sign(&signer, order).await?;
@@ -217,9 +217,11 @@ GTD orders auto-expire at a specified time. Useful for quoting around known even
 </CodeGroup>
 
 <Note>
-  There is a security threshold of one minute on GTD expiration. To set an
-  effective lifetime of N seconds, use `now + 60 + N`. For example, for a
-  30-second effective lifetime, set the expiration to `now + 60 + 30`.
+  GTD orders expire one minute before their stated expiration as a security
+  threshold. To set an effective lifetime of N seconds, use `now + 60 + N`.
+  In addition, the expiration must be at least three minutes in the future —
+  orders expiring sooner are rejected — so the minimum effective lifetime is
+  about two minutes.
 </Note>
 
 ***

docs/polymarket-learn/trading/market-orders.md

@@ -208,7 +208,7 @@ GTD orders auto-expire at a specified time. Useful for quoting around known even
       .size(dec!(10))
       .side(Side::Buy)
       .order_type(OrderType::GTD)
-      .expiration(Utc::now() + TimeDelta::hours(1))
+      .expiration(Utc::now() + TimeDelta::minutes(1) + TimeDelta::hours(1))
       .build()
       .await?;
   let signed = client.sign(&signer, order).await?;
@@ -217,9 +217,11 @@ GTD orders auto-expire at a specified time. Useful for quoting around known even
 </CodeGroup>
 
 <Note>
-  There is a security threshold of one minute on GTD expiration. To set an
-  effective lifetime of N seconds, use `now + 60 + N`. For example, for a
-  30-second effective lifetime, set the expiration to `now + 60 + 30`.
+  GTD orders expire one minute before their stated expiration as a security
+  threshold. To set an effective lifetime of N seconds, use `now + 60 + N`.
+  In addition, the expiration must be at least three minutes in the future —
+  orders expiring sooner are rejected — so the minimum effective lifetime is
+  about two minutes.
 </Note>
 
 ***

docs/resources/error-codes.md

@@ -271,6 +271,10 @@ These errors are returned when an order passes initial validation but fails duri
   `the market is not yet ready to process new orders`
 </ResponseField>
 
+<ResponseField name="500" type="Internal Server Error">
+  `order timed out` — The exchange could not process the order before the request deadline. This typically happens during bursts of concurrent order submissions from the same account. The order was rejected before reaching the order book and can be safely resubmitted.
+</ResponseField>
+
 ***
 
 ## Matching Engine Errors