Hyperliquid Tick Size and Lot Size: Why Orders Get Rejected
How Hyperliquid tick size, lot size, and szDecimals work, and how to round order sizes so API and app orders are not rejected.
Direct answer
Each Hyperliquid asset has a size precision published as szDecimals, and order sizes must be rounded to that many decimals. If a size has too many decimals the order is rejected. Prices also follow tick rules, so an order priced off-grid can fail. Read each asset's metadata rather than assuming one precision for every market.
In short
- 1szDecimals sets how many decimals an order size may have.
- 2Precision differs by asset, so read it from metadata.
- 3Round sizes before submitting to avoid rejections.
What are tick and lot size?
Tick size is the smallest allowed price step and lot size is the smallest allowed size step. Hyperliquid expresses size precision through the szDecimals field in asset metadata.
How do I round a size?
If an asset has szDecimals of 3, a size of 0.1234 is invalid and 0.123 is valid. Round down so you never exceed the intended size. A value like 0.5 BTC and a value like 12,345 of a low-priced token require different precision.
Where is the precision published?
Perpetual metadata from the public info API lists szDecimals for each asset, and the same endpoint family exposes margin and leverage limits. Fetch it once and cache it, but refresh periodically since markets are added.
What if an order still fails?
Check price against the tick rule, the minimum order value, and that the asset identifier matches the market. In the app, reduce size to a supported step; in code, apply the rounding before signing.
Example: rounding a size
Say an asset has szDecimals of 2 and you want to buy 1.2345 units. The valid sizes are 1.23 and 1.24. Rounding down to 1.23 keeps you within your intended exposure. Submitting 1.2345 would be rejected.
If you automate orders, apply this step in code before signing, and refresh the metadata so a new asset's precision is not guessed.
Common mistakes
Round down, validate against current metadata, and log rejected orders.
- Assuming every asset uses the same decimals.
- Rounding up and exceeding a risk limit.
- Caching metadata forever.
Practical next steps
If you place orders through the app, reduce size to the nearest supported step whenever an order is refused and confirm the price is on the tick grid. If you automate, fetch perpetual metadata at startup, store szDecimals per asset, round sizes down before signing, and refresh the metadata on a schedule. Add a unit test with an asset that has few decimals and one with many, so a regression shows up before it costs a failed order in a fast market. The API guide on this site lists the request shapes. Keep a short log of rejected orders with the asset, size, and price so a pattern is easy to spot.
Sources
2 references · ExpandCollapse
- Hyperliquid Docs: Tick and lot sizeAccessed 2026-08-25Supports: Asset size precision, szDecimals metadata, and the requirement to round order sizes to the supported decimal precision.
- Hyperliquid Docs: Perpetuals info endpointAccessed 2026-09-04Supports: Core and HIP-3 perpetual DEX discovery, current market contexts including rolling dayNtlVlm, perpetual metadata, funding history, predicted funding, DEX and market limits, DEX status, configuration metadata, clearinghouse state, and open-interest cap fields.