← Back to lab
Lab

Slippage tolerance derived from staleness

A price-deviation guard with a constant tolerance rejects honest orders whenever the client's quoted price is older than the move it measures; the tolerance has to come from how stale that price can be.

↓

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 intent is that a user never fills far from the price they acted on, and that 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, the positions table and the chart every two, each on its own timer, and 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, and two widgets on the same screen can show prices of different ages.
  • On a volatile pair, a move past 0.05% inside six seconds is routine.

What a constant tolerance does

  • A fixed 0.05% treats that lag as a market move and rejects the order. The honest action it rejects most is a manual close.
  • 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, removes the protection entirely, because the client now names 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 is a figure per instrument and per feed, not one constant.
  • 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 it still needs a band to decide when to ask.
  • A user-set maximum slippage moves the choice to the person taking the risk and leaves the server to fill at its own price or refuse.
  • Filling at the client's observed price is not a tolerance. It is the server accepting the client's number as the market.

Where it stops holding

Every version above assumes the client's price is honest and stale. None of them protects against a client that fabricates a price inside the band. The guard decides whether an order fills; the server's own price is what it fills at, in every case. A fill price taken from the client sits outside anything a tolerance can protect.

Up next
Liveness observed by the server→