How do you know what a market order will cost before you send it?
Every trading interface shows you a price. Almost none of them tells you what your order will actually pay.
The number on screen is the best price for the first unit. A market order of any real size does not trade at the best price; it trades at the best price, then the next one, then the next, until the size is filled. The cost of that walk is slippage, and the only honest way to quote it in advance is to do the walk before the order goes out.
The price of one unit is not a price
An order book is a list of resting offers. On the ask side, someone is willing to sell 2.4 units at 3,001.0, someone else 5.1 units at 3,001.5, and so on outward. On the bid side the same structure runs the other way.
The "price" most interfaces show is either the best bid, the best ask, or the midpoint between them. All three describe what the next unit costs. None of them describes what a $50,000 order costs, because a $50,000 order does not stop at the first level.
This is why a small trader and a large trader looking at the same screen are looking at different prices. The small order fills entirely at the top of the book. The large one consumes the top and keeps going, and every level it reaches is worse than the last.
Walking the book
The estimate BT365 runs before a perps order is placed is a straightforward walk. For a buy, it takes the ask side; for a sell, the bid side. It fills the order's notional size level by level, starting from the best price, and tracks two totals as it goes: how much it has spent and how many units it has bought.
Divide one by the other and you have the average fill price. Compare that to the mid price — the point halfway between the best bid and the best ask — and the distance, in basis points, is the slippage estimate.
Three details in that walk matter more than they look:
- The depth is measured across the whole side, not just the part you consume. After the order is fully filled, the walk keeps going, summing the value of every remaining level. That total — the visible depth — is what decides whether the order is safe to send, and it is a property of the market, not of the order.
- The walk is over the book as it is, not a model of it. No assumption is made about liquidity arriving or leaving. The estimate answers one question: if this order hit the book right now, what would it pay?
- The result is a whole number of basis points. The walk is over a snapshot, and the book will have moved by the time the order lands; a figure quoted to fractions of a basis point would claim a precision the snapshot cannot deliver.
Leverage multiplies the bill
Slippage is a cost on the notional size of the trade. Leverage is what lets a trader post a fraction of that size as margin. Those two facts combine badly.
Open a position at 10x. Ten basis points of slippage on the notional is one percent of the margin you posted, paid on the way in. Close the position and pay it again on the way out. A fill that looked like rounding error at 1x is two percent of the capital at risk at 10x — before the trade has moved at all, and before funding.
This is the reason slippage matters more on a perps venue than on a spot exchange with the same book. The book is the same. The capital exposed to it is not.
When the estimate says no
An estimate on its own is only information. What makes it useful is a rule that acts on it, and the rule BT365 applies is a rejection, not a warning.
Before an order from BT365's V2 perps pipeline — the path its rules-engine-driven perps agents trade through — is approved, the pipeline's risk gate checks its size against the book it will hit:
- If the visible depth on the consumed side is under $25,000, the order is rejected. A book that thin cannot be trusted to hold its shape between the estimate and the fill. Whatever the walk said the order would cost, the real cost is unknowable.
- If the order would consume more than 30% of that depth, it is rejected. At that size the order is not taking liquidity, it is moving the price, and the estimate — which assumes the book is static — has stopped describing reality.
Both rules reject the order outright. The agent does not get a worse price; it does not get to trade. That is deliberate. A system that responds to a thin book by placing a smaller order has quietly changed the trade the strategy asked for. A system that refuses has left the decision where it belongs — with the strategy, on its next evaluation, against whatever book exists then.
Not knowing is not the same as knowing it's fine
There is one more case, and it is the one most systems get wrong. What should the estimate return when it cannot read the book?
The tempting answer is a default: assume a few basis points, carry on. BT365 does carry a fallback — a size-tiered guess used when the book cannot be fetched — but it is shaped so it cannot be mistaken for a measurement. The fallback carries no depth figure at all, so the two depth rules above cannot run against it; the order passes that gate unchecked, on the strength of the strategy's other checks rather than on a slippage number that was never measured.
That may sound like the same thing as assuming it is fine. It is not. The difference is whether the estimate itself records that the book was never read. A default that looks like a measurement erases that; a fallback with the depth left blank preserves it. When a fill comes back worse than expected, "we could not see the book" is an answer, and "the estimate said two basis points" — when nothing was measured — is a fabrication.
What this changes about reading a fill
A fill that lands worse than the mid price is not evidence of a bad venue or a bad order. It is the walk, made real. The question worth asking is whether the cost was known before the order went out, and whether the system would have declined the trade if it had been too high.
You cannot ask that of a system that only ever showed you the price of one unit.
BT365 runs Hyperliquid perps, prediction markets and spot from one self-custodial account, with book-depth checks in its automated perps pipeline. Explore the platform.