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 and perpetual futures. All resting orders are limit orders. There are no market orders as a distinct type.

Price-Time Priority

Orders on the book are matched using price-time priority:

1. Price: the best-priced resting order fills first. Bids ranked highest-first, asks ranked lowest-first.
2. 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:

TIF

Name

Behavior

Use case

GTC

Good Till Cancelled

Rests on the book until filled or you cancel it

Default. Passive limit orders, providing liquidity.

IOC

Immediate or Cancel

Fills whatever crosses immediately, cancels the rest

Aggressive execution. "Market order" equivalent.

FOK

Fill or Kill

Fills the entire size immediately or cancels everything

All-or-nothing. Large block orders that should not partially fill.

💡

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

• Automatic 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 orderbook fallback for multi-leg

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

RPI Orders (Retail Price Improvement)

On instruments configured for both orderbook and RFQ, single-leg orders automatically enter 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
• Each market maker has 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

Fills here never violate your limit price.

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

Same behavior as submitting a limit order directly.

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.

Auction window

2 seconds

Min. improvement

1 tick

Partial fills

None

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. There is no CLOB for arbitrary multi-leg packages, so market makers are the only counterparty.

RFQ has two modes:

Manual accept

1. You submit a package via POST /rfq/request with your legs (instrument, side, size per leg)
2. The system fans out the request to all eligible quote providers
3. QPs respond with firm quotes (valid for up to 30 seconds)
4. You see all quotes in the app and manually select one to accept
5. 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

1. You submit a package via POST /rfq/request with an auto_accept_limit (the maximum debit you will pay, or minimum credit you will accept)
2. Your signature pre-authorizes execution at any price within your limit
3. The first quote that meets or beats your limit is automatically executed without a second signature
4. 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.

Manual accept

Auto-execute

Signatures required

2 (submit + accept)

1 (submit with limit)

Quote selection

You choose which quote to accept

First qualifying quote wins

Execution speed

Depends on how fast you accept

Instant when a qualifying quote arrives

Price control

You see exact prices before committing

Pre-authorized limit. May fill at better than limit.

Expiry risk

Quotes may expire while you review

No manual acceptance delay. Request can still expire if no quote meets your limit.

Multi-leg fills are always all-or-nothing. The entire package executes atomically, or not at all. This eliminates leg risk.

Perp Orders (Directives)

Perpetual futures orders go through a separate path. Instead of the options orderbook, perp orders are submitted as directives to HyperCore (Hyperliquid's on-chain execution layer).

Perp orders are submitted via POST /v1/actions/hl_limit_order and support:

Feature

Details

Order types

Limit only (use IOC TIF for market-order behavior)

Time-in-force

GTC, IOC, ALO (Add Liquidity Only, rests or cancels, never crosses)

Reduce-only

Supported. Order can only reduce an existing position, never increase it.

Cancel

By order ID (hl_cancel_by_oid) or client ID (hl_cancel_by_cloid)

Execution

On-chain via HyperCore precompile. Settlement is atomic.

RPI/RFQ

Not applicable. Perp orders go directly to the on-chain book.

Perp orders do not pass through the RPI auction or RFQ system. They are signed, relayed to the on-chain exchange contract, and matched on-chain.

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. Each enters the standard execution path independently.
• Bulk cancel (DELETE /bulk_order or DELETE /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-30MAY26-80000-C at a limit of $2,450.

Book state

Book reference

MM requirement

Result

Best ask: $2,448

$2,448

At or below $2,447.9999

MM quotes $2,447.50. Filled with $2.50 improvement vs. book.

Partial ask: $2,448 for 0.1 contracts

$2,448

At or below $2,447.9999

MM must still improve the displayed book price to fill your full order.

Best ask: $2,455

None

At or below your $2,450 limit

MM quotes $2,450. Filled at your limit without jumping resting liquidity.

No resting asks

None

At or below your $2,450 limit

MM quotes $2,450. Filled at your limit.

Best ask: $2,448

$2,448

At or below $2,447.9999

MM quotes $2,448.50 (not enough improvement). Rejected. You cross book at $2,448.

Price improvement display

• When filled via RPI against an executable book reference, the app shows your savings vs. the book
• When no executable book reference exists, the app shows that the quote filled within your limit
• Example: "Filled at $2,447.50, saved $2.50 (0.1%)"
• This appears automatically on your fill confirmation, no action required

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:

Trading mode

Limit orders

RPI auction

RFQ

Typical use

Orderbook + RFQ

Yes (Phase 2 fallback)

Yes (Phase 1)

Yes (multi-leg)

Most option instruments at launch

Orderbook only

Yes (direct)

No

No

Highly liquid instruments with deep books

RFQ only

No

No

Yes (no book fallback)

Illiquid or newly listed instruments

As instruments mature and attract more resting liquidity, they transition from RFQ-enabled to orderbook-only. The routing is transparent to you. 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.

Common Misconceptions

Common misconceptions

The mistakeMarket makers can match resting book liquidity and take the fill in RPI

The realityThey must beat executable resting liquidity by at least 1 tick. If no executable resting liquidity exists, matching your limit is allowed.

The mistakeThe 2-second RPI auction delays my order significantly

The realityThe auction terminates early if all connected MMs respond. In practice, latency is often well under 2 seconds. Phase 2 placement is immediate after.

The mistakeI need to opt in to RPI or toggle a setting

The realityRPI is automatic for all eligible instruments. There is no toggle, no mode switch, and no separate order type.

The mistakeMulti-leg orders can fall back to the orderbook

The realityThere is no CLOB for arbitrary multi-leg packages. If no MM fills the package, the RFQ expires. You can resubmit or leg in individually.

The mistakeIOC is the same as a market order

The realityIOC still requires a limit price. It crosses whatever is available at or better than your limit, then cancels the unfilled portion. You can never fill worse than your stated price.

FAQ