Slippage tolerance derived from staleness

What the guard compares

• The client sends, with the order, the price it showed the user. The server fetches the current ask or bid and rejects the order with a 400 when the two differ by more than a tolerance.
• The guard exists so that a user never fills far from the price they acted on, and the client never names its own fill price.

How old the client's price is

• The price on screen is polled. On the platform this is drawn from, the order form refreshed every three seconds, and the positions table and the chart every two. Each had its own timer. The server answered all of them from a cache refreshed every three seconds.
• The number a user acts on can be six seconds behind the vendor's feed. Two widgets on the same screen can show prices of different ages.
• On Binance spot one-second data for 2 to 8 June 2025, BTCUSDT moved past 0.05% within six seconds in 0.72% of windows, about 26 times an hour. PAXGUSDT, a gold-backed token, did so in 0.16%.

What a constant tolerance does

• A fixed 0.05% treats that lag as a market move and rejects the order. A manual close is rejected the same way.
• The 400 asked the user to reconfirm, and no reconfirm step existed on the client. The only visible outcome was a blocked close.
• Switching the guard off is one commented block. The quickest replacement, filling at the price the client observed, lets the client name the fill.

Deriving the tolerance

• The tolerance has to cover the move an instrument can make in the time the client's price can be stale: polling interval plus cache age, against the instrument's short-horizon volatility. That gives a figure per instrument and per feed.
• A reconfirm flow removes the rejection: the server returns its price and the client asks the user once. It costs a round trip and a screen and still needs a band to decide when to ask.
• With a user-set maximum slippage the user chooses the risk. The server fills at its own price or refuses.

A fabricated price inside the band

An order fills at the server's own price, and the guard decides only whether it fills. Every version above assumes the client's price is stale. None protects against a client that fabricates a price inside the band.