How to Backtest Execution Costs Across DEX Perpetuals

Why Backtesting Execution Costs Matters as Much as Strategy Backtesting

Most traders who backtest their strategies do so with simplified cost assumptions: a flat 0.1% per round trip, or "taker fee only." These assumptions feel conservative but often dramatically underestimate true execution costs — and can turn a paper-profitable strategy into a real-world loser. If your backtest shows 15% annual returns but your actual execution costs are 2x your assumed costs, your live returns might be closer to breakeven or worse.

Execution cost backtesting — modeling the actual cost of each historical trade, including slippage, spread, price impact, and fees, based on real historical market data — closes this gap. It is the difference between knowing your strategy "worked historically" and knowing whether it actually earned alpha net of true costs. For any strategy trading DEX perpetuals, this distinction is critical because execution costs vary dramatically by exchange, order size, time of day, and market conditions.

This guide shows you exactly how to build a basic execution cost backtester for DEX perpetuals using LiquidView's historical data API, with a worked example comparing BTC execution costs across five exchanges over 30 days.

What Data You Need for Accurate Execution Cost Backtesting

Accurate execution cost backtesting requires more than just historical price data. To model what a trade would have actually cost at a given historical moment, you need four categories of data at the time of each hypothetical trade.

First, you need historical bid-ask spread data at the precise timestamp of each trade. Spread is a cost component that varies significantly throughout the day and across market conditions — using a daily average spread rather than the spread at the exact trade moment introduces meaningful error. LiquidView provides spread data at 1-minute resolution, which is sufficient for most non-HFT backtests.

Second, you need historical order book depth data at standardized order sizes. Knowing that the spread was 0.5 bps tells you nothing about the impact of a $300K order — for that, you need to know how much depth existed at each price level near the mid-price at that moment. LiquidView stores depth snapshots at $10K, $50K, $100K, $250K, and $500K standardized sizes, allowing you to interpolate impact for any order size in that range.

Third, you need the fee schedule that was in effect at the time of the trade. Fee schedules change — both as exchanges update their structures and as your own volume tier changes over the course of a month. Backtesting with today's fee schedule applied retroactively to all historical trades introduces a systematic bias if fees have changed.

Fourth, for strategies holding positions for more than a few hours, you need historical funding rate data at each settlement period. Funding rate is often the largest single cost component for longer-duration positions, and ignoring it will overstate historical performance on long-biased strategies during positive funding periods.

• Historical bid-ask spread: at 1-minute or finer resolution for the execution timestamps
• Historical order book depth: at standardized sizes to estimate price impact for your order size
• Historical fee schedules: particularly important if your volume tier changes or fees were adjusted
• Historical funding rates: at each settlement interval (typically every 8 hours) for the full holding period
• Historical mid-price: to compute mark-to-market P&L separately from execution cost

Using the LiquidView API to Fetch Historical Execution Data

The LiquidView historical API makes the data collection step of execution cost backtesting straightforward. All data is returned in JSON format with UTC timestamps, suitable for direct import into pandas DataFrames or similar data structures.

To fetch historical execution cost data for a specific exchange and token: GET /api/v1/historical-cost?exchange=hyperliquid&token=BTC&size=100000&from=2026-01-01&to=2026-01-31&interval=1m. This returns a time series of all-in execution cost estimates in basis points at 1-minute intervals for $100K BTC orders on Hyperliquid throughout January 2026. The response includes the component breakdown (fee, spread, impact) alongside the composite cost.

To fetch data for multiple exchanges simultaneously for cross-exchange comparison: GET /api/v1/historical-cost/all?token=BTC&size=100000&from=2026-01-01&to=2026-01-31&interval=1m. This returns the same time series for all nine supported exchanges in a single call, with one key per exchange. This is the most efficient way to gather the data needed for the multi-exchange BTC backtest described later in this article.

For funding rate data: GET /api/v1/historical-funding?exchange=hyperliquid&token=BTC&from=2026-01-01&to=2026-01-31. Returns an array of funding rate settlements with timestamp, rate (as a percentage), and annualized rate for convenience. Join this with your trade log on the position open and close timestamps to compute total funding paid or received during each holding period.

Building a Basic Execution Cost Backtester in Python

The following Python pseudocode outlines a minimal but complete execution cost backtester. It takes a list of historical trades (timestamp, exchange, token, side, size, duration) and computes the actual estimated cost of each trade using LiquidView historical data.

Step 1 — Load historical execution cost data. Fetch the all-exchanges time series for your token and order size for the full backtest period. Store as a dictionary keyed by (exchange, timestamp) for O(1) lookup. Fetch historical funding data for each exchange separately and store as a list of (timestamp, rate) tuples sorted chronologically.

