Precision and rounding

3 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

How do I read tickSize, stepSize and minNotional from exchangeInfo?

Per symbol, `GET /api/v3/exchangeInfo` (spot) or `/fapi/v1/exchangeInfo` (futures) returns `filters`: `PRICE_FILTER.tickSize` (price must be a multiple), `LOT_SIZE.stepSize` (quantity multiple, min/max), `MIN_NOTIONAL`/`NOTIONAL` (min order value, often ~5-10 USDT), `MARKET_LOT_SIZE` (separate quantity bounds for MARKET orders), and futures adds `PERCENT_PRICE` (price band around mark). Values are strings like `0.00100000` — keep them as decimals/strings, never floats. Cache the response, refresh daily AND on errors like -1013, because exchanges change filters when prices move (a token that 10x'd gets a new tickSize). Bybit equivalent: `GET /v5/market/instruments-info` with `priceFilter`/`lotSizeFilter`; OKX: `/api/v5/public/instruments` with `tickSz`/`lotSz`/`minSz`.

Why does Math.round lose me money on order sizing?

Binary floating point: `0.1 + 0.2 = 0.30000000000000004`. Rounding such values to a step size can yield `0.30000001`, which fails `LOT_SIZE` server-side (-1013 'Filter failure'), or silently oversizes a position beyond your balance. Exchanges send all numeric fields as strings for a reason. Use a decimal library (decimal.js, big.js) end to end, or convert to integer ticks: `ticks = floor(qty / step)` then `qty = ticks * step` computed in decimal space. Do all comparisons (notional >= min, qty <= max) in decimals too. Never `parseFloat` an exchange number, do math, and `toFixed` the result — `toFixed` rounds half-to-even-ish on a binary approximation and will betray you at filter boundaries.

Which way do I round price and quantity to be safe?

Quantity: round DOWN to `stepSize`. Rounding up can exceed your free balance (-2010 insufficient balance) or, worse, make a reduceOnly order larger than the position. Price: round so the order is never MORE aggressive than intended — buys round down to `tickSize`, sells round up. Check `minNotional` AFTER rounding: if `qty * price` lands just below the minimum, bump quantity UP one step (never lower the price to compensate). On truncation vs rounding: Binance historically truncates to filter precision, but behavior can vary by filter and endpoint — do not rely on the exchange to fix your numbers; normalize client-side and prove it with a minimum-size test order. A value that passes your local float check (`0.29999999`) can still fail the server-side decimal check.

Give your agent this brain