> For the complete documentation index, see [llms.txt](https://docs.nexus.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexus.xyz/apis-and-rates/apis-and-rates/market-maker-guide.md).

# Market maker guide

Quoting on the Exchange: post-only, cancel-on-disconnect, rate-limit tiers, and maker rebates.

This guide covers what a market maker needs to integrate with the Nexus Exchange. The exchange is API-first and has no MM-specific UI. You quote, cancel, and stream over the same REST and WebSocket APIs every client uses, with a higher rate tier and a maker-only order type.

For the basics, this guide links to the reference pages rather than restating them: [REST](/apis-and-rates/apis-and-rates/exchange-rest.md), [WebSocket](/apis-and-rates/apis-and-rates/exchange-websocket.md), [Rate Limits](https://docs.nexus.xyz/api-reference/guides/rate-limits), [Rate & connection limits](/apis-and-rates/apis-and-rates/rate-limits.md), and the [Quickstart](/trading/trading/quickstart.md).

## 1. Get MM-tier access

The **Market Maker** rate tier (**a budget of 2,000 weight per second**, of which a plain order submit costs 1) is admin-assigned, not self-serve. See [Rate Limits](https://docs.nexus.xyz/api-reference/guides/rate-limits) for how requests are costed. Request the tier through your Nexus contact with your `key_id`. Until promoted, a key runs at the base tier. MM keys also get higher WebSocket ceilings (100 simultaneous connections vs. 5 at base, and 1,000 subscriptions vs. 50).

> Testnet-preview note: tier assignment and rate-limit state are currently in-memory at the gateway and reset on restart. After a gateway redeploy, an MM key may briefly fall back to base until it is re-promoted. A key also carries its own ceiling from the moment it was created (20/s by default), and a promotion does not rewrite it. Check `GET /account/rate-limit` after being promoted, since the effective limit is whichever of the two binds first, and mint a fresh key if it still reports the base number.

## 2. Authenticate

The [section overview](/apis-and-rates/apis-and-rates.md) describes the standard flow. Use a wallet-signed session token (EIP-191) to create an **HMAC API key**, then sign every request with the key. The session token is for key management only, never for trading. Store the HMAC secret safely, because it is shown only once.

## 3. Orders for market making

The order type that matters most for market making:

* **Post-only.** Set `time_in_force: "PostOnly"` on a limit order. The engine **rejects** the order (rather than filling) if it would cross the book and take liquidity on entry, so you always rest as a maker. A crossing post-only order comes back as an `InvalidOrder` with code **`WouldTakeLiquidity`**. Detect that and re-quote. This is the main way to avoid paying taker fees.
* Standard `GTC` / `IOC` / `FOK` are also available for the non-resting cases.
* **Batch + cancel-all.** Use batch order placement to refresh a quote ladder in one request, and market-scoped cancel-all to pull quotes on a market quickly. Amend is available for in-place price/size changes. (See [REST reference](/apis-and-rates/apis-and-rates/exchange-rest.md).)

## 4. Stream the market

Subscribe over [WebSocket](/apis-and-rates/apis-and-rates/exchange-websocket.md) rather than polling:

* **Order book** and **trades** for the market data you quote against.
* **Your fills / orders / positions** (private channels) to track quote state. Mint a single-use ws-token with `POST /ws/token`, then connect.

Connection and subscription caps are per-tier (MM: 100 connections, 1,000 subscriptions) and form their own budget, separate from the REST one. See [Rate Limits](https://docs.nexus.xyz/api-reference/guides/rate-limits). Subscriptions are capped per connection *and* across all of an account's connections at the same number, so spreading a quote ladder over more sockets does not raise the total. Design for reconnects. The client should re-subscribe and re-sync book state on reconnect, and the 2× inbound-frame burst allowance covers a resubscribe storm.

## 5. What to expect on latency & throughput

**We do not publish a latency figure for this venue yet.** Earlier revisions of this page carried an order-to-ack p95 and a WebSocket delivery p95 that were internal engineering targets, not measurements of the deployed testnet preview. Both have been removed rather than restated, because a latency number a desk cannot reproduce is worse than no number.

What we can tell you today:

* **Rate ceiling, not a measured capacity.** The MM tier admits **2,000 weight per second** per key (see [Rate & connection limits](/apis-and-rates/apis-and-rates/rate-limits.md)). That is the configured admission ceiling. It is not a measured saturation point and not a throughput commitment. Pace against the `x-ratelimit-*` headers on every response and back off on `429` + `retry-after`. Two things about those headers matter. `x-ratelimit-remaining` counts **unit-cost** requests, so it overstates how many heavy reads are left. Order writes draw on a **separate** budget from reads, so a healthy `remaining` on your last read says nothing about placement headroom.
* **Measure latency from your own client, and hold us to what you measure.** The numbers that matter to a quoting strategy are the REST order-to-ack round trip and matching-event-to-WebSocket-frame delivery. Both depend on your network path as much as on the venue, so act on your own measurement. Tell your Nexus contact what you get. A reproducible client-side number from a real desk is more useful to us than an internal one.
* **Latency goals tighten across release gates**, as noted in the [WebSocket reference](/apis-and-rates/apis-and-rates/exchange-websocket.md). When we publish a figure it will carry its conditions: environment, client location, network path, offered load, what the timer starts and stops on, and percentiles from a single run rather than averaged across runs.

## 6. Tooling

* **SDKs.** Rust (`nexus-exchange` on crates.io), Python (`nexus-exchange` on PyPI, from the `nexus-exchange-py` repository), and TypeScript (`@nexus-xyz/exchange-ts` on npm) all wrap this API, including request signing.
* **CLI.** `nexus-exchange-cli` (`nexus`) is a thin command layer over the Rust SDK.
* **CCXT.** Operations that map to a CCXT unified method carry an `x-ccxt-method` annotation in the OpenAPI spec. CCXT compliance is a stated target that is still being built and tested, so check CCXT-based MM tooling against the spec before relying on it.

## 7. Testnet status

This is a testnet preview: balances are testnet USDX (no real funds), state can reset on redeploy, and tier/rate-limit ceilings are configurable and may change as the tier system is finalized across release gates. Treat API keys as re-creatable.

The ceilings for every tier are published on [Rate Limits](https://docs.nexus.xyz/api-reference/guides/rate-limits); this guide gives only the Market Maker figures.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.nexus.xyz/apis-and-rates/apis-and-rates/market-maker-guide.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.