A replay console for hftbacktest market-making backtests. It runs one of hftbacktest's own tutorial strategies against real recorded Binance USDT-M Futures order-book data and shows what the engine sees and decides, frame by frame: the local order book, every resting order with its exchange-side queue estimate, feed and order latencies, market trades, executions, the raw feed the collector recorded, and the engine's own run statistics.

This repository is a backtester and a replay screen. Nothing in it places orders. What the backtest leaves out, in numbers from the BTCUSDT session recorded here (25 minutes, 0.002 BTC orders):

1. Fees. The tutorial strategy assumes a 0.005% market-maker rebate, as the tutorials state. A regular Binance USDT-M account pays a 0.02% maker fee. The spread was one tick 99.7% of the time; one tick is 0.013 bps of price, so the retail fee is 154 ticks per fill and the rebate is 38 ticks the other way. The session traded about $413k of notional: $83 of fees at the retail rate against $21 of rebate at the tutorial rate. The economics of quoting BTC at the touch exist only inside a rebate program.
2. Latency. The data was recorded on a laptop in Europe: 200 ms feed latency, a 250 ms round trip. The tutorials' data was collected near the exchange at about 4 ms. Here, 24% of the strategy's post-only orders were rejected because the market had moved while they were in flight. Binance Futures runs in AWS Tokyo (docs: market maker programs, a page that carries its own out-of-date warning).
3. Fills are modelled. Queue position is a probabilistic estimate from level-2 data; there is no market impact and no partial fill. Order latency here is derived from feed latency, not measured; the docs describe measuring it by placing far-from-mid orders and cancelling them (Order Latency Data). Their guidance for going live is to trade tiny size, plot live against backtest, adjust the queue model until they agree, and only then scale (