Order Priority
How orders are routed, who gets to fill them, and in what order.
Orderbook Fundamentals
Hypercall runs a central limit order book (CLOB) for options. All resting orders are limit orders. There are no market orders as a distinct type. Perpetuals do not trade on this book: they are native Hyperliquid orders (see Perp Orders below).
Price-Time Priority
Orders on the book are matched using price-time priority:
- Price: the best-priced resting order fills first. Bids ranked highest-first, asks ranked lowest-first.
- Time: at the same price level, the order that arrived earliest fills first.
When an incoming order crosses resting liquidity, it fills immediately against the best available prices. Any unfilled remainder rests on the book (or is cancelled, depending on time-in-force).
Time-in-Force
Every order includes a time-in-force (TIF) instruction:
There is no dedicated "market order" type. To get market-order behavior, submit a limit order with TIF set to IOC at a price you are willing to pay. The order crosses whatever is available and cancels any unfilled portion.
Maker and Taker
Every fill has two sides:
- The maker is the party whose order was already resting on the book.
- The taker is the party whose incoming order crossed it.
Makers and takers pay 0% fees under the launch configuration. See Fees for the launch policy and planned future schedule.
Order Types
Hypercall supports several execution paths depending on what you are trading and how you submit:
Limit Order
Single-leg options, direct to book
- Standard limit order on the orderbook
- Crosses resting liquidity or rests at your price
- Available on orderbook-only instruments
- Time-in-force: GTC, IOC, or FOK
RPI Order
Single-leg options, auction + book
- Default on RFQ-eligible instruments
- 2-second MM auction before the book
- MMs must beat the reference price by ≥ 1 tick
- Falls back to a standard limit order if no MM fills
RFQ
Multi-leg packages
- Request for Quote to professional market makers
- Manual accept or auto-execute with a limit
- Atomic fill: entire package or nothing
- No book fallback: use a combo order for that
Limit Orders
The simplest path. You submit a price, size, side, and symbol. The engine checks your margin, validates your EIP-712 signature, and places the order on the book.
If the book has resting liquidity at or better than your limit, you cross immediately. Otherwise, your order rests until filled or cancelled.
This is the execution path for instruments configured as orderbook-only (no RFQ/RPI layer), and for any order sent with route: "book_only". Reduce-only orders, bulk orders and WebSocket orders also go straight to the book.
RPI Orders (Retail Price Improvement)
On instruments configured for both orderbook and RFQ, a POST /order with route: "best_execution" (or no route) enters a two-phase execution pipeline. This is the default path on the Hypercall frontend.
Phase 1: RPI Auction
Market makers compete to fill your order
- Order is broadcast to all connected quote providers
- Market makers have 2 seconds to respond with a firm quote
- If executable book liquidity exists, every quote must strictly improve on that book price
- If no executable book liquidity exists, every quote must satisfy your limit
- Best-priced quote wins (ties broken by arrival time)
- Auction closes early if all market makers respond
- If a qualifying quote wins, you are filled immediately at or better than your limit
Phase 2: Limit Fallback
Your order becomes a standard limit order
- Activates only if Phase 1 produces no qualifying fill
- Order is placed on the orderbook at your original limit price
- Crosses immediately if resting liquidity exists at or better than your limit
- Otherwise, order rests until filled or cancelled
- Standard time-in-force applies (GTC, IOC, FOK)
- Total latency from submission to Phase 2: ~2 seconds
The structural logic comes from equity market programs like CBOE BYX's Retail Price Improvement and the NYSE Retail Liquidity Program: market makers earn the privilege of seeing your order before the book only when they do not jump executable resting liquidity without improving it.
RFQ (Request for Quote)
RFQ is used for multi-leg orders (spreads, straddles, iron condors, risk reversals) and for single-leg instruments configured as RFQ-only. Market makers are the only counterparty, and there is no book fallback: if no quote fills, the request expires. For a fixed-ratio package you can also send a combo order instead.
RFQ has two modes:
Manual accept
- You submit a package via
POST /rfq/requestwith your legs (instrument, side, size per leg) - The system fans out the request to all eligible quote providers
- QPs respond with firm quotes (valid for up to 30 seconds)
- You see all quotes in the app and manually select one to accept
- You sign and submit an accept (
POST /rfq/accept) to execute the trade
Manual accept gives you full control over which quote you take. The tradeoff is a second signature and the risk of quotes expiring while you decide.
Auto-execute
- You submit a package via
POST /rfq/requestwith anauto_accept_limit(the maximum debit you will pay, or minimum credit you will accept) - Your signature pre-authorizes execution at any price within your limit
- The first quote that meets or beats your limit is automatically executed without a second signature
- If no qualifying quote arrives before the RFQ expires, the request expires with no fill
Auto-execute is faster and simpler. You set your worst acceptable price upfront and let the system execute. This is the mode the Hypercall frontend uses for multi-leg packages.
Multi-leg fills are always all-or-nothing. The entire package executes atomically, or not at all. This eliminates leg risk.
Combo Orders
A combo order trades a fixed ratio of 2 to 8 option legs on one underlying as a single limit order at a net package price. Every leg fills together or none does, and your resulting positions are the individual options.
- Routing: with
best_execution, the package first goes through the RPI auction at the full package size, then to the book. Withbook_only, it skips the auction. - Liquidity: it can match other combo orders for the same package and supported implied liquidity built from the outright leg books.
- Time in force: GTC rests the unfilled package remainder, IOC cancels it, FOK executes the full package quantity or nothing.
- In the app: the multi-leg ticket offers a combo limit order when every leg is an active, book-enabled option on the same underlying. You can still request RFQ quotes for the same package.
The API for combos is experimental. See the Experimental Combo API for discovery, signing, and current restrictions.
Perp Orders
Perpetual futures are Hyperliquid perps. They do not trade on Hypercall's book and do not pass through the RPI auction or RFQ. Hypercall's engine checks each perp order against your whole portfolio margin account first, then it reaches Hyperliquid through a secure enclave on the TEE route (the app default, opt-in over the API; those orders carry Hypercall's builder address) or through your account contract on the advanced smart contract route, and it matches on Hyperliquid's order book under Hyperliquid's rules.
See Perps on Hypercall for the full order path and Perp Order Types for each type.
Bulk and Replace Operations
For programmatic traders, the API supports batch operations:
Bulk and replace endpoints
- Bulk place (
POST /bulk_order): Submit up to 50 orders in one request. Bulk orders go straight to the orderbook (book_only) and do not enter the RPI auction. - Bulk cancel (
DELETE /bulk_orderorDELETE /bulk_order_cloid): Cancel up to 50 orders by order ID or client ID in one request. - Replace (
PUT /order): Atomically cancel an existing order and place a new one in the same engine tick. No gap risk. - Bulk replace (
PUT /bulk_order): Replace up to 50 orders atomically.
Replace operations are critical for market makers who need to update quotes without exposing themselves to being filled on the old price while the new order is in flight.
Price Improvement (RPI)
The core guarantee of the RPI auction: a market maker cannot jump executable resting liquidity unless it gives you a better price than the book. Any within-limit resting liquidity, even if it is smaller than your order, sets the book reference. Your limit remains the worst acceptable execution price, not the price-improvement benchmark when no book liquidity exists.
The reference price
The reference price is the best within-limit resting book price a market maker must beat. The displayed size at that price does not need to cover your full order. If there is no executable resting liquidity, the quote only needs to satisfy your limit.
Buy Orders
- If best ask <= your limit, reference = best ask on book
- MM must quote at or below reference minus 1 tick
- If there is no executable ask, MM may quote at or below your limit
Sell Orders
- If best bid >= your limit, reference = best bid on book
- MM must quote at or above reference plus 1 tick
- If there is no executable bid, MM may quote at or above your limit
This is the same principle behind CBOE BYX Rule 11.24: RPI orders must improve on the NBBO. On Hypercall, the "NBBO" is the best executable resting price on the orderbook.
Worked example
You submit a buy order for 1.0 BTC-20260530-80000-C at a limit of $2,450.
Quote Providers
Quote providers (QPs) are professional market makers registered on Hypercall. They maintain persistent WebSocket connections and receive both RPI auction requests and multi-leg RFQs in real time.
QP eligibility
- Registered and active (not suspended)
- Whitelisted for the relevant underlying (or approved for all underlyings)
- Not frozen by Market Maker Protection (MMP) on that underlying
- Connected via WebSocket at the time of the auction or RFQ
Multiple QPs compete on each auction. The system selects the best price, breaking ties by arrival time. This competition is the mechanism that drives price improvement. As more QPs join, competition intensifies and spreads tighten.
See Market Maker Protection (MMP) for how QPs manage risk, and Incentives for market maker programs.
Instrument Eligibility
Each instrument has a configured trading mode that determines how orders are routed:
Every option currently listed on mainnet runs in Orderbook + RFQ mode. The trading mode is set per instrument and can change; you always submit the same order type regardless of which mode the instrument is in.
Fill Priority Summary
When a single-leg order enters the system on an RPI-eligible instrument, fills are prioritized:
1. RPI Auction
First look (eligible instruments only)
- Market makers compete for your order
- Must satisfy your limit
- Must improve on executable resting liquidity by at least 1 tick
- Best quote wins, ties broken by arrival time
- Fill may include price improvement
2. Book Cross
Immediate fill on existing liquidity
- Activates if no RPI fill
- Crosses against resting orders at or better than your limit
- Standard price-time priority
- May fill partially (standard matching)
3. Resting Order
Wait for a counterparty
- Activates if no immediate cross
- Order rests at your limit price
- Visible on the orderbook
- Subject to your time-in-force setting
On orderbook-only instruments, the flow starts at step 2 (no RPI auction). The system never fills you at a price worse than your limit.