Whale walls

What counts as a whale wall

A whale wall is a single price level in an exchange order book whose resting quantity is at or above a configured minimum. The tracker reads the live book, keeps every bid or ask level that meets the minimum, and follows that level over time as one tracked object. Minimums are stored per trading pair and per venue rather than as one global number, and only pairs with a stored, enabled configuration are tracked at all. If a wall disappears and reappears at the same price within five minutes with a similar quantity, it is treated as the same order rather than a new one.

The life of a wall in the tracker

The stream carries five event names: wall_appeared, wall_updated, wall_cancelled, wall_filled and wall_partialfill. Appeared marks the first time a level meets the minimum; updated fires on every quantity change. A level that vanishes does not close immediately. It moves into a pending state for up to five minutes, and if the same price returns with a quantity the tracker scores at 0.70 or better as the same order, it is merged back and its gap counter increases. Only when the five minutes pass without a return does the tracker emit one closing event. On the board, cancelled and filled remove the row, while updated and partial-fill keep it and rewrite its numbers.

Closing events are treated differently from size filtering. The server drops appeared and updated events below your minimum before they leave the channel, but it always forwards cancelled and filled, because a client may still be holding that wall from an earlier snapshot and needs to remove it. The board follows the same rule: it ignores an under-threshold update, but never ignores a removal. This is why a wall can disappear from your board moments after you raise the minimum, without any new wall arriving to replace it.

How the tracker decides filled, partial fill, or cancelled

Every time a tracked level shrinks, the tracker looks for trades that executed at or around that price at about the same moment. When those trades account for most of the shrink, it is booked as filled. When they account for only part of it, only the volume they confirm is credited, and where the evidence is thin, only a discounted share of that. A shrink with no trade evidence behind it at all is booked as a cancellation. The window reaches further back than forward, because a trade usually reaches us before the depth update that reflects it.

Those amounts accumulate over the life of the wall into a filled total and a cancelled total. When the wall finally closes, the cumulative filled share decides the closing event: 90 percent or more is filled, 20 percent or more is a partial fill, and anything below that is cancelled. Two special cases override the arithmetic. A wall that vanishes in a single tick with no recorded shrinks, but where the market price had crossed through its level, is booked as filled. A wall that lived under 500 milliseconds with almost nothing filled, and where price did not cross it, is classified as spoofing.

Exchanges and markets covered

Four venues are covered: Binance Futures, Binance Spot, Coinbase and Hyperliquid. Binance Futures and Hyperliquid are grouped as futures; Binance Spot and Coinbase as spot. Order-book and trade data are read directly from each exchange’s own public WebSocket feed. Coverage is not identical across venues — the Coinbase and Hyperliquid trackers run only for an explicit list of pairs each venue supports, and some pairs are skipped on Binance Spot because they are not listed there. In the interface you choose which venues to display, and the header shows how many of the four are currently selected.

Settings you control

Two size filters drive the board. Min sets the smallest wall shown at all; Big sets the level above which a wall is marked as a big order. Both offer the same presets — 5, 10, 25, 50, 100 and 250 units of the base asset — plus a custom amount, and both can be expressed in base-asset units or in US dollars via a single currency toggle, with the dollar equivalent shown next to each preset. Defaults differ by pair, so switching symbols applies that pair’s own defaults. Preferences are kept in the browser and, when you are signed in, synced to your account.

How current the data is

The board opens with a one-off snapshot of the currently active walls, then keeps itself up to date over a server-sent event stream — one for futures, one for spot — so changes arrive as they happen rather than on a refresh timer. The size filter is applied server-side in the snapshot request. The server sends a heartbeat every 15 seconds and a keep-alive comment every 30. The client marks data as stale after 30 seconds without events, treats a missing heartbeat for 45 seconds as a dead connection, and reconnects with exponential backoff up to ten attempts. A snapshot is loaded when you connect and after a symbol or threshold change; an automatic reconnect restores the stream only and resumes from the last sequence number it saw.

How the board keeps the snapshot and the stream consistent

The stream opens before the snapshot has arrived, so events would otherwise be applied to a book that is about to be replaced. Instead they are held in a buffer of up to 10,000 events while the snapshot is fetched; if that buffer overflows, the older half is dropped and the drop is logged. Once the snapshot lands, the buffer is sorted and replayed, keeping only the events whose sequence number is higher than the snapshot's. Applied events are then written to the screen in animation-frame batches, with appeared, filled and cancelled queued ahead of the rest.

• Under load the server sheds only low-priority traffic: appeared, filled and cancelled are never dropped from a channel, while updated events can be, once the channel buffer passes 800 entries.
• When something is dropped, the server does not stay silent — it sends a data_gap event carrying the number of dropped events and the reason, either backpressure shedding or a client that fell behind.
• Changing a size threshold reopens the stream with the new filter and pulls a fresh snapshot; walls that no longer clear the threshold are removed from the local map first.
• Changing the symbol clears the wall map, the sequence number and the metrics before anything new is requested, so the two symbols never mix.

Reading the board

