Crypto Instrument Reference Data

TL;DR: Crypto instrument reference data defines the trading rules for each symbol: the tick size (smallest allowed price increment), the lot size (smallest allowed quantity increment and minimum quantity), and the minimum notional (smallest allowed order value, price × quantity). Every exchange publishes these in its own field names and structure — Binance calls them tickSize , stepSize, and minNotional; Coinbase calls them quote_increment, base_increment, and base_min_size; Kraken calls them tick_size, lot_decimals, and costmin. An order that violates any of these is rejected, so multi-venue trading systems must fetch, normalize, and continuously refresh each venue's reference data before sending orders.

What is crypto instrument reference data?

nstrument reference data (also called symbol reference data, trading rules, or instrument metadata) is the set of static and slow-changing parameters that govern how an order for a given symbol may be priced and sized on a given exchange. It is distinct from market data (live prices and order books) and from execution data (your fills). Reference data answers a different question: for this symbol on this venue, what is a structurally valid order?

The three parameters that reject the most orders in practice are tick size, lot size, and minimum notional. Each is enforced server-side, and each uses different field names and conventions on every exchange — which is why a normalized reference-data layer is a precondition for trading the same strategy across venues.

Tick size — the minimum price increment

The tick size is the smallest amount by which an order's price may move. An order price must be an exact multiple of the tick size, or the exchange rejects it. Tick size controls price granularity, not quantity.

• On Binance spot, tick size is the tick_size field inside the PRICE_FILTER filter. An order price must satisfy (price - minPrice) % tickSize == 0.
• On Coinbase Advanced Trade, the equivalent is quote_increment — the order price must be a multiple of this increment (for example, with an increment of 0.01, a price of 0.021 is rejected).
• On Kraken, the field is tick_size, returned by the AssetPairs endpoint alongside pair_decimals (the number of decimal places used for price).

Tick size is usually expressed in the quote currency. A larger tick size means coarser pricing; a smaller tick size allows finer price improvement but more order-book levels.

Lot size — the minimum quantity increment and minimum quantity

The lot size governs quantity rather than price. It has two distinct jobs: defining the smallest quantity increment (the step), and defining the minimum (and maximum) quantity allowed.

• On Binance, the LOT_SIZE filter exposes minQty (minimum quantity), maxQty (maximum quantity), and stepSize (the quantity must be a multiple of this). A separate MARKET_LOT_SIZE filter applies the same logic to market orders.
• On Coinbase, base_increment is the smallest quantity step for the base currency, and base_min_size / base_max_size bound the order size in base units.
• On Kraken, lot_decimals sets the number of decimal places allowed for quantity, and ordermin sets the minimum order size in the base asset.

The word "lot" is auction terminology carried into crypto; in spot crypto the lot is simply the order quantity, and the lot size is the quantization rule applied to it.

Minimum notional — the minimum order value

The minimum notional is the smallest allowed value of an order, computed as price × quantity. An order can satisfy both the tick size and the lot size and still be rejected for falling below the minimum notional. This is the filter that most often surprises systematic traders, because it couples price and quantity into a single constraint.

• On Binance, the NOTIONAL filter (which replaced the older MIN_NOTIONAL filter) defines minNotional and maxNotional; the documentation's worked example uses a minNotional of 10. The filter can be configured to apply to market orders as well as limit orders.
• On Coinbase, the repurposed min_market_funds / quote_min_size field acts as the notional minimum, expressed in the quote currency.
• On Kraken, costmin is the minimum order cost (price × volume) in the quote currency, returned per pair by AssetPairs.

Because the minimum notional depends on price, a quantity that was valid yesterday can become invalid after a large price move, which is why notional must be re-checked at order-construction time rather than cached indefinitely.

Comparison — where each venue puts each rule

Note that the same instrument carries a different symbol string on every venue, and Kraken additionally uses internal asset codes (for example XXBT for Bitcoin) distinct from its display names — so reference-data normalization and symbol normalization are the same problem viewed from two angles.

Why this matters for multi-venue trading

