Cumulative depth

How it is computed

Take one side of the book, start at the best price, and add the resting size level by level outward. The DOM guide on this site uses a hypothetical bid side of five levels: 40, 65, 110, 30 and 55 contracts, which sum to 300. The same sum on the ask side over its five best levels gives the comparison. The result is a pair of totals, or a ratio between them, that updates on every book change.

• The number of levels must be the same on both sides for the comparison to mean anything.
• The totals are bounded by the feed's published depth; a ten-level feed cannot give a fifteen-level sum.
• Size is in the feed's unit: contracts on futures, base-asset quantity or notional on crypto.

Why sum rather than read one level

A single large level can be an outlier, an order about to be pulled, or several unrelated orders that happen to coincide. Summing a handful of levels dilutes any one order's influence, so the total changes more slowly and reflects the side's resting size as a whole. In the guide's example, the cumulative read comes out at roughly 1.4 to 1 in favour of the bid side, more resting size waiting to buy than to sell across those levels, while the top level alone could have said the opposite. That is the reason the guide pairs top-of-book urgency with cumulative depth for weight.

What the totals do and do not say

• A heavier bid total means more displayed size below the market, which is where sellers would have to trade to push price down; it does not mean price will not go down.
• The imbalance can flip in seconds when size is pulled, so the trend of the totals over a minute is more informative than one reading.
• Displayed totals exclude hidden iceberg reserves and everything beyond the feed's depth.
• The DOM guide's workflow: watch a cumulative depth imbalance build on one side, then confirm every big level against the footprint before treating it as weight.

In Senzoukria

The heatmap settings include a Cumulative depth toggle in the DOM ladder section, drawn alongside the ladder's bid and ask sizes, with Levels / side controlling how many levels are shown. The ladder header reports Depth received, so the number of levels actually available for the sum is visible rather than assumed. The application's Microstructure indicator computes queue imbalance from size at the best bid and best ask only, which is the single-level version of the same idea; cumulative depth extends it across the published window. The heatmap's side colouring note applies here too: when the book is crossed or empty, levels are drawn neutral rather than assigned to a side by guesswork.

Common mistakes

• Comparing a five-level bid sum with a ten-level ask sum.
• Reading the ratio as a prediction rather than a description of displayed size.
• Ignoring the feed's depth: a truncated book can make one side look thin simply because its size sits outside the window.
• Summing across a crossed or stale book; a dead feed reads as a quiet, balanced market.