7 days Pro+ free · no cardStart my free trial

Execution mechanics: from intended orders to actual fills · 2 / 5

Reconstruct a maker queue before assuming a fill

A trade at your limit price does not prove that your order filled. A resting order can stand behind other orders. Matching priority depends on the venue and product; FIFO is one possible algorithm, and pro-rata allocation is another. A chart's low or high touching the limit is weaker evidence than an execution report.

Athenum6 minUpdated:

Declare the matching assumptions

Use a deliberately simplified price-time FIFO ledger to see the distinction. Assume all orders discussed are offers at 100 USDT; better-priced offers have already been consumed, no hidden quantity exists, and all events below are known in order. At the moment your eight-unit offer arrives, 30 units are ahead of it. Fourteen units arriving afterward are behind you and do not worsen your initial queue position under these assumptions.

Post-only and priority are separate questions

Post-only constrains how an order enters the book; it does not guarantee that it will fill, remain at the front, or earn money. An accepted maker order can be filled just before price moves against it. Modifying an order may reset its priority, depending on the modification and exchange rules. Any replay must apply the actual priority rules, not assume the original place in line survives.

Eight units join behind thirty

An aggressive buyer executes 18 units at 100. Your queue ahead falls to 12; you have no fill. Seven units known to be ahead then cancel, leaving five. A subsequent ten-unit aggressive buy executes the remaining five ahead and five of your units. You now have three units still resting. The market traded 28 units at your price, but only five of your units filled.

Hypothetical worked example — Eight units join behind thirty
EventQuantity ahead afterwardYour cumulative fillsYour remaining order
Your eight-unit order arrives3008
18 units execute1208
Seven known-ahead units cancel508
Ten units execute053
Hypothetical FIFO ledger with known order-level events. Aggregate book changes alone cannot establish this queue history.Open full-size diagram
  1. 30 units ahead when your order arrives
  2. 18 execute: 12 remain ahead, no own fill
  3. Seven known-ahead units cancel: five remain ahead
  4. Ten execute: five fill your order; three of your units remain
Hypothetical FIFO ledger with known order-level events. Aggregate book changes alone cannot establish this queue history.

An aggregate cancellation does not locate your queue

The word “known” matters. With aggregated level-two depth, a seven-unit decrease could be a cancellation behind you, a cancellation ahead, an execution, or several updates netted together. It does not establish the same queue improvement as this complete hypothetical ledger. A public tape and snapshot usually support bounds or a model, not perfect reconstruction of your live priority. Use the exchange's own order/fill reports to establish your actual fills.

Before acting

  • Name the matching algorithm and its assumptions.
  • Separate quantity ahead from orders behind.
  • Attribute cancellations only when order-level evidence permits it.
  • Apply actual amendment and priority rules.
  • Use order/fill reports to establish your own executed size.

Check your understanding

In the same FIFO ledger, the final aggressive buy is six units instead of ten. How much of your order fills and remains?

Show the explained answer

Five of the six units execute against orders ahead; one fills your order. Seven of your original eight units remain. Trading at your price does not allocate all that volume to your order.

Sources and further reading

Continue with Athenum