Order Book Liquidity & Heatmaps

Three different views of market activity

A useful order-flow workflow separates three kinds of information. Executed trades describe what has already happened. The live order book describes visible resting liquidity now. A heatmap or order-book history adds the missing time dimension by showing how that liquidity appeared, persisted, moved or disappeared.

A large order is an observation, not a signal

Seeing an unusually large sell order above price can be interesting, but the bot should not immediately translate it into SELL. Displayed liquidity can be cancelled, moved, partially executed or replenished. It may influence price—or have little lasting effect.

Normalize size before calling an order “large”

A fixed threshold is rarely enough. A 500,000-unit order can be exceptional in one market and ordinary in another. The system should compare displayed size with local depth and recent order-book behavior.

Possible features include order size divided by median depth at nearby levels, percentile rank versus recent visible orders, distance from mid-price, concentration across adjacent price levels and the ratio between bid-side and ask-side depth.

RELATIVE WALL SIZE = DISPLAYED SIZE ÷ NORMAL DEPTH AT COMPARABLE LEVELS

Persistence adds information that a snapshot cannot

A single order-book snapshot answers only: “What is displayed now?” A heatmap can answer a more useful question: “How has this liquidity behaved over time?”

A bot can record when a large order first appeared, how long it remained visible, whether its size changed, whether it moved as price approached and whether it survived repeated interactions with the market.

A pulled wall is not automatically spoofing

Large orders can disappear for many reasons. Cancellation alone does not establish the trader's intent, so an automated system should not label every disappearing wall as spoofing.

Instead, the bot can describe observable behavior: the order appeared, persisted for a measured period, moved, was reduced or was cancelled as price approached. Repeated patterns can become research features without claiming knowledge of the participant's motive.

Liquidity becomes more useful when price approaches it

A large resting order far from the current market may never matter. As price approaches the level, the system can increase observation resolution and evaluate what actually happens.

DETECTED WALL → PRICE APPROACH → WALL HOLDS / MOVES / PULLS → TRADES EXECUTE → PRICE REACTS / BREAKS

The distinction between displayed liquidity and executed liquidity is important. A visible wall that disappears before contact provides different information from a level where aggressive market orders repeatedly trade into resting liquidity without moving price through it.

From liquidity zone to support or resistance hypothesis

Order-flow data can identify a candidate zone, but support or resistance should be treated as a hypothesis to validate. The bot can combine visible liquidity with previous traded volume, market structure and the reaction after contact.

A stronger candidate might contain several independent observations: unusual resting depth, persistence over time, prior executed volume, structural relevance and a measurable rejection after price reaches the area.

What does absorption look like to an algorithm?

Absorption is often described visually, but automation requires explicit measurements. One possible research model looks for substantial aggressive traded volume at a level while price makes limited progress through it.

The system can track executed volume, price displacement, replenishment of resting liquidity and subsequent movement. No single threshold proves absorption; the objective is to convert the concept into reproducible features that can be tested.

Order-book imbalance needs context

A large imbalance between visible bids and asks can change quickly. It can also be affected by how much depth the data feed exposes. For that reason, imbalance is generally more useful as one contextual feature than as a standalone directional prediction.

Build a liquidity-event state machine

A production bot can represent each candidate liquidity area through explicit states:

DETECTED → VALIDATED → APPROACHING → INTERACTING → HELD / BROKEN / PULLED → EXPIRED

• DETECTED: relative size exceeds the research threshold.
• VALIDATED: persistence and data-quality conditions are satisfied.
• APPROACHING: price enters a defined observation distance.
• INTERACTING: executions occur at or near the liquidity area.
• HELD: the market reacts without accepting price through the level.
• BROKEN: liquidity is consumed and price establishes acceptance beyond it.
• PULLED: the displayed order disappears before the expected interaction.
• EXPIRED: the observation is too old or no longer structurally relevant.

Do not let the order-flow layer place trades directly

The liquidity detector should produce structured evidence or a trade intent—not send an order by itself. Market regime, strategy rules and risk controls still need to approve exposure.

ORDER FLOW → SETUP → TRADE INTENT → RISK ENGINE → PORTFOLIO GATE → APPROVED ORDER

This separation makes the system easier to test and prevents one unusual order-book event from bypassing account-level protection.

Testing one strategy across 100 trades

A fixed-rule series of 100 trades is a useful validation idea because it discourages changing the strategy after every win or loss. But the number 100 is not a guarantee of statistical significance, and win rate alone is not enough to evaluate the result.

For example, an early sample of 12 winners and 2 losers may look impressive, but it is still only 14 observations. The eventual evaluation should include the size of winners and losers, costs, drawdown and the consistency of execution.

Metrics that matter more than win rate

EXPECTANCY = (WIN RATE × AVG WIN) − (LOSS RATE × AVG LOSS) − COSTS

Data limitations matter

Order-book analysis is only as complete as the available feed. Crypto liquidity is fragmented across venues, displayed orders can change rapidly, and the visible book does not represent every participant's intentions or every source of liquidity.

A bot should therefore log exchange, instrument, depth coverage, timestamps and data gaps. Results from one venue should not automatically be interpreted as a complete map of the entire crypto market.

What should a production liquidity detector log?

• exchange, symbol and timestamp;
• bid/ask side and price level;
• absolute and normalized order size;
• distance from mid-price;
• first-seen and last-seen time;
• size changes and price movements;
• pull, execution and replenishment behavior;
• executed volume near the level;
• price reaction after interaction;
• market-regime and structural context;
• trade-intent decision and risk-gate result;
• data-quality warnings.

From visual heatmap to testable trading logic

The goal is not to teach a bot to stare at bright bands on a heatmap. The goal is to translate visible liquidity behavior into measurable features with explicit state transitions.

Large orders become more informative when the system knows how unusual they are, how long they persist, what happens as price approaches, whether they execute or disappear, and how price behaves afterward. That turns discretionary observation into data that can be validated.

Educational and software-engineering information only. Order-book and order-flow features are analytical models, not guarantees of price behavior or profitability. Automated trading involves financial risk.