# Canonical: https://www.uddalak.xyz/hyperliquid-academy/article/97-tick-size-lot-size-and-szdecimals
# Author: Uddalak Das
# Last source: https://www.uddalak.xyz/hyperliquid-academy/article/97-tick-size-lot-size-and-szdecimals

---
title: "Tick Size, Lot Size, and szDecimals on Hyperliquid"
description: "Hyperliquid order validity depends on price precision and size precision; `szDecimals` determines quantity granularity while price rules constrain significant figures and decimal places."
pillar: "Markets & Trading"
track: "Markets & Trading"
cluster: "Markets & Trading"
level: "Advanced"
primary_icp: ["builder", "trader"]
secondary_icp: ["market maker"]
content_type: "reference"
reading_time: "3 min"
last_reviewed: "2026-09-07"
last_verified: "2026-09-07"
volatile: true
prerequisites: ["96-hyperliquid-perpetual-contract-specifications"]
related: ["98-price-time-priority-on-hypercore", "104-how-to-read-hyperliquid-l2-order-book"]
---

# Tick Size, Lot Size, and szDecimals on Hyperliquid

Precision errors are one of the easiest ways to build a Hyperliquid client that works for one market and fails on another. Size precision comes from an asset's `szDecimals`. Price precision follows Hyperliquid's significant-figure and decimal-place rules. The safe approach is to convert values into deterministic decimal representations before signing rather than rely on floating-point formatting.

## Size precision

If an asset has a given `szDecimals`, order size must be representable at that granularity. A client should round or reject deliberately, not let a language's floating-point serializer decide.

The base asset's precision can differ between spot and perps.

## Price precision

Current documentation limits prices to a maximum number of significant figures and a decimal-place constraint derived from market type and `szDecimals`. Integer prices are a special practical case because they do not need unnecessary decimal formatting.

Always use the live documented formula because protocol precision rules can evolve.

## Why floats are dangerous

Binary floating-point numbers cannot represent many decimal fractions exactly. A value intended as `0.1` can have an internal representation with extra digits. If those digits leak into serialization or signing, the exchange can reject the order or the signature can differ from another implementation.

Use decimal arithmetic or integer-scaled representations in the order layer.

## Tick size is an economic parameter too

Coarser price increments change queue competition, spread granularity, and how a market maker can quote. Size increments change minimum inventory adjustments.

Precision is therefore not merely an API annoyance. It shapes microstructure at small scales.

## Testing

Build a table-driven test suite across assets with different `szDecimals`, tiny and large prices, boundary significant figures, and spot/perp identifiers. Compare generated orders against official SDK behavior.

## How this connects

Start with [Hyperliquid Perpetual Contract Specifications](/hyperliquid-academy/article/96-hyperliquid-perpetual-contract-specifications) if the underlying concept is unfamiliar. Related reading: [Price-Time Priority on HyperCore](/hyperliquid-academy/article/98-price-time-priority-on-hypercore), [How to Read Hyperliquid's L2 Order Book](/hyperliquid-academy/article/104-how-to-read-hyperliquid-l2-order-book).

## Sources

- https://hyperliquid.gitbook.io/hyperliquid-docs/trading/tick-and-lot-size
- https://hyperliquid.gitbook.io/hyperliquid-docs/trading/contract-specifications