Backtesting a Solana HFT Bot with Tardis Machine Data

Solana DEX liquidity is fast, thin, and slot-dependent. Before you commit capital to a high-frequency bot on Solana, you need a simulation environment that actually reflects what the matching engine does to your orders — not a bar-chart replay from a BI dashboard. Tardis Machine is the closest thing the crypto world has to a professional tick-data replay server, and this article walks through exactly how to use it for a credible Solana HFT backtest.

Why Tardis Machine Over Raw CSV Ticks

Tardis Machine streams historical order-book data as a local WebSocket endpoint that emulates a real exchange feed. Instead of loading a CSV and iterating rows, your strategy code connects to ws://localhost:8000/replay and receives normalized book_change and trade messages at their original cadence, including microsecond timestamps. That matters because HFT logic is inherently event-driven — your fill logic, queue-position model, and resubmission timers all need to fire in response to individual events, not batches.

For Solana specifically, Tardis provides Openbook v2 and Phoenix snapshots sourced from validator-level RPC logs. The data includes slot numbers alongside wall-clock times, which lets you reconstruct the true sequencing of trades and book updates within a single 400 ms slot boundary.

Setting Up the Replay Environment

Install the Tardis Machine Docker image and pull the datasets you need:

docker run -p 8000:8000 -e "TM_API_KEY=<your_key>" tardisdev/tardis-machine

Use the tardis-dev Python or Node client to request a date range. For a realistic Solana HFT backtest, two to four weeks of data covering different volatility regimes — a quiet week, a high-volume news day, and a liquidation cascade — will expose edge cases that a single market condition will not.

Keep the replay speed at 1x real-time. Cranking it to maximum speeds introduces artificial event coalescing because your strategy process cannot drain the socket fast enough, which will silently corrupt fill-rate statistics.

Building a Minimal Fill Simulator

The fill simulator is where most backtests go wrong. The temptation is to assume any limit order at or through the best price gets filled immediately. In practice, Solana DEX fills depend on whether your order reaches the matching engine before the slot closes and whether a superior order already consumed the available liquidity.

Model queue position using a FIFO approximation: when your order arrives at a price level, estimate your position as the size already resting at that level at the moment of your submission. Track how much volume trades through that level across subsequent trade events. Your order is filled only once cumulative traded volume at your price exceeds your estimated queue position. This is not perfect — Openbook v2 uses a deterministic on-chain CLOB so true queue position is provable from transaction logs — but the FIFO approximation is accurate enough to identify strategies that are systematically too slow.

Record three metrics per order:

• Fill rate: what fraction of submitted orders execute at all
• Fill latency: slots between submission and execution
• Slippage: difference between your limit price and the actual trade price on aggressive orders

Avoiding Look-Ahead Bias at the Tick Level

Look-ahead bias in a bar-chart backtest is obvious — you used tomorrow's close to make today's decision. At tick level it is subtler. The two most common forms in Solana simulations are:

Snapshot contamination. Tardis delivers periodic book snapshots alongside incremental book_change events. If your strategy initializes its internal order-book state from a snapshot that arrives after the first trade you want to simulate, you are implicitly using a later state of the book to evaluate an earlier signal. Always build your book state incrementally from the first book_change event in your replay window and discard the first snapshot if it arrives after any trade event.

Timestamp alignment between feeds. If you are combining Tardis data with an external signal — say, a Pyth oracle price or a Hyperliquid perp mid — make sure you align on event sequence, not wall-clock time. A 50 ms oracle lag is realistic; in a backtest where you align on timestamp with sub-millisecond precision, you are effectively trading on a price you would not have had.

Measuring PnL Realistically

Mark open positions at the mid-price of the replayed book at each evaluation point, not at your order price. Use a cost basis that includes the Solana network fee (currently ~0.000005 SOL per signature, plus priority fees that spike to 0.001 SOL or more during congestion) and the taker fee on whichever venue you are targeting.

A strategy that looks profitable at zero fees but breaks even at realistic fees has a cost-of-carry problem, not a signal problem. Separate the two early. Run a fee sensitivity sweep: plot PnL against fee tiers of 0, 1, 2, and 5 basis points to find your fee break-even fill rate. If the curve is steep, the strategy is fragile; if it is flat, you have margin to absorb execution variance in live trading.

Moving From Backtest to Paper Trading

A backtest tells you whether your logic has positive expected value given historical data. Paper trading tells you whether your infrastructure can actually execute that logic. The gap is usually latency: your Tardis replay runs locally at consistent speed, but production requires a co-located RPC node, a priority fee bidding strategy, and transaction retry logic that can add 50–200 ms in the worst case.

Before going live, run your strategy against the Tardis replay one more time, this time injecting an artificial latency jitter of 50–300 ms on every order submission. If the backtest PnL degrades by more than 30%, the edge is latency-sensitive enough that infrastructure quality will determine profitability more than signal quality.

---

If you want this infrastructure built and tuned by engineers who have shipped Solana HFT bots into production, talk to TierZero.