Hyperliquid 'Order must have minimum value' error, and what's next

CoTrading editorial team 2026-09-23

Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs.

Hyperliquid returns Order must have minimum value of $10. for a perp order, or Order must have minimum value of 10 {quote_token}. for a spot order, when the order’s notional is below the venue’s minimum. The number sits inside the string, and Hyperliquid sets it — it can change, so read the current value on the error responses page rather than hard-coding it from here.

This page is for anyone placing Hyperliquid orders through the API — a bot, an SDK, or an AI assistant with trading tools. It covers why the error is easy to miss, what usually produces it, and the other order rejections that tend to turn up alongside it.

What this error actually means

The docs label the perp version MinTradeNtl and the spot version MinTradeSpotNtl. Both mean the same thing: the notional value of the order is below the minimum. For spot the minimum is denominated in the pair’s quote token, which is why the string carries {quote_token} rather than a dollar sign.

The same rejection shows up later in order history. The info endpoint’s order status for it is minTradeNtlRejected, described as “Rejected due to order notional below minimum”. If you are reconciling after the fact, that is the status to search for.

Why your code may not notice

This error arrives inside a successful response. Hyperliquid’s documented example is an HTTP 200 whose top-level status is ok:

{"status":"ok","response":{"type":"order","data":{"statuses":[{"error":"Order must have minimum value of $10."}]}}}

The rejection is in response.data.statuses[i].error. Per the docs, “Order and cancel errors are usually returned as a vector with same length as the batched request” — so in a batch of five orders, statuses 0, 2 and 4 can be resting while 1 and 3 were rejected.

Code that checks the HTTP code, or only the top-level status, will log the order as placed. The first sign of trouble is then a position that never appeared or a stop that does not exist. Check every element of statuses, and treat an error key as a failed order.

There is one exception to the per-order vector. Some errors are “a deterministic function of the payload itself”, and for those “only one error is returned for the entire payload”. The docs’ examples include an empty batch, a TP/SL that is not reduce-only, an order too far from the reference price, and some tick-size validation. Batch code needs to handle both shapes. The general pattern is in API error handling patterns.

The usual cause: size that shrank on the way to the order

Few people set out to place an order below the minimum. The size gets there by arithmetic:

Rounding to the asset’s size decimals. Sizes must respect the asset’s szDecimals (from the meta info request). Rounding a computed size down to fit can drop it below the minimum, especially on assets with a high unit price and few size decimals.
Risk-based sizing on a small account. A position size calculator will happily tell you a correct size whose notional is under the venue minimum. The maths is right; the venue will not take it.
Slicing. Splitting one order into many — a grid, a ladder, a scaled entry — can leave every slice under the minimum even when the total is well above it.
Closing a remainder. After partial fills, what is left of a position can be small. We did not find a statement in Hyperliquid’s docs on whether a reduce-only close of a remainder below the minimum is exempt, so do not build on the assumption that it is. Order lifecycle and partial fills covers where those remainders come from.

Which price sets the notional? The docs describe the trigger as order notional below the minimum and do not spell out which price is used for an aggressive, market-style order. Leave headroom above the minimum rather than sizing exactly to it.

Other rejections you’ll see next to it

The same statuses vector carries the rest of the documented order errors. These are the ones that tend to appear once the minimum-value problem is fixed:

Docs label	String (verbatim)	What to check
Tick	`Price must be divisible by tick size.`	Price precision; the rules are on the tick and lot size page. Some tick errors reject the whole payload
ReduceOnly	`Reduce only order would increase position.`	Whether the position is on the side you think, at the size you think
BadAloPx	`Post only order would have immediately matched, bbo was {bbo}.`	A post-only order priced through the book
IocCancel	`Order could not immediately match against any resting orders.`	Immediate-or-cancel with nothing to hit
PerpMargin	`Insufficient margin to place order.`	Margin available for a new order at the leverage you set
Oracle	`Order price too far from oracle`	Limit price far from the oracle price

Two of these need more than a glance.

Tick size. Hyperliquid expresses its price rules as limits on significant figures and decimal places, which differ between perps and spot. Read the tick and lot size page and implement its rules rather than guessing a tick. If you sign requests yourself, that page also says trailing zeroes should be removed — a separate way to break a signature, covered in User or API Wallet does not exist.

Reduce-only. The order-time rejection is the string above. There is also a later outcome: order status reduceOnlyCanceled, “Canceled reduced-only order that does not reduce position”, for a resting reduce-only order the position no longer supports. How reduce-only behaves generally is in what is a reduce-only order.

How to confirm which one you have

Log the full statuses array, with the index of each order in the batch, for every /exchange call. When an order seems to have vanished, the first thing to rule out is an unread error in a 200 response.
Recompute notional for the rejected order from the size and price you actually sent — after rounding — not the values your strategy intended.
Compare against the current minimum on the error responses page. Keep it in configuration, not in code, since it lives in a string Hyperliquid can change.
For historical orders, query order status and look for minTradeNtlRejected, tickRejected or reduceOnlyRejected.
Do not auto-retry a rejected order at a larger size without re-checking position state. A retry after a partial failure is how duplicate exposure happens; see why retrying a failed order is not safe.

If you also trade on centralised exchanges, their equivalent rules work differently; symbol filters and minimum order size covers that side.

FAQ

Why does Hyperliquid return “status ok” for a rejected order?

Hyperliquid reports order and cancel results per order, inside a successful envelope. The documented example is an HTTP 200 with "status":"ok" and the rejection in response.data.statuses[i].error. You have to read each status in the vector to know whether that order was accepted.

What is the minimum order value on Hyperliquid?

It is the value embedded in the error string, as published on Hyperliquid’s error responses page. Perp orders have a dollar-denominated minimum and spot orders one denominated in the quote token. Hyperliquid sets it and can change it, so read the current page and keep the value in configuration.

Why did my Hyperliquid order fall below the minimum when my size looked fine?

Usually because of rounding. Sizes must respect the asset’s size decimals, and rounding down to fit can push the notional under the minimum. Slicing an order into smaller pieces and closing small remainders after partial fills do the same.

What does “Price must be divisible by tick size” mean on Hyperliquid?

The order price does not satisfy Hyperliquid’s price precision rules, which depend on significant figures and decimals and differ between perps and spot. Implement the rules from Hyperliquid’s tick and lot size page. Some tick-size validations reject the entire batch with a single error rather than per order.