Six venues. One order surface. No rounding up.

REST info endpoint plus the public websocket. Tickers and books are served from a cached asset-context snapshot with rate-limit-aware exponential backoff; candles and trades have their own ingestion subscribers; the market universe is discovered from the meta endpoint.

Market and limit orders, GTC / IOC / post-only, reduce-only, client order ids, tick and size rounding taken from the asset metadata, plus cancel and single-order status. Retries on rate limits without duplicating an order.

Clearinghouse positions with leverage mode and unrealised PnL, withdrawable balance, open orders, the full historical order set, user fills and funding history.

One of the three venues the dynamic adapter factory can build on demand, so the router can actually send the order it recommends.

Exchange info, 24h tickers, prices and depth through the broker market-data service, a Binance-compatible websocket client for streaming, and candle plus trade subscribers in the ingestion pipeline.

The router adapter places and cancels orders and sets leverage before sizing. The broker service covers the wider order-type set — stop, stop-market, take-profit, trailing stop — with reduce-only and close-position flags.

Reads work, but not from the router adapter. That class deliberately stubs positions, balances, open orders and the history calls to empty results and throws on ticker and orderbook; the broker services and the ingestion pipeline serve those instead.

Routable. The adapter factory builds an Aster adapter from an encrypted key pair and wallet address, and the router sets leverage before it sends the order.

Tickers and full orderbooks from the mainnet REST API, a streaming websocket client, market discovery from the explorer API, and candle plus trade subscribers.

Place and cancel, either against stored encrypted credentials or with a key passed in directly. Requests are queued so nonces never collide, and the key format is validated before a signature is attempted.

Open positions, open orders, per-order status, historical orders, user trades and an account-info read used by the balances endpoint. Funding history is the one gap.

Routable. The adapter factory validates the 40-byte key, the account index and the key index, then builds the adapter on demand.

Tickers, symbols, prices and market stats over REST, plus a websocket client with an orderbook manager that coalesces book updates on a 100ms tick. Pacifica is also one of the sources the aggregated orderbook merges.

Market and limit orders, cancel, cancel-all and close-position, all signed with the account's Solana key and bounded by the venue's minimum order size and slippage limits.

Account info, balance, positions in both raw and normalised shapes, open orders, an account summary, trading limits, and trade history with per-symbol PnL.

Not routable today. The API accepts pacifica as a preferred venue and the aggregator reads its book, but the dynamic adapter factory only builds Hyperliquid, Aster and Lighter adapters, so a routed order preferring Pacifica is rejected at credential validation.

A dedicated connection pool holds one websocket to Pear's market-data channel — the whole market set arrives as a single snapshot — with a 30-second REST poll as a fallback so ratio history keeps accumulating if the socket drops. Ratio history has its own service and route.

Through Pear: EIP-712 login for a JWT, then create, close, adjust and re-leverage positions across sync, market, trigger, TWAP, ladder, take-profit and stop-loss execution types. Through multi: the pair engine sizes each leg from its weight, places the legs with per-venue rate limiting and retries, and reports open, partial or failed.

Processed open positions and an account summary from Pear, and locally-executed pair positions tracked with their entry ratio and per-leg fills.

Pair intents do not go through the single-symbol router. They have their own endpoints, and the pair engine picks Hyperliquid by default or Lighter on request.

Pair listings, open interest, leverage bounds and per-pair fees from the public socket API, with prices polled from Pyth every two seconds and pair data every thirty. There is no orderbook, because Avantis does not have one.

Nothing. No adapter, no signing path, no order route. Opening or closing an Avantis position is done at Avantis.

Open positions decoded from the user-data API with entry price, liquidation price, leverage and rollover fee, plus limit orders, paged trade history, and deployed collateral netted out of the Base USDC balance.

Not routable. Avantis appears in the aggregated orderbook's source list and is an accepted venue name in the API, but no adapter exists for the router to execute against.