Price-Time Priority Explained: Who Gets Filled First on an Order Book?

You place a limit order. The market reaches your price. Someone else gets filled, but your order is still sitting there.

That does not necessarily mean something went wrong. You may have been behind other traders in the queue, and there may not have been enough incoming volume to reach you.

The rule behind that queue is price-time priority. It determines which orders get matched first, which get partial fills, and which keep waiting. Understanding it helps you evaluate execution beyond the price displayed on your screen.

Here is how it works, with competing orders you can follow by hand, and how KalqiX proves that its matching engine followed those rules.

What Is Price-Time Priority?

Price-time priority is a matching rule for a central limit order book, or CLOB. An order book collects bids from buyers and asks from sellers, then matches compatible orders.

The rule has two parts:

1. Price first: Orders offering the best price to the incoming trader get matched first.
2. Time second: At the same price, the order that entered the book earlier gets matched first.

For resting sell orders, a lower asking price has priority. A buyer should reach someone selling at $3,000 before someone selling at $3,001.

For resting buy orders, a higher bid has priority. A seller should reach someone buying at $3,000 before someone buying at $2,999.

Time only breaks ties within the same price level. An older order at a worse price does not jump ahead of a newer order at a better one.

This is the basic matching model used by major stock exchanges and centralized crypto exchanges. KalqiX's Rust matching engine also matches by price-time priority.

A Simple Example: Three Sellers, One Buyer

Imagine these hypothetical ETH sell orders are resting on an order book:

Now an incoming market order wants to buy 7 ETH.

A market order takes the best available prices rather than setting a maximum purchase price. Here is the matching sequence:

• Alice sells 2 ETH at $3,000.
• Ben sells 4 ETH at $3,000.
• Cara sells 1 ETH at $3,001.

Alice goes before Ben because they offer the same price and Alice arrived first. Both go before Cara because their price is better for the buyer, even though Cara's order is older.

Cara still has 2 ETH left on the book.

Notice that the buyer does not get all 7 ETH at the displayed best ask of $3,000. Only 6 ETH were available there. The remaining ETH fills at the next price level.

Priority determines the sequence. Available liquidity determines how far the order must go.

The Same Rule Works for Buyers

Now reverse the direction. Suppose the book contains these buy orders:

An incoming market order sells 2 ETH.

Eva buys 1 ETH first. Farah buys the next 1 ETH. Daniel gets nothing from this order.

Daniel arrived earliest, but his bid is lower. The seller gets a better price from Eva and Farah, so those orders have priority.

Farah's order is partially filled, with 1 ETH still waiting. Under a standard price-time model, that unfilled remainder retains its place ahead of later orders at the same price.

What Queue Position Actually Means

Queue position is your place among resting orders at a particular price.

Suppose you submit a bid for 2 ETH at $3,000. There are already bids for a combined 10 ETH at that price ahead of you.

If an incoming seller sells 6 ETH into that level, those earlier orders absorb the trade. Your order does not fill.

If another seller then sells 5 ETH, the remaining 4 ETH ahead of you fills first. You receive a 1 ETH partial fill.

Your price was competitive throughout. What changed was how much volume reached your position.

Think of each price level as its own checkout line. The matching engine visits the best-priced line first, then serves the orders in that line by arrival time.

But this is not a queue that must steadily move forward. Traders can cancel orders ahead of you, while better-priced orders can appear at other levels and attract incoming trades before yours.

Why Touching Your Price Is Not Enough

A trade at your limit price does not guarantee your order was filled.

The traded quantity may have been too small to clear the orders ahead of you. A chart showing the last traded price tells you where a trade happened, not how much liquidity remained ahead of your order.

That distinction matters when reviewing fills. “The market traded at my price” and “enough opposing volume reached my queue position” are different statements.

Cancelling and Replacing Can Change Your Place

Under a standard price-time model, cancelling an order and submitting a new one gives the new order a new arrival time.

Rules for modifying an existing order vary by venue. Some changes may preserve priority; others may reset it. Check the venue's order-handling rules rather than assuming every edit keeps your place.