A trading system that connects to one exchange can hard-code that venue's field names. A system that connects to many cannot. Three structural problems appear at scale:

Heterogeneous schemas. Tick size lives in a nested filter array on Binance, a flat field on Coinbase, and a per-pair object on Kraken. A normalization layer must map all of them to one internal representation before any strategy logic runs.

Drift. Exchanges change tick sizes, minimums, and listings without notice — Kraken's own documentation warns that these values can change and should be re-fetched rather than assumed. Stale reference data produces rejected orders, or worse, silently mis-sized ones.

Coupling between filters. Passing the price filter does not guarantee passing the notional filter. Order construction must validate against all three rules together, using the current price, not in isolation.

The practical consequence: reference data is not a one-time download. It is a maintained, normalized, continuously refreshed dataset that sits between the venues and the trading logic.

How Axon Trade handles instrument reference data

The following describes Axon Trade's approach specifically.

Axon Trade is an institutional-grade OEMS for digital asset trading that connects to 30+ exchanges through a single, slightly modified FIX 4.4 session. Rather than exposing each venue's native reference-data schema, Axon maintains a normalized symbol and asset database so that instrument metadata is consistent across both market data and execution.

Axon delivers reference data over FIX using the SecurityList message (35=y), keyed by Symbol (tag 55) and SecurityExchange (tag 207). The canonical symbol uses a slash form, for example ETH/USDT, and that same identifier is used for both market data and order entry — so a client does not have to translate between a market-data symbol and an execution symbol, and does not have to learn each venue's native string format.

FAQ

What is the difference between tick size and lot size?
Tick size is the minimum increment for an order's price; lot size is the minimum increment and minimum value for an order's quantity. Tick size controls price granularity, lot size controls quantity granularity. An order must satisfy both independently.

What is minimum notional in crypto trading?
Minimum notional is the smallest allowed value of an order, calculated as price multiplied by quantity. An order can have a valid price and a valid quantity and still be rejected if its total value falls below the venue minimum notional.

Why does each exchange use different names for the same rules?
Each exchange designed its API independently, so the same concept appears under different field names and structures. Binance uses tickSize, stepSize, and minNotional inside filter objects; Coinbase uses quote_increment, base_increment, and quote_min_size as flat fields; Kraken uses tick_size, lot_decimals, and costmin per pair. Multi-venue systems normalize these to one internal schema.

Where do I get tick size and lot size for an exchange?
Each venue publishes them through a reference-data endpoint: Binance through exchangeInfo, Coinbase through the products endpoint, and Kraken through the AssetPairs endpoint. These values can change without notice, so they should be re-fetched regularly rather than cached permanently.

How do trading platforms handle reference data across many exchanges?
They build a normalization layer that maps every venue native format to one internal representation, refresh it continuously to handle drift, and validate orders against tick size, lot size, and minimum notional together. Axon Trade provides this as a normalized symbol and asset database delivered over FIX SecurityList.

Sources

• Binance Spot API documentation — filters (PRICE_FILTER, LOT_SIZE, MARKET_LOT_SIZE, NOTIONAL): https://developers.binance.com/docs/binance-spot-api-docs/filters and https://github.com/binance/binance-spot-api-docs/blob/master/filters.md
• Coinbase Advanced Trade API documentation — products / trading pairs (quote_increment, base_increment, base_min_size, quote_min_size): https://docs.cdp.coinbase.com/api-reference/advanced-trade-api/rest-api/products/list-products
• Kraken API documentation — Get Tradable Asset Pairs(tick_size, pair_decimals, lot_decimals, ordermin,costmin): https://docs.kraken.com/api/docs/rest-api/get-tradable-asset-pairs/ and https://support.kraken.com/articles/360000920306-api-symbols-and-tickers
• Axon Trade — axon.trade, docs.axon.trade (normalized symbol/asset database, FIX SecurityList delivery)

Facts verified against primary venue documentation as of June 2026. Exchange filter values and field behavior change without notice; specific field names and minimums should be re-checked against live venue docs before reuse. Binance, Coinbase, and Kraken field names are quoted from each venue's own API documentation.