Skip to content

Rigorous Backtesting for Hyperliquid Trading Agents

Learn how to backtest your Hyperliquid trading strategies effectively. Avoid common pitfalls like look-ahead bias and overfitting to build robust agents.

6 min read

Rigorous Backtesting for Hyperliquid Trading Agents
On this page

Quick Answer

To backtest effectively on Hyperliquid, you must simulate execution against historical order book data while accounting for latency, slippage, and funding rates. Most traders fool themselves by using 'perfect' fills at the mid-price or ignoring the impact of their own order size on the market. A robust backtest requires a realistic simulation environment where your strategy logic is tested against actual historical snapshots. Using infrastructure like Antei allows you to run these simulations on historical data before moving to paper trading, ensuring that your strategy behaves predictably under market stress before you commit real capital. By separating your logic from the execution layer, you ensure that your backtest results reflect the reality of the exchange environment rather than a sanitized, theoretical model.

Key Takeaways

  • Use historical order book depth rather than simple OHLC candles to estimate realistic slippage.
  • Account for funding rate payments, as these can erode the profitability of long-term positions.
  • Implement a 'paper trading' phase after backtesting to catch logic errors that simulation might miss.
  • Separate your data into 'in-sample' and 'out-of-sample' sets to prevent overfitting your strategy parameters.
  • Ensure your risk management logic is decoupled from your strategy logic to prevent catastrophic code failures.
  • Always simulate the impact of your own order size on the available liquidity at the best bid and ask.

The Mechanics of Realistic Backtesting

Backtesting is the process of applying a trading strategy to historical data to see how it would have performed. The most common failure mode is 'look-ahead bias,' where your code accidentally uses information from the future (e.g., the closing price of a candle) to make a decision at the start of that same candle. To avoid this, your backtesting engine must process data sequentially, as if it were receiving a live stream.

Data Granularity and Fidelity

Using 1-minute candles is often insufficient for high-frequency or market-making strategies. You need tick-level or order book snapshot data. Hyperliquid provides high-fidelity data that reflects the true liquidity available at different price levels. If your strategy intends to buy 10,000 units of an asset, your backtest must check if there is enough depth at the ask price to fill that order without moving the market significantly. If you only look at the mid-price, you are ignoring the 'market impact' of your own trades, which is the primary reason backtests fail to translate to live performance.

Transaction Costs and Funding

Many backtests ignore the cost of trading. On Hyperliquid, you must account for: 1. Maker/Taker Fees: These are small but cumulative. A strategy that relies on high-frequency trading can be rendered unprofitable by fees alone. 2. Funding Rates: If you hold a perpetual position, you pay or receive funding every hour. Ignoring this can turn a profitable strategy into a losing one, especially for long-term trend-following strategies that hold positions across multiple funding intervals. 3. Slippage: The difference between the expected price and the actual execution price. In a backtest, you must simulate the order book depth to determine where your order would actually be filled.

Worked Example: Simulating a Mean Reversion Strategy

Imagine you are building a mean reversion strategy that buys when the price drops 2% below the 20-period moving average.

Variable Value (Example)
Position Size 1,000 USDC
Historical Slippage 0.05%
Trading Fee 0.02%
Funding Rate (Hourly) 0.001%

If your strategy triggers a buy at 100 USDC, a naive backtest might assume you get the full 1,000 USDC worth of assets at 100 USDC. A rigorous backtest calculates: - Execution Price: 100.05 USDC (accounting for 0.05% slippage). - Fee: 0.20 USDC (0.02% of 1,000 USDC). - Total Cost: 1,000.20 USDC + slippage impact.

If the price stays flat for 24 hours, you must also subtract 24 * (0.001% * 1,000) = 0.24 USDC in funding payments. If your backtest doesn't track these, you will overestimate your performance. Over a year, these small costs compound significantly. A strategy that looks profitable on a gross basis often becomes a net loser once these friction costs are applied. Furthermore, if your strategy is large enough to move the market, you must simulate the 'price impact' of your order, which is the cost of consuming the liquidity available at the best bid or ask.

Failure Modes in Backtesting

Overfitting

This happens when you optimize your strategy parameters (like RSI periods or moving average lengths) so perfectly for the past that the strategy fails on new, unseen data. To avoid this, use a 'walk-forward' analysis where you train on one period and test on the next. If your strategy performs exceptionally well on the training set but poorly on the test set, it is likely overfitted.

Latency Neglect

In a backtest, your code executes instantly. In reality, your agent's order must travel to the exchange, be processed, and be matched. If your strategy relies on being the first to hit a price, your backtest might be overly optimistic. You should introduce a synthetic delay in your backtest to simulate the round-trip time of an order.

Survivorship Bias

This occurs when you only test your strategy on assets that are currently performing well. Ensure your backtest includes assets that have been delisted or have performed poorly, otherwise, your results will be skewed toward success.

Step-by-Step Workflow for Deployment

  1. Define the Strategy: Write your logic in Python, Node.js, or Pine Script. Use Antei to structure your agent and ensure it is ready for the Hyperliquid environment.
  2. Historical Backtest: Run your code against historical Hyperliquid data. Focus on drawdown and Sharpe ratio rather than just total return. Ensure you are using out-of-sample data to validate your results.
  3. Paper Trading: Deploy the agent in a simulated environment. This is crucial because it tests your code's ability to handle network errors, API rate limits, and real-time data streams. You can use the Antei MCP server to connect your AI assistants to this process.
  4. Risk Limits: Set hard limits on your account. Even if your strategy code has a bug, the risk management layer should prevent the agent from liquidating your entire account. Antei enforces these limits outside your strategy code.
  5. Live Deployment: Start with a small amount of capital to verify that the live execution matches your paper trading results. Monitor the agent closely during the first few days of operation.

Frequently Asked Questions

Why does my backtest look better than my live trading?

This is usually due to 'slippage' or 'latency' that the backtest didn't account for. Backtests often assume perfect fills, whereas live markets have limited liquidity and network delays. Additionally, your backtest might be ignoring the impact of fees and funding rates, which are constant drains on your capital.

How much data do I need for a good backtest?

It depends on the strategy. For a trend-following strategy, you might want months of data to capture different market regimes. For a market-making strategy, a few days of high-volatility data might be more valuable than months of flat data. The goal is to test your strategy across a variety of market conditions, including high and low volatility, and trending and ranging markets.

Can I use Pine Script for my backtest?

Yes, you can use Pine Script for initial logic prototyping on TradingView, but for production-grade agents on Hyperliquid, you should eventually port that logic to Python or Node.js to ensure it integrates properly with the exchange's API and your risk management infrastructure. Antei supports these languages to ensure your production code is robust and secure.

What is the purpose of paper trading?

Paper trading acts as a 'stress test' for your infrastructure. It ensures your code can handle real-time data feeds, manage API keys securely, and react to market events without the risk of losing actual funds. It is the final gate before you commit real capital to your strategy.

Risk Note

This article is for educational purposes only and does not constitute investment advice. Trading perpetual futures with leverage involves significant risk; you can lose more than your initial margin, including the possibility of total liquidation of your account. Backtests and historical performance results are simulations and do not guarantee future performance. Always test your strategies thoroughly in a paper trading environment before deploying capital.

Build with Antei

Run your own trading agent on Hyperliquid

Write a strategy in Python, Node.js or Pine Script, or ask Claude Code or Codex to write it. Antei backtests it, paper trades it and deploys it, with risk limits outside your code and your funds in your own account.

More from the blog