Walls from the same venue are grouped into price buckets, with bucket size chosen automatically from the price level. Each row shows the bucket price and its total size in dollars or base-asset units, a marker for rows that clear your big-order threshold, and a bar showing cumulative size stacked toward the best price. Hovering a row opens a detail strip with venue, side, price, value, cumulative value, distance from the current price as a percentage, quantity, and the age of the oldest wall in the bucket. Walls the market has already traded through are hidden by default, on the assumption that they are likely filled; a command-palette action toggles them back on.

What a row actually is: price buckets

A row is not one order. Before anything is drawn, every tracked wall is rounded onto a price grid and walls that land on the same step, on the same venue and the same side, are merged into one row. The step comes from the price itself: at 1,000 and above the step is 0.1, from 10 up to 1,000 it is 0.01, and below 10 it is 0.001. So a level near 100,000 is bucketed to a tenth of a dollar, while a level near 3 is bucketed to a tenth of a cent. Nothing about your size settings changes the grid.

Each bucket then carries the summed quantity, the summed dollar value, how many walls it contains, and the age of the oldest and newest of them. The big-order marker is tested against the bucket total, not against any single order, so several medium walls sitting on one step can light it up together. After bucketing, bids are sorted downward and asks upward, and a running total is accumulated from the top of each list. The bar behind a row shows that running total measured against the largest running total in the same card, which is why bars are comparable within a venue but not across venues.

Crossed walls and the price watermarks

"Crossed" is decided by two numbers the page keeps for itself: the highest and the lowest price it has seen since you selected the current symbol. An ask wall counts as crossed once the high watermark reaches or passes its price; a bid wall counts as crossed once the low watermark reaches or falls to its price. The reasoning is that the market has already traded at that level, so a wall still sitting there is more likely a leftover in the client's own state than live resting size. Hiding them is the default.

Two consequences are worth knowing. The watermarks reset whenever you change symbols, so immediately after a switch the filter has nothing to act on and nothing is hidden until prices start arriving. And the filter is applied while the board aggregates, not merely while it renders, so a hidden wall also disappears from the venue totals and from the maximum that scales the bars. Turning the filter off through the command palette brings those walls, and their contribution to the totals, straight back.

The four layouts

The layout menu offers four presets. All four read the same wall data and the same thresholds; they differ in how the rows are arranged and, in one case, in what is drawn at all.

• Default: one card per selected venue, laid out side by side and scrolled horizontally, with bids in the left column and asks in the right. Cards can be dragged to reorder the venues, and their width can be fixed in pixels, set as a share of the container, or auto-fitted. An extra aggregate card can be appended at the end.
• Compact: one card per venue as well, but each card is a vertical ladder — asks on top, the venue's current price in the middle, bids below.
• Aggregate: two panels side by side, both showing all selected venues merged into one list with a colored venue badge on every row. The left panel is the vertical ladder, the right panel is the two-column bid and ask view.
• Chart: replaces the board entirely with a candlestick chart for a single venue — Binance Futures, Binance Spot or Coinbase. Timeframes run from one minute to one week, with five minutes as the default. Wall levels are drawn over the candles as horizontal bands labeled with their value and an "age · count" note, at most 64 levels at a time, and a depth panel sits beside the chart.

The spoof score exists in the API, not on the board

The interface has no spoofing indicator. The row detail strip shows venue, side, price, value, cumulative value, distance, quantity, age and the big-order badge; the idle bar shows connection state, events per second, freshness, wall count, bid and ask totals, imbalance and a health badge. Neither carries a spoof score, and there is no filter or sort based on one. The score lives only in the API, on two endpoints — one for futures, one for spot — under the whale-walls path.

A request takes an optional symbol and venue filter plus a lookback in hours, which defaults to 24 and is capped at 168. The response is one entry per symbol and venue, each with a composite score from 0 to 100, a reading of low, moderate or high at the 40 and 70 marks, the number of walls analyzed, and the four factors behind the score: the share of walls that lived under 60 seconds, the average number of disappear-and-return gaps per wall, the share of cancelled walls above a fixed dollar value, and the average number of quantity changes. Only closed walls count, a pair needs at least ten of them to appear at all, and results are cached for one minute.

Where the whale-wall board sits next to the rest of the order book

The board is deliberately not a full order book. Only levels at or above your minimum are ever tracked, so the space between two rows is not empty book — it is simply size that never qualified. Aggregated depth, the imbalance history, the depth history and the order-book heatmap are separate endpoints with their own data path, and a second family of endpoints aggregates the same wall events into bid-ask totals, ratios and deltas rather than individual levels. Reading a whale-wall row as a complete picture of liquidity at that price is a mistake the data does not support.

The prices shown next to each venue do not come from the wall stream at all. The browser opens its own WebSocket connections to Binance Futures, Binance Spot, Coinbase and Hyperliquid and reads prices directly, which is why a card can display a live price before a single wall has arrived, and why the price keeps moving while the wall stream is reconnecting. The same wall runtime also backs a whale-walls widget in the Terminal, so the size thresholds and the currency toggle you set in one place apply in the other.