At 08:00 UTC on a Tuesday, a crypto venue changed the tick size for a mid-priced perpetual contract. Our basis strategy did not notice. Its signal still saw the same spread between spot and futures, its risk limits were unchanged, and its backtest kept printing the same results.
Paper trading noticed for it. The order adapter rounded a buy limit down to the nearest permitted price. That put the order one tick below the level the backtest had modeled. The market touched the old price, the simulated order filled, and the paper order sat untouched. By lunch, the strategy's inventory was lopsided.
The incident looked like a small rounding bug. It was really a model boundary problem: the strategy knew prices, but the backtest did not know the venue's price grid.
We were trading a simple basis signal, buying spot and selling a perpetual when the futures premium widened beyond a threshold. The orders were passive because the expected basis edge was small. A few ticks could decide whether the entry earned enough to cover fees and the eventual exit.
What changed when the tick size changed?
Before the update, the perpetual accepted prices in increments of 0.01. Afterward, it accepted 0.05 increments in the relevant price band. The signal computed a target sell at 42,318.03, a valid price under the old rule. Under the new one, that price was invalid.
The exchange rejected invalid prices, but our adapter had a fallback: it rounded the sell down to 42,318.00. That was still invalid. A second fallback rounded again, this time to 42,318.05, which was valid but less aggressive for a seller. The order could no longer sell at the modeled price. The code path had been written for a different market and quietly turned rejection into a repriced order.
That one order crossed two distinct questions. First, what price may the venue accept? Second, how should a strategy respond when its desired price is not on the grid? The exchange answers the first. The strategy or execution policy must answer the second.
| Order intent | Grid rule | Typical rounding direction | What it can change |
|---|---|---|---|
| Buy limit | Price must be a tick multiple | Down to stay at or below the limit | Lower fill probability |
| Sell limit | Price must be a tick multiple | Up to stay at or above the limit | Lower fill probability |
| Marketable limit | Must also respect price bounds | Depends on the maximum acceptable price | Whether it crosses the spread |
There is no universally correct rounding rule. Rounding a buy down preserves the buyer's price constraint, but can make a fill less likely. Rounding up may make the order marketable, which changes fees and impact. For our passive basis entry, silently moving the order was the wrong behavior. The strategy had chosen a target; the adapter changed its economics.
Why did the backtest still look healthy?
Our historical order simulator treated limit prices as continuous numbers. If the bar's low reached the buy price, or its high reached the sell price, it counted a fill. That is already a generous approximation for a passive order, since a traded price at the limit says nothing about queue position. But the tick update made the gap more basic: the order could not have existed at that price.
We replayed the same decisions with the new grid applied from its effective time. Several fills disappeared. A few orders rounded to prices that crossed the spread and picked up taker fees instead of maker fees. The resulting position path diverged, so later hedges and exits changed too. A rule that looked like metadata had altered the entire trade sequence.
And the update was not a surprise hidden in a chart. The venue had published an instrument-rule change with an effective timestamp. We stored market data carefully, but instrument metadata lived in a cache refreshed at startup. The backtest read today's rules for every historical date; paper trading had stale rules until the process restarted. Neither environment represented what the venue allowed at each moment.
How should a backtest model tick-size changes?
Version instrument rules with validity intervals, just like other point-in-time inputs. At minimum, retain the effective time and the rule values needed to validate an order: tick size, quantity step, minimum quantity, and any price bands. The simulator should load the rule set available at the simulated decision time.
Then make order handling explicit. If a target price is invalid, reject it, round it according to a documented policy, or recalculate the target on the grid. Record which happened. A backtest that automatically repairs every order may be useful for estimating a particular execution policy, but it should not disguise that policy as an exchange fill.
For passive orders, a tick-valid price is only the first condition for a fill. You still need a model for whether the market traded through your price, the queue ahead of you, cancellations, and the fee tier you would have earned.
We added two checks. One runs every generated order through the point-in-time instrument rules and fails loudly on invalid prices or sizes. The other compares the backtest and paper adapter's final normalized order: side, price, quantity, time-in-force, and fee intent. If they disagree, the run is not considered comparable.
After that, we replayed the Tuesday change. The backtest no longer claimed fills at 42,318.03 after the grid update. Paper trading and simulation made the same decision about each invalid target, even when that decision was to skip the order.
The signal had not broken. Its assumptions about the object it could trade had gone stale. A strategy can survive a new tick size, but only if the research system treats venue rules as part of the market it is simulating.
← All posts
