By Keel Research Team · Updated October 18, 2026
To backtest a trading strategy, write the rule down exactly, run it over historical prices from the market you will trade, and charge every fee, slippage and funding payment it would have paid. Then test it on data you did not use to build it, read the drawdown and the number of trades before the return, and paper trade it before you risk money. Keel runs each of these steps without code on real Hyperliquid data.
A backtest is only as honest as the way it was run. The same idea can look great or useless depending on whether you charged its costs, let it peek at prices it could not have known, or tuned it until it fit the past. These are the steps in the order to do them, each shown on one real strategy from Keel’s public library.
The strategy below is the golden cross idea from the library, run on daily bars across BTC, ETH, SOL, BNB, XRP, DOGE, HYPE and SUI: hold a coin while its fast moving average is above its slow one, and step aside when it drops below. Each block is one part of the rule, read top to bottom. The numbers are its backtest over Aug 2024 to Sep 2026, with fees, slippage and funding charged. Fork it to change the coins, the averages or the dates and run it again.
A backtest needs a rule with no judgement left in it. Write down exactly when you enter, when you exit, how much you put on and which markets you trade. If two people could read your rule and place different trades, it is not finished yet.
The example’s rule fits in one sentence: on each daily close, hold a coin long while its fast average is above its slow average, give every coin the same fixed share of the account, and never use more than the account itself. That is the whole strategy, and every block in the diagram above is one piece of that sentence.
On Keel you can describe a rule in plain English or build it from blocks, and Keel shows you the strategy it made so you can check it says what you meant before you run anything.
Test on prices from the market and venue you will actually trade. A rule tested on spot prices and run on perpetual futures meets funding payments it never saw. A rule tested on one exchange’s candles can behave differently on another exchange with different liquidity and fees.
Cover rising, falling and sideways markets, and include coins that did badly, not only the ones that are popular today. A list picked from today’s winners quietly leaves out the coins that collapsed, which makes any rule look better than it was.
The example runs on Hyperliquid perpetual futures, using Hyperliquid’s own price and funding history. If that is where you trade, see backtesting on Hyperliquid for what the data covers.
Leaving out costs is the most common way a backtest lies. Every trade pays a fee and some slippage between the price you saw and the price you got. On perpetual futures an open position also pays or receives funding every hour, and on a long position held through a strong market that adds up.
The example shows the size of it. With every cost charged its Sharpe ratio is 1.05. Run the same trades without funding and it reads 1.24. The trades did not change; only the funding bill did. A trend strategy that holds longs while longs are crowded pays for it, and a backtest that skips funding hides that.
Keel charges fees and slippage on every fill and funding on every open position, in backtests and in paper trading, so the number you read is already after costs.
Look-ahead bias is using information the rule could not have had at the time. The classic case is deciding to buy on a bar’s close and getting filled at that bar’s open. The subtle cases are worse because nothing errors: a daily value lined up against the wrong hour, or a rolling average that includes the bar being traded.
The check is simple to state: for every trade, ask what the rule knew at that moment and whether the price it traded at was still available. If a backtest looks too smooth, look for look-ahead first. How Keel works shows one of these timing bugs making a strategy look better than it is, with no error raised.
Keel strategies are written in a typed language where that kind of timing mistake can’t be expressed: a slower value reaches a faster bar only as its most recent completed value. Orders fill at the close of the bar the strategy runs on.
Overfitting is tuning a rule until it fits the past instead of the market. Every setting you add and every value you try gives the backtest another chance to find luck. Run enough versions and one will look excellent by chance alone.
Keel’s library ran the example with 8 different settings. The best of them scored a Sharpe of 1.44, but the default you see above scores 1.05. The library keeps the rule’s reference settings as the default and labels the best one separately, because picking the best of many is exactly how overfitting starts.
Prefer rules with few settings, and settings that work across a range of values rather than at one exact number. If moving a setting a little changes the result a lot, you found a lucky spot, not an edge. Read more in overfitting in backtests, and measure it with the overfit check, the probability of backtest overfitting and the deflated Sharpe ratio. The strategy robustness test page puts these checks in order.
Split your history. Build and tune the rule on the first part, then run it once, unchanged, on the part you held back. If it falls apart on the held-back data, the first result was mostly fitting. If it holds up, you have real evidence.
Walk-forward testing repeats that split through time: tune on a window, test on the next, move forward and do it again. It takes longer and gives a much more honest picture. Walk-forward testing explains how to run the steps, walk-forward optimization covers tuning inside each window, and out-of-sample testing compares the ways to split.
On Keel you set the dates of each backtest, change a setting and run it again, and every backtest is kept, so a held-back period is a second run with different dates.
Read the worst case before the best case. Start with the drawdown: the deepest fall from a high, which is what holding the strategy actually feels like. The example’s worst drawdown was −30.4%. Ask whether you would have kept running it through that. The max drawdown calculator shows what a drawdown means in money.
Then the number of trades. The example made 54 trades. The library flags that as a small sample, so treat the Sharpe as rough. A result built on a few trades can be one good month in disguise.
Then the Sharpe ratio, the return per unit of risk, and only then the total return, which was +131% here. Finally look at the equity curve itself: a steady climb and a curve made of one big jump can end at the same return and be very different strategies to hold. The example’s library page shows the full curve, monthly returns and each coin’s result.
A backtest only replays the past. Paper trading runs the strategy forward on live prices with simulated money, so it meets markets it has never seen, and you watch how it behaves bar by bar before any money is at risk. It is the last check that the strategy does what the backtest said it would.
On Keel, paper trading runs on live Hyperliquid prices with real fees and funding, and you need no wallet. The same strategy that you backtested is the one that paper trades and, when you are ready, runs live from your own Hyperliquid account. See backtesting vs paper trading for what each one tells you.
Keel is a strategy builder for Hyperliquid. Start from a library strategy or describe your own, backtest it with every cost charged, and paper trade it on live prices. The free plan includes backtests and paper trading.
Browse backtested strategies to see common indicator rules tested across coins, including the golden cross, or read how Keel works for the engine behind the numbers. For a list of every check before you go live, see the robustness checklist.
Keel is a strategy builder for Hyperliquid. Describe an idea, backtest it with fees, slippage and funding, and run it live on Hyperliquid’s crypto perps. Stock and index perps are coming soon.
Start free. Connect a Hyperliquid wallet when you’re ready to trade.
Backtesting runs a trading rule over past prices and records what it would have done: every entry, exit, fee and funding payment, and the account value that results. It tells you how the rule behaved in the past, not what it will do next. Its main use is to throw out ideas that would have lost money, cheaply, before they cost real money.
Enough that the result does not rest on a handful of trades, and enough to include rising, falling and sideways markets. A rule that only ever traded a bull run has not been tested on the market that hurts it. If the history is short, test the same rule on more coins rather than squeezing more out of one chart.
Yes. You can do it in a spreadsheet or in Python with free price data, as long as you add fees, slippage and funding yourself. Keel's free plan includes backtests and paper trading on Hyperliquid data, with costs already charged, and you can start from a library strategy instead of a blank page.
Yes. On Keel you describe the rule in plain English or build it from blocks, and Keel turns it into a strategy you can read and backtest. You can also fork a strategy from the public library, change a setting and run it again. Every backtest is kept, so you can compare versions.
A backtest replays the past in seconds. Paper trading runs the strategy forward on live prices with simulated money, so it meets markets the rule has never seen and shows you how it behaves bar by bar. Do the backtest first to filter ideas, then paper trade the ones that survive.
Usually for one of four reasons: the backtest left out costs, it used information that was not available at the time, its settings were tuned to fit the past, or the market changed. Charging every cost, checking the timing, testing out of sample and paper trading first catch most of it.