Moving to a better price puts you in a different price-level queue. It does not carry your old timestamp into that queue.

Limit Orders, Market Orders and Immediate Execution

A limit order sets a price boundary. A buy limit specifies the most you will pay; a sell limit specifies the least you will accept.

That does not always mean waiting in the book.

A buy limit priced high enough to cross existing asks can execute immediately against those asks, starting with the best price. Depending on its time-in-force instruction, any unfilled remainder may rest on the book.

KalqiX supports limit and market orders, with these time-in-force choices:

• Good-till-cancelled: The order can remain open until it fills or is cancelled.
• Immediate-or-cancel: Whatever can execute immediately fills; the remainder is cancelled.
• Fill-or-kill: The entire order must execute immediately, or none of it does.

These instructions control whether an order can wait or accept a partial fill. They do not give it permission to skip better-priced or earlier eligible orders.

A market order avoids waiting for its own limit price, but it can consume several price levels. In a thin book, that can mean substantial slippage.

Fair Priority Does Not Guarantee a Good Price

Price-time priority answers a specific question: Did the engine allocate available fills according to the matching rules?

It does not answer every question about execution quality.

An engine can follow the rules perfectly while a market order receives a poor average price because the book is thin. A limit order can have a tight price boundary and still never fill.

When evaluating a venue, separate these questions:

• Spread: How far apart are the best bid and ask?
• Depth: How much can trade near those prices?
• Priority: Which eligible resting orders get filled first?
• Fees: What does the execution cost?
• Integrity: Can you verify that the engine followed its rules?

Also, time priority refers to the venue's ordering of accepted orders, not simply when you clicked a button. Network delays can affect when an order reaches the engine.

A matching proof should not be confused with a promise that every trader has identical connectivity.

How KalqiX Proves the Matching Rules Were Followed

On many venues, traders must trust that the matching engine respected its stated rules. Seeing a completed trade is not the same as verifying how the engine selected it.

KalqiX takes a different approach.

Orders are encrypted before they leave your device, and there is no public mempool exposing them before matching. The Rust engine matches by price-time priority, with sub-10 millisecond matching.

Every batch of trades is then proven using Succinct's SP1, a zero-knowledge virtual machine that can prove the execution of programs written in Rust.

The proof shows that orders were matched by price-time priority and that nothing was front-run or reordered. A smart contract on Base verifies the proof, where trades settle.

Trades match instantly; proofs follow. Matching latency and proof verification are separate steps, not one event.

For a plain-English explanation of the cryptography, read ZK Proofs Explained for Traders.

Privacy Before Matching, Transparency After

Encryption protects your order before it is matched. It prevents public observers from seeing your pending intent and trading ahead of it.

ZK proofs serve a different purpose: verifying that execution followed the rules. Encryption protects the order; the proof checks the matching.

After matching, trades are public on the KalqiX explorer. Trade data is also published to Avail DA, so anyone can independently rebuild the full state.

KalqiX's own trading app and partner exchanges use this infrastructure. Partners keep their own brands and frontends while connecting to a shared order book, rather than splitting liquidity across separate books.

FAQ

Does the biggest order get filled first?

Not under price-time priority. A smaller order at a better price, or an earlier order at the same price, has priority over a larger one.

Why did my limit order only partially fill?

There may not have been enough opposing volume left after earlier eligible orders were filled. Whether the remainder stays open depends on the order's time-in-force instruction.

Can I move ahead by offering a better price?

A better-priced order has priority over worse-priced orders on the same side of the book. But you join the queue at your new price and may still sit behind orders already resting there.

Does price-time priority prevent slippage?

No. It determines which orders match first, but a large incoming order can exhaust the best price level and continue into worse ones.

The Takeaway

The quoted price is only part of execution. Your place in the queue, the quantity ahead of you, and the available depth all affect whether you fill and at what average price.

Price-time priority makes that sequence understandable. KalqiX adds a way to verify that the engine followed it.

Explore order-book trading on the KalqiX app.