No DMM program

The official market-making page states that there is no DMM program, special fee arrangement or latency advantage. Anyone can market-make through the public exchange interfaces and APIs.

Infrastructure location, state handling, risk limits, quoting logic and capital still affect execution results.

Post-only intent and queue risk

ALO orders protect maker intent by preventing immediate taker execution. They do not guarantee a fill, favorable queue position or profitable spread. A Chase order reprices in the browser and is not a substitute for a server-side quoting engine.

A maker must handle partial fills, self-trade prevention, tick and lot constraints, stale quotes and cancel acknowledgements. Never assume a local order state is final until reconciled with exchange state.

Spread and rebates must exceed real losses

Gross spread and maker rebates are only the visible revenue. Adverse selection, inventory drift, funding, hedging, failed cancels, slippage and liquidation can dominate them.

Hyperliquid’s maker-rebate tiers depend on the user’s share of rolling weighted maker volume. A zero maker-fee tier and a negative maker rebate are separate conditions; model the actual account response.

Run a minimal control loop

Check the long cap against the current position plus all open bid size. Check the short cap against the current position minus all open ask size. A position-only check can fail when several open orders fill before the next loop.

Use scheduleCancel as a dead man's switch and renew the deadline while the process is healthy. The deadline must be at least five seconds in the future. The protocol permits at most 10 triggered cancel-all events per UTC day.

Start on testnet, then use minimal mainnet size. A backtest does not reproduce queue position or live adverse selection.

  1. Snapshot: read a fresh l2Book plus the account position, open orders and recent fills.
  2. Quote: calculate ALO bid and ask prices and sizes. Include open-order exposure when you apply the inventory and notional caps.
  3. Acknowledge: submit a unique cloid for each order and check every order or cancel status. Keep an order pending when the response is missing.
  4. Reconcile: combine orderUpdates and userFills with an openOrders query. Query the account address, not the API wallet address.
  5. Cancel stale orders: cancel each acknowledged order that uses old book data, old inventory or removed quote intent. Confirm the cancel status and reconcile again.
  6. Kill switch: cancel open orders after stale data, a missed acknowledgment, feed loss, a cap breach or a loss limit. Stop new signing and require an operator reset.
snapshot -> quote -> submit -> acknowledge -> reconcile -> cancel stale

if stale_data || acknowledgment_timeout || inventory_cap || loss_limit:
  cancel_all -> stop_signing -> require_operator_reset