Order-book price grouping combines nearby price levels into wider display buckets; exchange tick size defines the permitted price increment for an instrument. Changing the grouping does not change the underlying order prices or the venue's price grid. Sum each level's quantity once, keep bids and asks separate, and read the bucket-label rule before treating a grouped row as an exact price or executable quantity.
A large row at 100.10 might contain offers at 100.06, 100.09 and 100.10. That can make the book easier to scan, but it removes information needed to answer a narrower question: how much was offered at or below 100.08? The distinction becomes visible when the same frozen book is rendered twice.
Three different meanings of a price increment
A venue's tick size belongs to its order rules. A display grouping interval belongs to the representation of market data. The number of decimal places shown belongs to formatting. They can have different values for the same instrument.
For example, Binance Spot's documented PRICE_FILTER checks enabled price bounds and requires a price to fall on its tickSize grid. Quantity and notional filters are separate checks. This describes Binance Spot's API rules, rather than every venue or product. Binance Spot filter documentation.
In a hypothetical instrument with a 0.01 tick, 100.08 lies on the price grid and 100.085 does not. Choosing a 0.10 display interval would not invalidate 100.08 or make 100.085 valid. Passing the grid check would still leave other applicable order rules to validate.
There is also more than one kind of aggregation. Combining several orders at exactly the same price produces a price-level record. Combining several different prices produces a wider bucket. Bitfinex's v2 REST Book endpoint illustrates the distinction: its aggregated trading records contain a price, order count and total amount, while its raw trading records include an order ID. Its precision parameter controls price aggregation. Bitfinex v2 Book reference.
Here, “native level” means a source price-level observation before our additional grouping. It does not mean that each row is one order. A row with two base units could represent one order or several; quantity alone cannot reveal the identities behind it. Check the source's own aggregation setting too: removing local grouping cannot restore prices the source has already combined. The fixture below assumes its input prices retain the native tick-level resolution.
Group one frozen book and keep every unit
The following fictional spot book uses prices in quote units per base unit and sizes in base units. Its assumed native tick is 0.01. All observations belong to one snapshot and the sizes are per-level amounts, not cumulative totals. This is an arithmetic fixture, not current market data.
Choose a display width of 0.10 with boundaries aligned to multiples of 0.10. For this example only, round bid labels down and ask labels up. Other displays may use different boundaries or labels; verify their definitions before applying this worksheet.
A bid label of 100.00 covers prices from 100.00 inclusive to 100.10 exclusive. An ask label of 100.10 covers prices above 100.00 through 100.10 inclusive. Keeping those boundary rules explicit prevents a level exactly on a boundary from appearing twice.
| Side | Native price | Size | Bucket label |
|---|---|---|---|
| Bid | 100.04 | 1.20 | 100.00 |
| Bid | 100.00 | 0.80 | 100.00 |
| Bid | 99.98 | 1.50 | 99.90 |
| Bid | 99.91 | 0.50 | 99.90 |
| Bid | 99.90 | 0.70 | 99.90 |
| Ask | 100.06 | 0.60 | 100.10 |
| Ask | 100.09 | 1.40 | 100.10 |
| Ask | 100.10 | 1.00 | 100.10 |
| Ask | 100.13 | 2.00 | 100.20 |
| Ask | 100.20 | 0.50 | 100.20 |
Each input row has exactly one destination on its own side. Add sizes within those destinations:
| Side | Display label | Size in bucket | Cumulative size |
|---|---|---|---|
| Bid | 100.00 | 2.00 | 2.00 |
| Bid | 99.90 | 2.70 | 4.70 |
| Ask | 100.10 | 3.00 | 3.00 |
| Ask | 100.20 | 2.50 | 5.50 |
The first bid bucket is 1.20 plus 0.80, or 2.00. The second is 1.50 plus 0.50 plus 0.70, or 2.70. Both representations contain 4.70 bid units. The ask side similarly preserves 5.50 units across its two buckets. Each side's cumulative column starts at its best displayed label and moves outward.
Changing grouping should preserve quantity over the same source rows. Ten price-level records have become four display records. Neither number is an order count, and fewer displayed rows do not establish that anything was canceled.
What the wider rows stop telling you
The native best bid is 100.04 and best ask is 100.06, giving a spread of 0.02. The closest grouped labels are 100.00 and 100.10, giving a label gap of 0.10. Reporting the latter as the actual spread would introduce a display artifact into a market measurement.
Calculate the spread from the native best prices before grouping. The same separation matters when investigating an apparent lock or cross: preserve side, source and observation timing before interpreting two labels. The locked versus crossed order-book guide develops that diagnostic.
Our outward labels have a useful limited meaning. All asks assigned to 100.10 have prices no higher than that boundary. They do not all have that exact price. Likewise, the bids assigned to 100.00 have prices at least that high. These are statements about the frozen observations, not guarantees that the quantities will remain available.
Now ask how much of the fictional book is offered at or below 100.08. The native table answers 0.60 units. The 3.00-unit ask bucket cannot answer it: part of its quantity falls above the cap, and grouping discarded the split. Counting all 3.00 would overstate the amount; excluding the entire bucket would overlook the 0.60.
Multiplying each bucket label by its size also changes the quote-value calculation. At their original prices, the first ask bucket contributes 300.262 quote units and the second contributes 250.360, totaling 550.622. Multiplying their labels by their sizes instead gives 300.300 plus 250.500, or 550.800: an overstatement of 0.178. Our ask-rounding policy makes the label product an upper bound for this fixture's displayed amounts, but it is not their exact notional.
Retain the original sum of price times quantity if the display needs an exact notional for its included observations. An average within a bucket may summarize those observations, but it still cannot reveal how quantity is distributed around an arbitrary price cap. Use native levels for the order-book depth and slippage worksheet; grouped bars alone do not supply the missing prices.
Two ways to manufacture extra depth accidentally
First, do not add cumulative rows as though they were independent sizes. In the grouped ask table, the cumulative values are 3.00 and 5.50. Their sum is 8.50, which counts the first bucket twice. The per-bucket quantities sum to 5.50, matching the source book. Record whether a feed or interface supplies incremental size, cumulative size, or both.
Second, do not mix a retained old bucket with a newly rebuilt version. Suppose the fictional bid quantity at 100.00 changes from 0.80 to 1.10, while the 1.20 at 100.04 remains unchanged. If the source operation replaces that level's quantity, the rebuilt 100.00 bucket becomes 2.30 and the bid total becomes 5.00. Appending 1.10 to the previous bucket would retain the obsolete 0.80. The feed's own update contract determines how to change the underlying book; the grouped view should then follow that corrected state.
Grouping and data coverage are also separate. Bitfinex's Book reference gives precision and the requested number of price points distinct parameters. A row count therefore needs its aggregation setting to be meaningful. Bitfinex Book request parameters.
When comparing views, preserve the source's depth limit and the furthest included price on each side. A wider view built from five native levels still contains only those five levels. It cannot fill in unseen prices. The order-book depth truncation guide explains how to label that coverage boundary instead of treating the final visible row as the end of the market.
A worksheet for checking a grouping control
Freeze one valid source snapshot before comparing settings. Otherwise, ordinary arrivals and cancellations can masquerade as changes caused by the control. Record the venue, instrument, market type, quantity unit, snapshot identity or time, native tick rule, source depth limit and aggregation setting, display width, boundary origin and label convention.
Then work through these checks on that same snapshot:
| Check | Evidence to retain | Pass condition |
|---|---|---|
| Quantity conservation | Side totals before and after | Every included amount counted once |
| Boundary ownership | A level exactly at an interval edge | One bucket under the declared rule |
| Best-price preservation | Native best bid and ask | Spread uses native prices |
| Row meaning | Per-bucket and cumulative values | Cumulative amounts are not resummed |
| Partial-bucket cap | A limit inside one interval | Native prices supply the answer |
| Independent price grid | Current instrument rules | Display width does not validate orders |
Use exact decimal values or an appropriate scaled representation for boundary calculations. A tiny representation error near 100.10 could place an observation in an adjacent bucket. The API decimal precision guide covers that separate numerical problem; fewer printed digits do not repair it.
Finally, change only the grouping setting and compare the recorded totals and coverage again. Keep a price selected for an order explicit, even if the interface fills it from a grouped row. Validate that candidate against the current instrument rules and the intended price cap. A useful grouped book keeps the quantity ledger intact while making its lost detail visible: wider rows are a viewing choice, and the original prices remain the evidence for a price-specific decision.