Liquidity tracker
A liquidity tracker is a panel that records, for each price level, what displayed liquidity did: how much was withdrawn without trading and how much was executed. It needs order-by-order (MBO) data, because an aggregated book only shows totals changing, not whether an order was cancelled or filled.
Senzoukria · Glossary · Updated September 2026
Withdrawn versus executed
When the displayed size at a price falls, an aggregated book cannot say why. The size may have traded, been cancelled, or been replaced a tick away. Order-level data attaches an identifier to each order and reports its add, modify, execute and delete events, so the tracker can attribute the change: executed when a trade consumed it, withdrawn when it was deleted without a fill. The heatmap guide makes the point from the other side: a disappearing band alone does not establish spoofing or intent.
- Executed: the resting quantity that was hit or lifted at that price.
- Withdrawn: the resting quantity deleted before trading, including ordinary requoting by market makers.
- Neither category identifies a participant, and several orders can contribute to one level.
What the numbers can support
- A level where executed volume is renewed by fresh adds is consistent with replenishment; it is not proof of a native iceberg.
- A level where most displayed size was withdrawn as price approached is a fact about that level, not a verdict on the participant.
- Lost order events make the picture partial; the tracker should say how many were dropped rather than smoothing over them.
In Senzoukria
The heatmap settings include a Liquidity tracker toggle in the Liquidity section, with the hint: for each price level, what the liquidity did, withdrawn without trading or executed; needs the order-by-order feed. The panel shows bid and ask columns per level. Its empty state reads No order book activity yet and explains that it needs the MBO feed because it reads each order's life, not just the visible totals.
A note under the panel states that Withdrawn includes normal market-maker requoting, cancelling to repost a tick away; the panel distinguishes withdrawal from execution and does not call withdrawal deceptive. When events are lost it prints the count of order events lost and labels the picture as partial. The tour lists it among the heatmap settings next to colour scale, DOM columns and executed volume. Whether MBO data is available depends on the feed and the account's entitlement; on an aggregated feed the panel stays empty rather than inferring.
Common mistakes
- Calling a high withdrawn share at a level spoofing; requoting is the ordinary case.
- Enabling the tracker on an aggregated depth feed and reading the empty panel as no activity.
- Ignoring the dropped-events line and treating a partial record as complete.
- Summing withdrawn and executed across the session as if the two were comparable units of intent.
Related
This page in other languages
Frequently asked questions
- Why does the liquidity tracker need MBO data?
- Because only order-level data reports each order's add, modify, execute and delete events. An aggregated book shows the total at a price changing, and a decrease can be a fill, a cancellation or a replacement; without the order identifier the tracker cannot attribute it, so it shows nothing instead of guessing.
- Does a large withdrawn share prove spoofing?
- No. Withdrawn includes market makers cancelling to repost one tick away, which is routine. The tracker separates withdrawal from execution as an observation about the level; attributing intent would require information the feed does not contain, and the panel's note says so explicitly.
- How does the tracker differ from the heatmap's adds and pulls tint?
- The adds and pulls tint on the heatmap is inferred from the aggregated book and is labelled as such, never presented as an MBO observation. The tracker reads actual order events and reports executed versus withdrawn quantities per level. They answer related questions from different data, with different degrees of certainty.