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

# V1.0.64

# Monaco Protocol SDK v1.0.64

This release rolls up the consumer-facing changes since v1.0.62. Order history — `sdk.trading.getPaginatedOrders` — now always returns an item count in **both** pagination modes, bounded by a server ceiling so a large history never drives an unbounded count, and the response carries a new `totalCapped` flag that tells you when that count is a lower bound. The response **schema** is additive — `totalCapped` is new and nothing is removed — but the count **values** change in two cases: cursor (`pageToken`) mode now populates `total` and `totalPages` — a count over full history, hot and archived rows merged — where it previously returned `0`, and a page-number caller with more than the ceiling of matching orders in its recent-history window now reads the capped ceiling instead of the exact count of that window. Check `totalCapped` to tell an exact count from a saturated one. v1.0.63 shipped no consumer-facing changes.

## Added

### Order history returns a bounded item count in both pagination modes

`sdk.trading.getPaginatedOrders` (`GET /api/v1/orders`, authenticated; gRPC `OrdersService.ListOrders`) now populates `total` and `totalPages` in **both** pagination modes — legacy page-number and cursor (`pageToken`) alike — where cursor mode previously returned `0` for both and offered no exact total. The count is **bounded by a server ceiling of 10,000**: it stays exact up to that many matching orders and saturates there, so a wallet with a very large order history no longer triggers an unbounded `COUNT` over the orders table on every page render. `pageSize` up to 1000 in cursor mode is unchanged.

`GetPaginatedOrdersResponse` gains `totalCapped` (`boolean`): `true` when **more than** the ceiling matched, so `total` and `totalPages` are a **lower bound** — at least that many orders exist — rather than an exact figure; `false` when `total` is exact, including exactly the ceiling, which is still reported exactly. `total` and `totalPages` are **no longer deprecated** now that both modes populate them; only `page` stays deprecated and still comes back as `0` in cursor mode.

Neither pagination loop breaks: cursor walks still terminate on an empty `nextPageToken`, and page-number loops that stop at `page >= totalPages` keep terminating. The count values are not identical to before, though: in cursor mode `total` and `totalPages` (a count over full history, hot and archived merged) were `0` and are now populated, and a page-number caller with more than 10,000 orders in its recent-history window now reads the capped ceiling rather than the exact count of that window (a page-number caller under the ceiling still reads the same exact `total`). Code that reads `total` as an exact figure should treat a capped value as "at least this many" and check `totalCapped` to tell an exact count from a saturated one.

See [Order history](/sdk/typescript/trades) and [the API reference](/api-reference).

## Upgrade

```bash theme={null}
npm install @0xmonaco/core@1.0.64 @0xmonaco/types@1.0.64 @0xmonaco/react@1.0.64
# or bun
bun add @0xmonaco/core@1.0.64 @0xmonaco/types@1.0.64 @0xmonaco/react@1.0.64
```

The response schema is additive, so there is no signature change to adopt. But order-history counts now behave differently in two cases — cursor mode populates `total`/`totalPages` where it returned `0`, and a page-number count above 10,000 saturates at the ceiling — so if you read `total` as an exact count, treat a capped value as "at least this many" and read the new `totalCapped` flag to tell an exact count from a saturated one.