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

# Hyperliquid-compatible

> Spot maker orders through Hyperliquid exchange, info, and WebSocket endpoints.

Use the Hyperliquid spot maker API to place, modify, and cancel individual orders. Existing orders stay open when you place another one. The adapter supplies order IDs, open-order queries, client order IDs, and order/fill subscriptions. No book snapshots are required.

The [quickstart](/makers/quickstart) uses the unmodified Hyperliquid Python SDK. Spire confirms access and the endpoint running this adapter during [onboarding](/makers/onboarding). No Hyperliquid account or deposit is required.

## Endpoints

Use the base URL supplied by Spire. The standard hostname is `https://mm.baibai.cx`.

| Endpoint         | Purpose                                                              |
| ---------------- | -------------------------------------------------------------------- |
| `POST /exchange` | Signed orders, modifications, cancellations, and API-wallet approval |
| `POST /info`     | Metadata, books, balances, orders, and fill history                  |
| `/ws`            | Hyperliquid WebSocket requests and subscriptions                     |

`spotMeta` describes the available markets. The SDK resolves `WETH/USDC` to its spot asset. WETH-USDC uses a `0.01` USDC price tick and `0.0001` WETH size increment. Off-grid orders are rejected. Settlement remains on Base mainnet, chain ID `8453`; see [funding and withdrawals](/makers/funds).

## Supported orders

| Operation                | Behavior                                                                                    |
| ------------------------ | ------------------------------------------------------------------------------------------- |
| `order` / bulk orders    | Adds resting `Gtc` or `Alo` limit orders                                                    |
| `modify` / `batchModify` | Replaces the named order, assigning a new ID; invalid modifications leave the original open |
| `cancel`                 | Cancels the named order IDs                                                                 |
| `cancelByCloid`          | Cancels by your 16-byte client order IDs                                                    |
| `scheduleCancel`         | Cancels all open orders at an absolute time; survives restarts                              |

Batches return a result for each entry. Default modifications require the original order to be open and make a resting GTC replacement post-only. The Hyperliquid `always_place` flag (`a:true`) can place the replacement even if the original has closed. Limits are 1000 open orders per master and 1000 entries per batch. GTC orders survive disconnects and gateway restarts. Use `scheduleCancel` for a deadman; disconnecting does not cancel orders. Arm the schedule before placing quotes: it also caps their published curve deadline, so expiry still applies if the gateway stops. A schedule change cannot rewrite a curve already on-chain. The minimum scheduling horizon is five seconds and at most ten scheduled cancellations may trigger per UTC day.

This adapter supports resting spot liquidity. Marketable orders, IOC/market orders, triggers, reduce-only, grouped orders, builder fees, perpetuals, and vault delegation are rejected. Hyperliquid funding and withdrawal actions are not supported; use BaiBai's [custody flow](/makers/funds).

## Integration checklist

Obtain maker approval, fund your master wallet, and wait for available inventory. Then use one nonce allocator per signing key, track order IDs, and persist fills using their `tid`. On reconnect, query open orders and fill history; do not replace your entire book. See [signing](/makers/authentication), [WebSocket requests](/makers/websocket), and [fills](/makers/fills).

An accepted cancellation removes an order from the gateway. Its earlier on-chain curve may still execute until replaced or expired. Those fills retain the original order ID, including after a modification. The general docs explain [curves and allocation](/makers/trading-and-allocation) and [settlement timing](/makers/fills-and-latency).