Step 2 — For each trade in your signal log, look up the execution cost at the nearest available timestamp (round to the nearest interval). Extract the composite cost in bps and the component breakdown. Multiply the composite cost by the position size in USD to get dollar cost of entry.

Step 3 — For each held position, sum the funding rate payments at each settlement period between entry and exit. Use the actual historical funding rates from the API, not a static assumption. This gives you total funding cost (or income) for the holding period.

Step 4 — Look up the execution cost at the exit timestamp for the exit trade. Add entry cost, exit cost, and net funding to get total round-trip execution cost. Subtract this from the gross P&L (mid-price at exit minus mid-price at entry, times size) to get net P&L.

Step 5 — Aggregate results. Compute total gross P&L, total execution cost, net P&L, and the ratio of execution cost to gross P&L. This ratio — how much of your raw returns you give up to costs — is the key diagnostic metric. A ratio above 50% indicates that your strategy's edge is dangerously thin relative to costs.

• Libraries needed: requests (API calls), pandas (data manipulation), numpy (math), datetime (timestamp handling)
• Handle missing data: interpolate linearly between timestamps when exact match is unavailable
• Size interpolation: if your order size falls between API size points, interpolate impact linearly
• Fee tier handling: track cumulative monthly volume and apply the correct fee tier for each trade
• Output: per-trade P&L table plus summary statistics (total cost, cost ratio, Sharpe with/without costs)

Example Backtest: BTC Across 5 Exchanges Over 30 Days

To make this concrete, here is a worked example of a 30-day execution cost backtest comparing BTC-USD execution across Hyperliquid, Lighter, Paradex, gTrade, and Orderly Network for January 2026. The signal is simple: enter a long position when BTC is below its 24-hour VWAP, exit when it crosses above. Order size is $100,000 per trade.

The signal generated 42 round-trip trades over the 30-day period. Gross P&L (mid-price moves, ignoring cost) was +$12,400, or 12.4% on $100K capital. Now we apply actual execution costs from LiquidView historical data for each exchange.

Hyperliquid: Average all-in entry cost: 4.2 bps. Average exit cost: 4.1 bps. Average funding per position (hold time ~6 hours): 0.3 bps. Total cost per round trip: 8.6 bps = $86. Total cost, 42 trades: $3,612. Net P&L: $8,788. Cost ratio: 29.1%.

Lighter: Average entry cost: 4.5 bps. Average exit cost: 4.3 bps. Funding: 0.2 bps. Total per round trip: 9.0 bps = $90. Total: $3,780. Net P&L: $8,620. Cost ratio: 30.5%. Nearly identical to Hyperliquid at this order size — the advantage difference is small for $100K.

Paradex: Average entry cost: 7.8 bps. Average exit cost: 7.5 bps. Funding: 0.3 bps. Total per round trip: 15.6 bps = $156. Total: $6,552. Net P&L: $5,848. Cost ratio: 52.8%. Costs consumed more than half of gross profits. The strategy is still profitable, but the margin is thin.

gTrade: Average cost: 18.5 bps (fee + dynamic spread, oracle model). Total per round trip: $185. Total: $7,770. Net P&L: $4,630. Cost ratio: 62.7%. This strategy is marginal on gTrade for $100K orders — a bad streak or a slight change in market conditions would push it into loss territory.

Orderly Network: Average cost: 22.3 bps due to thinner liquidity. Total: $9,366. Net P&L: $3,034. Cost ratio: 75.5%. Costs have consumed three-quarters of gross profits. This strategy is not viable on Orderly at $100K order size.

Interpreting Backtest Results and Avoiding Common Pitfalls

Once you have your backtest results, the most important metric to examine is the cost ratio — the percentage of gross P&L consumed by execution costs. A cost ratio below 25% is healthy for most strategies. Between 25–40% is acceptable but sensitive to execution quality degradation. Above 40%, your strategy has limited robustness — small changes in market conditions or exchange policies could make it unprofitable. Above 60%, the strategy is unlikely to survive real-world conditions.

A common pitfall in execution cost backtesting is survivorship bias in exchange selection. If you only backtest on exchanges that still exist and are liquid today, you will miss historical periods when your preferred exchange had much thinner liquidity — in its early days, during market stress events, or during major outages. This makes historical costs look better than they were and overstates expected future performance.

Another pitfall is assuming your historical impact model will hold at larger sizes. LiquidView's depth data lets you estimate impact at your current order size, but if you plan to scale the strategy — trading $200K instead of $100K — impact does not scale linearly. Run the backtest at your intended future size, not your current size, to stress-test robustness.

Finally, do not confuse backtested execution cost with guaranteed future execution cost. Order book depth is dynamic and can change dramatically over short periods. A LiquidView data-backed backtest gives you the best available historical estimate, but real-world performance may differ if market structure changes materially. Run your backtest on multiple time windows (a calm month, a volatile month, a trending month) to check robustness across conditions.