Market Maker Guide

Everything a market maker needs to integrate with the Nexus Exchange. The exchange is API-first — there is no MM-specific UI; you quote, cancel, and stream over the same REST + WebSocket surface every client uses, with a higher rate tier and a maker-only order type.

For the primitives, this guide points at the reference pages rather than restating them: REST, WebSocket, Rate & Connection Limits, and the Quickstart.

1. Get MM-tier access

The Market Maker rate tier (2,000 req/s per key) is admin-assigned, not self-serve — see Rate & Connection Limits. Request it via your Nexus contact with your key_id. Until promoted, a key runs at the base tier. MM keys also get a higher WebSocket connection cap (100 simultaneous connections vs. 5 at base).

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 re-promoted.

2. Authenticate

Standard flow (details in the section overview): 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. Keep the HMAC secret safe; it's shown once.

3. The maker order surface

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, guaranteeing you 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 primary tool for never 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.)

4. Stream the market

Subscribe over WebSocket 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 via POST /ws/token, then connect.

Connection and subscription caps are per-tier (MM: 100 connections); see Rate & Connection Limits. Design for reconnect: the client should re-subscribe and re-sync book state on reconnect.

5. What to expect on latency & throughput

Measured on the current testnet preview (experimental, not an SLA):

• Order-to-ack ~5 ms p95, WebSocket delivery ≤ 50 ms p95 under sustained market-making load.
• The MM tier sustains 2,000 req/s per key; a sustained-load run at 50 req/s held p95 well under the ack target with zero rejects. Pace against the X-RateLimit-* headers on every response and back off on 429 + Retry-After.

6. Tooling

• SDKs: Rust (nexus-exchange, published to crates.io), Python (nexus-exchange-py), and TypeScript (nexus-exchange-ts) all wrap this API, including request signing.
• CLI: nexus-exchange-cli (nexus) is a thin command layer over the Rust SDK.
• CCXT: the API exposes CCXT-compatible endpoints (tagged in the OpenAPI spec), so existing CCXT-based MM tooling connects with minimal changes.

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.

---

Doc note (ENG-2755): the tier ceilings above track rate-limits.md. One known inconsistency to reconcile (ENG-4062): that page lists the Pro tier at 200 req/s while the indexer's in-code default (DEFAULT_PRO_RPS) is 20 — the gateway config is the effective authority for the public number; the discrepancy is flagged for reconciliation, not resolved here.