Read the quantity available at each price before estimating an average. The last trade tells you where one transaction happened; it does not quote a guaranteed price for every unit you are about to request. A depth estimate should show both the portion it can explain and the portion for which it lacks data.
Check what the columns actually measure
A market buy uses available asks, while a market sell uses bids. Start with that direction, the complete pair and the quantity unit. A column labelled Total may already be cumulative. Summing those totals again counts the earlier levels more than once and makes the book appear deeper than the displayed evidence supports.
Some interfaces group several fine price levels into one row. That can be useful for viewing the overall shape, but a grouped row is not proof that all its quantity is offered at a single exact price. Also distinguish base-asset quantity from quote-asset value. Three units of an asset are not the same instruction as spending three units of the quote currency.
Try three fixed ask prices: 100, 101 and 103
Our example contains one unit offered at 100, 1.5 units at 101 and two units at 103. The quote unit is USDT solely for the arithmetic. These are invented teaching numbers, with no live feed, actual account or claim about the present depth of any market.
| Ask | Quantity at this level | Cumulative quantity |
|---|---|---|
| 100 | 1 | 1 |
| 101 | 1.5 | 2.5 |
| 103 | 2 | 4.5 |
Freeze all three rows while calculating. We omit other buyers, withdrawals of offers, fees, filters and exchange protections. In an actual book those omissions would matter; here they allow us to examine just how order size uses the displayed levels.
One, two and three units produce different results
A one-unit buy uses the first level and costs 100 before fees. A two-unit buy uses the first unit at 100 and another at 101, costing 201. At three units, it uses one at 100, 1.5 at 101 and only half a unit at 103.
That final calculation is 100 + 151.5 + 51.5 = 303. The average is 303 divided by three, or 101. Averaging the three displayed prices directly would be wrong: their actual contributions differ. Including the entire two-unit third row would also be wrong because the target needs only half of it.
Write down three separate observations: the initial ask is 100, the last level used is 103 and the resulting weighted average is 101. None needs to equal the others. Their difference is explained by the distribution of the requested quantity across the fixed book.
Five units need more offers than these three rows show
The displayed book offers only 4.5 units. Their total value is 100 + 151.5 + 206 = 457.5. A request for five leaves half a unit without a displayed offer. The honest output is “4.5 units covered; 0.5 not priced,” rather than extending the last ask to quantity that was never shown.
To price the missing half unit, you need the next available asks and their quantities. These three rows cannot give the cost of the full five-unit purchase. The depth exercise shows the uncovered amount separately; it does not assume the last displayed price applies further down the book.
When comparing estimates, keep the same target quantity and units. Comparing an average for one unit with an average for five can exaggerate an apparent change in market conditions when the main difference is simply the amount requested.
The estimate has a timestamp, not a reservation
Between reading a book and an order being processed, offers can be consumed, cancelled or replaced. An estimate calculated from a screenshot describes that screenshot under your assumptions. It does not reserve the listed quantity for your later instruction.
Different panels may refresh at different moments too. The chart, last price and depth do not necessarily represent a perfectly synchronized snapshot on your screen. Save the observation time when investigating a discrepancy, but avoid claiming that an ordinary screenshot reconstructs every event at the matching engine.
Binance Academy’s market-order explanation describes execution against existing liquidity and the possibility of several prices. The calculations here are original examples of that mechanism, not promised execution quotes.
A limit changes what you accept
With the same frozen asks, a buy limited to 100.5 can use only the first unit. It excludes the 101 and 103 levels, even though they are visible. This preserves a price boundary while leaving part of the target unexecuted in the example.
Changing an order type is therefore a decision about conditions, not a guarantee of a better result. For the other side of this comparison, see why a limit can leave quantity waiting. Do not widen a boundary just to make a teaching tool display a complete fill.
Which price are you comparing the result with?
If you describe a difference as slippage, name the reference used for the comparison. The first ask, the last trade observed before submission and a personal budget are different benchmarks. A percentage without its reference price and observation time is difficult to reproduce. In the teaching example, comparing the calculated total with a hypothetical purchase of every unit at the first ask isolates the effect of using additional levels. It does not establish a normal slippage rate for an asset. Keep that distinction when reviewing a real order, where both the book and the reference may have changed while the request was travelling.
After execution, calculate from the actual fills
Once a real order has a result, use its actual executed quantity and trade amounts. One order may have several fills; group the correct records by order ID rather than treating the latest row as the whole transaction. Divide actual value by actual quantity when checking an execution average.
Our example excludes fees. If wallet changes do not equal a simple price-times-quantity calculation, inspect the separate fee and balance fields instead of adjusting the average until the numbers happen to match. Other orders can affect balances at the same time.
A useful worksheet has a planned quantity, observed depth, estimated value and confirmed execution. The first three belong to the information available before submission; the last belongs to the outcome. Keeping them separate shows whether a difference came from changed prices, changed quantity or an estimate that never covered the whole request.