Inside the Order Book: From Arrival to Resting Order

You click Buy. Your app shows an order number. The position stays at zero.

That can be a perfectly normal outcome. The order reached a system that accepted it, but nobody has traded with it yet. An order number, a place in the book, and an execution describe three different events. A useful trading interface has to keep them separate.

Start with the machinery that sits between those events.

A small market we can follow

We’ll use a fictional exchange called Harbor and a fictional instrument called BAG, quoted in dollars. BAG is an accounting unit for the examples, not a real stock or token. Prices move in one-dollar ticks, quantities in whole units. Every order is fully displayed, and every participant in our examples is a different owner.

Harbor runs a continuous central limit order book: a shared record of outstanding buy and sell instructions that can trade whenever compatible orders meet. An order is resting when its unfilled quantity waits in that record for a counterparty. The matching engine is the software that selects compatible orders and records their trades.

Harbor gives better prices priority, then earlier orders at the same price. Trades execute at the resting order’s price. Ordinary limit orders use good till canceled, meaning an unfilled remainder can keep working until it trades or is canceled under Harbor’s rules. Hidden liquidity, auctions, routing, fees, and settlement sit outside this model.

Those are our market’s rules. They are not a claim that every exchange operates identically. Coinbase Exchange documents a comparable price-time model and resting-price execution. Other venues may add display-priority rules, auctions, or different allocation methods, so this example applies only to the rules declared here. Coinbase Exchange matching engine

Here is Harbor before our order arrives:

Side	Order	Price	Remaining units	Accepted sequence
Buy	B1	$99	6	100
Sell	S1	$100	4	101
Sell	S2	$100	3	102
Sell	S3	$101	5	103

The highest buy price is the best bid: $99. The lowest sell price is the best ask: $100. Their difference is a $1 spread. These are executable interests in our example, not a prediction of what BAG is worth. SEC Investor.gov glossary

A typical depth display compresses the two $100 sell orders into one row showing seven units. The engine still needs the individual orders underneath that row. It must know which owner trades, how much remains on each order, and which order comes first.

The displayed price level groups quantity; the engine retains the individual instructions that make up that quantity. The accepted sequence numbers show Harbor’s processing order, with a lower number coming first.

Figure 1.1. Before M1, S1 and S2 offer seven units at $100 and S3 offers five at $101; B1 bids for six at $99. M1 buys seven at $100, then leaves a three-unit bid at $100. S3 and B1 are unchanged.

Getting to the engine

Our application submits M1: buy ten BAG at a limit of $100, good till canceled.

In Harbor’s illustrative design, the gateway authenticates the request and checks its format. Admission controls check permissions, tick and size rules, and available buying capacity. A sequencer assigns accepted commands a definite processing order for this market. Only then does the matching logic apply M1 to the current book.

Real systems distribute those checks differently. Some checks happen at a broker before anything reaches an exchange; some happen at the venue. Our diagram groups responsibilities so we can follow the order. It does not prescribe a particular server layout.

The order book records outstanding trading interest. Matching logic changes that book according to the market’s rules. A gateway response may tell the app that a request reached the gateway. It cannot, by itself, tell us what matching subsequently did.

Protocol names deserve the same care. Coinbase’s public feed distinguishes an incoming order’s received event from an open event for a remainder that rests. An order can execute immediately without ever becoming a resting order. Coinbase full-channel lifecycle

The limit is permission to trade

M1 can buy at $100 or less. Harbor has sellers at $100, so M1 is immediately eligible to trade with them.

Under our starting conditions, seven units trade. Three remain unfilled. The next seller wants $101, beyond M1’s limit. Matching stops, and the three-unit remainder joins the buy side at $100.

The book now contains:

Side	Order	Price	Remaining units
Buy	M1	$100	3
Buy	B1	$99	6
Sell	S3	$101	5

The same order has taken available liquidity and then supplied liquidity with its remainder. Calling it a limit order did not guarantee that it would wait passively. Its price determined whether it could trade on arrival; its lifetime instruction determined whether an unmatched remainder could stay.

The seven executed units consist of four bought from S1 and three from S2, all at $100. A fill is one completed execution against another order. M1 has two fills totaling $700 and a three-unit working remainder. Its lifecycle is admitted, processed, partly executed, then resting for the unfilled quantity.

Figure 1.2. Gateway receipt only confirms a request arrived. After admission and ordered processing, M1 buys four from S1 and three from S2. Its three unfilled units rest at $100; an order can execute and also leave a working remainder.

A different incoming order, buy three at $99, would find no eligible seller in the initial book. It would join the buy side without an execution. An order rejected for an invalid tick would never enter the book at all.

What the app needs to retain

A single status label compresses several facts. For M1, the app needs at least the original requested quantity, cumulative executed quantity, remaining executable quantity, and the order’s current state.

After the first pass, those values are ten requested, seven executed, and three still working. Showing only “Open” hides the purchase that already happened. Showing only “Partially filled” without the working remainder hides continuing exposure.

This also explains why an order history and a trade history serve different purposes. One order can create several trades. An order can also finish with unfilled units removed, rather than with every requested unit executed.

When the screen lies about the book

Suppose Harbor admits M1 and reports that it has received the order. A faulty market-data client immediately adds all ten units to its local buy book. The actual engine then trades seven and rests three.

The client has invented liquidity. Depending on which subsequent updates it handles, it may show ten, subtract seven twice, or retain an order that never rested in its original size. Its display can look plausible while disagreeing with the venue.

Coinbase explicitly warns book builders that receipt is not evidence of resting liquidity and that some terminal or change messages concern orders that never rested. That is a concrete reason to build from the documented lifecycle rather than infer book changes from message names. Coinbase book-building guidance

For Harbor, the operational response is to fix the lifecycle handling and rebuild the local book from a valid snapshot and subsequent updates. Check sequencing and repair any detected gaps as well; this particular bug can corrupt a book even when no message is missing. Use private order reports to establish M1’s own outcome. A public depth display alone does not prove what your account traded.

Where this explanation stops

In this example, S1 gets selected before S2 because both ask $100 and S1 has the earlier accepted sequence. That rule determines who sells; the two fills and the resting remainder explain what happens to the incoming buy order. A different venue’s priority rules can change the selected counterparties without changing the distinction between receipt, resting interest, and execution.

Matching also leaves work for surrounding systems. Brokers manage their customers’ instructions and exposure. Other services record balances, positions, fees, and post-trade obligations. An execution creates an outcome those systems must process; the matching example does not settle the asset or transfer custody.

When an order appears stuck, locate the last confirmed event. Gateway receipt, engine processing, a resting remainder, and an execution each answer a different operational question.