Order Flow Imbalance Flash Maker — Patch Update

Audit / Issue Found

The strategy had two ways to record a trade and they were not consistent with each other. Market orders such as scratch closes, position-cap reductions, and flash entries bumped the trade counter immediately when they were sent. The post-only spread quotes never bumped the trade counter at all, even when they filled. So the trade count was visible only for emergency or aggressive actions, not for the regular spread capture the strategy is built around.

Before the patch

A clean session running off the bot's normal post-only quotes could show a trade count of zero even after many spread captures. Win-loss and profit-and-loss were updated by an inventory detector but the trade counter and the volume totals were not, so the dashboard numbers contradicted each other. When the strategy did fire a market action, the trade count moved by one, but if the next cycle the inventory detector also saw the same inventory drop it had no way of knowing the market action had already been booked.

After the patch

Every market-order path now tags the cycle with the quantity it sent. The inventory-delta detector at the end of the cycle treats observed inventory change as the authoritative source for the trade counter. Before counting, the detector subtracts the tagged quantity so a market order does not get counted a second time. Any remaining observed inventory change is a real post-only fill and is counted exactly once.

The profit-and-loss and win-loss tallies retain their existing inventory-based math, which was already correct on the close direction.

Bottom line

The trade counter and volume figures now reflect every actual fill, including the routine spread captures that drive most of the strategy's profit. The dashboard is internally consistent with itself for the first time.

Follow-up correctness audit, same day

Three real issues were found and fixed in a deeper review.

First, the carry-over window between a tagged market order and the detector that watches for the resulting balance change was only one cycle. If a market order partially fills across two or three ticks, the leftover portion would be counted as a brand-new fill and the trade counter would over-count. The window is now five cycles by default, tunable per pair.

Second, a safety reaper was added. If a market order is cancelled before filling, or the exchange never reports the matching balance change, the carry-over would have lived forever and quietly absorbed every future fill in that direction. The reaper drops the tag after the window expires and warns about the unmatched quantity in the log.

Third, the side-panel value labelled Pair Exposure was always showing one hundred percent on this strategy because the formula was the spot-side version and the strategy runs on futures. The fix replaces it with a futures-correct calculation, position notional divided by wallet balance.

Other findings were checked and confirmed as false positives or design choices unrelated to the patch.