A market order gets one quote, then walks through several prices

The screen says Bitcoin is available at one price. Buy enough of it, though, and that price runs out. The rest of the order has to keep walking.

Depthwalk is a small browser lab for watching that happen. It replays historical level-two order-book snapshots, then lets you send a simulated market buy or sell through them. Drag the size control and the book's colored levels turn amber as they are consumed. At the same time, the average fill price and dollar cost of slippage move.

I built it because slippage is usually explained with one sentence: a large order fills at progressively worse prices when there is not enough volume at the best quote. That sentence is correct, but it skips the useful part. Seeing the third and fourth levels disappear makes the mechanism much harder to forget.

One order, several prices

An order book is a pair of ladders. Bids are offers to buy, asks are offers to sell, and each rung has a price and an available quantity. A market buy begins at the cheapest ask. If the order is larger than the quantity there, it takes that whole rung and continues to the next cheapest ask. A market sell does the mirror image on the bid side.

Depthwalk does that calculation in a Rust matching engine compiled to WebAssembly. It is not a sequence of prewritten highlights. On every change to the slider, the engine walks the selected snapshot level by level and returns the actual fills: price, consumed quantity, filled size, unfilled size, and volume-weighted average price. Invalid levels and non-positive order sizes are ignored rather than allowed to spoil the result.

For a buy, the displayed slippage cost is (average fill price - best ask) × filled size. A 1-unit order filled half at $100 and half at $102 has an average price of $101, so its slippage against the original $100 quote is $1. That number is not a fee. It is the cost of demanding more liquidity than the best price level offered.

D3 owns the picture, but none of the matching logic. It receives structured fill results and draws the remaining and consumed portions of each rung. Keeping that boundary means the Rust engine can be tested without a browser, while the renderer does not need its own second opinion about the math.

Why the data does not need to be live

Live exchange feeds sound more authentic, but they add API keys, reconnect logic, rate limits, and an awkward question: will an interesting thin book appear while somebody is trying to learn from it? Depthwalk instead bundles two historical scenarios with six timestamps each. One is a deep BTC-USD book. The other is a deliberately thin AUCTION-USD book. The same order can behave politely in the first and chew through several levels in the second.

That choice also defines the limit. This is a replay against frozen snapshots, not a trading terminal, execution venue, or forecast. It does not model orders arriving and cancelling while your trade executes. Level-two data aggregates quantity by price, so it also does not show the individual orders waiting within a rung. Those omissions are acceptable for the lesson I care about: a quote describes the front of the queue, not the price guaranteed for every unit.

The whole experiment stays client-side. The snapshots are static files, the matching engine runs in the tab, and no simulated order goes anywhere. That makes the lab deployable as a static site and, more importantly, makes the first experiment require no account or data subscription.

Try it

Open Depthwalk, choose the deep BTC-USD book, and raise the order size until the amber slippage counter first leaves zero. Keep that size, switch to the thin AUCTION-USD scenario, and compare how many levels disappear and whether any size is left unfilled. The matching engine and snapshot provenance are on GitHub.