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, WebSocket, Rate Limits, Rate & connection limits, and the Quickstart.

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 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 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.)

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 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. 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). 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. 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; this guide gives only the Market Maker figures.