Hyperliquid order types control execution prices, timing, and unfilled quantity
Updated on
Hyperliquid order types determine how an order seeks liquidity and what happens to its unfilled quantity. A buy limit caps the execution price; a sell limit sets a floor. Market orders seek immediate execution, while conditional orders wait for a trigger. Time-in-force settings govern resting or cancellation, and reduce-only constrains position changes. The choice turns on whether price control, immediate execution, or gradual execution matters most, with available liquidity limiting completion.
A limit price constrains execution, while time-in-force settings determine whether unmatched quantity stays available for a later fill.
Market execution and firm price boundaries
Market orders seek available liquidity immediately, so execution can span different prices across the order book. The Python SDK implements its market-order helpers through aggressive immediate-or-cancel (IOC) limit orders with a slippage allowance. That allowance establishes an execution boundary; it does not promise the displayed price or a complete fill. Larger requested quantities can require matching farther through the available book.
A buy limit permits fills at its price or lower, while a sell limit permits its price or higher. A marketable limit can therefore execute immediately. At a nonmarketable price, the order needs new matching liquidity before it can trade. Price-time priority also matters: earlier resting orders at the same price have priority. A price appearing in recent trades does not establish that sufficient quantity remains available for another order.
Which setting keeps an unfilled limit order open?
GTC, meaning good till canceled, allows unmatched limit quantity to remain on the book for later execution. A marketable GTC order can fill immediately and leave its remainder resting. Choosing GTC therefore accepts continued execution opportunities after the initial submission.
IOC cancels any quantity that cannot execute immediately instead of leaving it on the order book. A partial fill remains possible. IOC suits an immediate attempt within a price boundary when leaving a pending remainder would be undesirable.
ALO, meaning add liquidity only or post-only, prevents immediate matching. An order that would take existing liquidity is canceled rather than executed. Its purpose differs from IOC: ALO requires resting execution, whereas IOC requires immediate execution. The limit price and this setting work together. Neither setting overrides the price boundary to complete the requested quantity.
Trigger prices and executable exit prices
Stop Market and Take Market activate market orders at their trigger conditions; Stop Limit and Take Limit activate limit orders. For position take-profit and stop-loss (TP/SL) orders, the mark price supplies the trigger. The trigger price determines activation, while the execution condition determines which available prices the order can accept.
A stop-limit exit can remain unfilled after activation if the market moves beyond its limit. A more permissive limit admits worse execution prices and increases the opportunity to match. Market TP/SL orders also have a slippage boundary, so triggering alone does not prove that a position closed. The useful distinction is between an activated instruction and executed quantity.
Reduce-only and position direction
Reduce-only restricts an order to decreasing an existing position. An order that would increase exposure fails that constraint. This setting belongs beside the execution choice when the intended action is a reduction or close. It does not supply liquidity, remove a limit price, or make a triggered exit certain to fill. A reduce-only rejection calls for checking the intended direction against the position, rather than removing the constraint automatically.
A rejected post-only buy and a resting replacement
Consider a hypothetical buy with a maximum acceptable price, sufficient available funds, and a requirement to avoid taking liquidity. The selected market, prices, available quantity, and subsequent order responses in this example are hypothetical.
The reader selects ALO, but the submitted price crosses the best available ask. Hyperliquid rejects the order because it would match immediately. No fill results from that rejected instruction.
The smallest adjustment is to reconsider the limit price while retaining ALO. After reviewing the changed bid and ask, the reader chooses a nonmarketable buy price within the original maximum. In this example, the replacement receives a resting status and has no fills. The buy remains open awaiting liquidity.
Its eventual cost remains unresolved. Filled quantity, execution prices, and the applicable maker fee determine the purchase cost if matching later occurs. The order’s requested size alone establishes no completed purchase or fixed charge.
Scale, Chase, and TWAP execution
Scale places multiple limit orders across a selected price range. Chase instead reprices a post-only limit to follow the best bid or ask. Chase runs in the browser tab that created it, making that tab an operating dependency.
TWAP, meaning time-weighted average price, divides an order into smaller submissions over a chosen duration. Their interval depends on total size and running time. Price-trigger and termination settings can govern when the schedule starts or stops; optional randomization varies suborder size.
A TWAP can finish its running time without executing its full requested quantity. Slippage limits can prevent suborders from filling, and later attempts to catch up remain constrained. Scale distributes prices, Chase follows quotations, and TWAP distributes execution through time. Each leaves completion dependent on matching conditions.
Does a limit order always receive maker fees?
A limit order does not automatically receive maker fees because it can immediately take existing liquidity. Resting execution and immediate matching have different fee treatment. The applicable schedule also depends on the market and account fee tier, so an order label cannot establish total cost. Compare the acceptable execution price with the actual maker or taker charge. Perpetual funding is a separate payment that a position can owe or receive, depending on its direction and the funding rate. Choosing a limit order does not eliminate funding. The next choice is whether to accept a pending remainder, require immediate execution, or require resting execution.
Popular questions about Hyperliquid order types
-
What happens to attached TP/SL orders when I cancel a partially filled parent order?
- Manually canceling a partially filled parent also cancels its attached TP/SL orders. Protecting the resulting position requires separate position-associated exits. Cancellation for insufficient margin has different behavior: after a partial fill, it causes the attached TP/SL orders to be placed.
-
Do position TP/SL orders resize after I specify an exit quantity?
- A position TP/SL order with an explicitly configured quantity keeps that fixed size when the position changes. Whole-position exits instead attempt to close the position size at triggering. The distinction matters after adding to or reducing exposure.
-
Can a resting perpetual order face another margin check before filling?
- A resting perpetual order faces a margin check when matching occurs, even though it passed the check at placement. Changes in margin conditions can therefore affect later execution. Resting status confirms an open instruction, without reserving an unconditional right to a future fill.
-
Why might a market order fail without executing any quantity?
- A market order can fail when no matching liquidity is available. A more aggressive execution instruction cannot create an opposing order. The returned error distinguishes this condition from insufficient margin, an invalid price increment, or another input problem.
-
How are time-in-force choices written in a Hyperliquid API order?
- The limit-order object’s tif field accepts Alo, Ioc, or Gtc, with that exact capitalization. Reduce-only is a separate order field. Trigger orders use a different type object containing the trigger price, market-or-limit selection, and TP or SL designation.