DEV Community: Bot LAB

Paper Trading Crypto Futures: How to Make It Honest

Bot LAB — Mon, 02 Nov 2026 04:06:22 +0000

Paper trading crypto futures means running a strategy or bot with simulated money on real market prices, so you can see how it behaves before risking capital. It is worth doing, but only if the simulation includes fees, slippage, funding payments and liquidation rules. Without those, a paper result will usually look much better than the same strategy would look live.

This guide shows how to set up an honest futures paper test, what to measure, and how to judge the result without fooling yourself.

Why paper trading crypto futures is harder than spot

Spot paper trading is simple: you buy, hold, and sell. Perpetual futures ("perps") add four costs and risks that many paper engines skip or simplify:

Funding payments. Perps charge or pay funding at set intervals. A bot that holds positions for hours or days can pay a meaningful amount here.
Leverage and liquidation. A paper engine that never liquidates you will hide your worst outcomes.
Taker fees on both sides. Many bots use market orders. Fees are charged on the full position size, not on your margin.
Slippage. Simulated fills at the last price ignore the spread and the order book, especially on fast candles and small coins.

If your paper tool ignores any of these, treat its numbers as an upper bound, not an estimate.

Paper trading crypto futures: a setup checklist

Before you start a paper run, decide what it must model. A good futures paper test should:

Use the exchange's real fee schedule for your account tier, maker and taker separately.
Add slippage per side. Even a small assumption (for example 0.02–0.10% per side, depending on the coin and order size) is better than zero.
Apply funding at the real intervals using historical or live funding rates for that contract.
Calculate a liquidation price for every position from your leverage and the maintenance margin rule, and close the trade if price touches it.
Use candle data the bot could actually see. Signals must use closed candles only, or you get look-ahead bias. See how to detect look-ahead bias.
Log every trade: entry, exit, size, fee, funding, and the reason for exit.

Decide your success rules before you start

Write down, in advance:

How many trades you need before you judge the result (more on this below).
The maximum drawdown you would accept.
What would make you stop the test early.

Setting the rules after you see the results is one of the most common ways traders talk themselves into a weak strategy.

Worked example: the paper vs live trading gap

Illustration only. These are made-up numbers to show the arithmetic. They are not results from any real bot.

Imagine a bot that opens 100 trades on a perp. Each trade uses 1,000 USDT margin at 5x leverage, so each position is 5,000 USDT notional. A basic paper engine (no costs) reports an average gain of +0.30% of notional per trade.

| Item | Per trade | 100 trades | |---|---|---| | Gross paper result (+0.30% × 5,000) | +15.00 USDT | +1,500 USDT | | Taker fees, assumed 0.055% per side (0.11% round trip) | −5.50 USDT | −550 USDT | | Slippage, assumed 0.05% per side (0.10% round trip) | −5.00 USDT | −500 USDT | | Funding, assumed 2 intervals × 0.01% paid | −1.00 USDT | −100 USDT | | Net after costs | +3.50 USDT | +350 USDT |

In this illustration, costs remove about 77% of the gross result. A small change in assumptions (say, slippage of 0.08% per side instead of 0.05%) would turn the net result close to zero. That is the paper vs live trading gap in one table.

Two lessons follow:

Costs scale with notional, not margin. Leverage makes every fee and slippage figure bigger relative to your capital.
Thin edges are fragile. If a strategy only survives with optimistic cost assumptions, it probably will not survive live.

For more on how funding interacts with strategy rules, see do funding rate and open interest filters improve a crypto bot.

What to measure during a futures paper test

Win rate on its own tells you little. Track these together:

Number of trades. Small samples can look great by luck. Our guide on how many trades a backtest needs covers sample size in detail.
Average result per trade after costs, in R (multiples of the planned risk) or in % of notional.
Profit factor: gross wins divided by gross losses, after costs.
Maximum drawdown, measured from peak equity, including open-position losses.
Liquidations and near-liquidations. Even one liquidation in a paper test is a serious warning.
Funding share. What share of total costs came from funding? A high share means holding time matters more than you thought.
Market exposure. If the bot is long most of the time in a rising market, its result may just be market direction (beta), not skill.

Compare paper fills with real prices

If you can, sample some paper trades and compare the simulated fill with what the order book actually offered at that time. If paper fills are consistently better, raise your slippage assumption.

How long should you paper trade futures?

There is no fixed number of days. What matters is the number of trades and the variety of market conditions. A bot that trades twice a week needs months to show anything; a bot that trades ten times a day may reach a useful sample sooner, but it also pays far more in fees.

A practical approach:

Run until you reach your pre-set trade count.
Make sure the period includes at least one strong move and one choppy, sideways stretch.
Judge the result only after costs, and only against the rules you wrote down at the start.

How we judge paper results

At BOTLAB, a bot is only marked "ready for micro live" after it passes 6 statistical gates (G1–G6), defined on the site. Most bots do not pass: of 221 bots tracked, 1 currently has that status and 219 are marked not ready.

Even a bot that passes needs care. In our published paper trading results, mr4h/long recorded 138 trades over 78 days (16 Aug to 2 Nov 2026, simulated) with a 72.5% win rate and passed all 6 gates, and our verdict is still "sample too small to conclude". That is the standard we suggest for your own tests: a good-looking number is a reason to keep testing, not a reason to go live. You can see how results are tracked on the platform page, and recent notes in Lab News such as Fees first.

If you already have trade logs from your own bot, you can run them through our free tool, Check your bot, to see how the numbers look after a basic statistical check.

Common mistakes in futures paper trading

Testing at high leverage "because it's paper". Paper trading should match the leverage you would actually use, or the test means nothing.
Ignoring funding on long holds. Swing-style bots on perps can pay funding many times per trade.
Restarting the test after a bad week. Resetting erases the drawdowns you most need to see.
Changing parameters mid-test. Each change starts a new test. Keep a log of every version.
Treating paper as proof. Paper trading removes real execution, queue position and emotional pressure. Live results can be worse.

FAQ

Can I paper trade crypto futures for free?

Yes. Many exchanges offer a testnet or demo mode for perps, and several charting and research platforms offer simulated accounts. Check whether the tool models funding, fees, slippage and liquidation before trusting its numbers.

Can I paper trade crypto perps through an API?

Often, yes. Exchange testnets usually expose the same API as the live venue, which lets you test a bot's order logic end to end. Testnet prices and liquidity can differ from the live market, so compare fills against live data where possible. When you later connect any bot to a live account, use a trade-only API key with withdrawals off and IP restriction on.

Is TradingView paper trading good enough for futures bots?

It is useful for practising manual entries and checking signals on charts. For bot testing, check whether it charges funding and applies realistic fees and slippage. If it does not, add those costs yourself using a spreadsheet like the table above.

Does bot trading work if the paper test is positive?

A positive paper test is one piece of evidence, not proof. It needs enough trades, realistic costs, a period with mixed market conditions, and a result that does not depend on market direction alone. Many strategies that look good on paper fail live. See crypto trading bot backtesting: an honest how-to guide.

Key takeaways

Paper trading crypto futures is only meaningful if it models fees, slippage, funding and liquidation.
Costs scale with notional size, so leverage magnifies them.
Set trade count, drawdown limits and stop rules before you start.
Judge results after costs, on enough trades, across different market conditions.
A strong paper result means "keep testing", not "go live".

Not available in restricted jurisdictions (see the Service Agreement). You trade with your own exchange account; BOTLAB never holds funds.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Want these checks run on your own strategy? See the strategy and backtest audit.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.

Crypto Trading Bots That Work: How to Tell Honestly

Bot LAB — Fri, 30 Oct 2026 04:06:22 +0000

People searching for "crypto trading bots that work" usually want a name, but no bot "works" in general. A bot only works if it shows a measurable edge after fees and slippage, over enough trades, in conditions it did not see during design, and most bots fail that test. This guide shows you how to run that test yourself, so you can judge any bot, including one you built, bought or found online.

What "a crypto trading bot that works" actually means

A bot that works is not one with a nice screenshot or a high win rate. It is a bot whose results survive four questions:

Is there enough data? A few dozen trades can look brilliant by pure luck.
Does it survive real costs? Fees, slippage and funding payments eat small edges first.
Is it more than market beta? A long-only bot in a rising market can look clever while simply riding the trend.
Does it hold up forward? Results on data the bot was never tuned on matter far more than the backtest.

If a bot cannot answer all four with evidence, you do not know whether it works. That is a fine place to be. It means you keep testing instead of risking capital.

Step 1: Check the sample size before anything else

Small samples are the most common reason people think a bot works when it does not. With 30 trades, a strategy with zero edge can easily show a 60% win rate.

Practical rules of thumb:

Under 50 trades: treat results as anecdotes.
100–300 trades: you can start to see patterns, but confidence intervals are still wide.
Several hundred trades across different market regimes (trend, range, high volatility): now the numbers begin to mean something.

Days matter as well as trades. A bot that made 300 trades in one week has seen one market regime. For more detail, see How Many Trades Does a Backtest Need?.

Step 2: Put real costs into every result

Many bots that "work" in a backtest are simply ignoring costs. Add all of these:

Trading fees on both entry and exit (taker fees if the bot uses market orders).
Slippage: the gap between the price the bot wanted and the price it got. It grows in thin markets and fast moves.
Funding payments on perpetual futures, which can run for or against you every few hours.
Spread on less liquid pairs.

Scalping and high-frequency bots are hit hardest, because costs are paid on every trade while the edge per trade is tiny.

Worked example: why a 70% win rate can still lose

The numbers below are a made-up illustration, not BOTLAB results and not results of any real bot.

Imagine a bot with these backtest stats over 100 trades:

Win rate: 70%
Average win: +0.8%
Average loss: −1.6%

Before costs (simple sum, ignoring compounding):

Wins: 70 × 0.8% = +56%
Losses: 30 × 1.6% = −48%
Gross result: +8%

Now add realistic costs per round trip:

Fees: 0.11% (0.055% each side)
Slippage: 0.10% (0.05% each side)
Total: 0.21% per trade × 100 trades = −21%

Net result: +8% − 21% = −13%.

The high win rate hid a poor ratio of average win to average loss, and costs did the rest. This is why you should judge a bot on expectancy and profit factor after costs, not on win rate alone. See Profit Factor vs Win Rate for Trading Bots.

Step 3: Separate edge from market beta

If Bitcoin rose strongly during the test period, almost any long-biased bot looks good. Ask:

How did the bot do compared with simply holding the asset over the same period?
Did it trade both directions, or only long?
How did it behave in the falling and sideways parts of the test?

If returns track the market almost one-to-one, the bot is mostly giving you market exposure with extra fees. That is not an edge.

Step 4: Check for overfitting

A bot with many tunable parameters can be fitted to almost any history. Warning signs:

Results collapse when you change a parameter slightly (for example, a 20-period moving average works but 18 and 22 do not).
The developer tested hundreds of variants and shows you only the best one.
Performance is concentrated in a few huge trades.

Tools that help: walk-forward testing, out-of-sample periods, and statistics that adjust for how many variants were tried, such as the deflated Sharpe ratio.

Step 5: Close the paper vs live trading gap

A backtest is a model. Paper trading on live candles is the next step, because it exposes problems a backtest hides: missed fills, late signals, API errors and data gaps. Paper trading uses simulated money at real prices, so it is still not live, but it is a much more honest filter than a backtest.

When you finally compare paper and live, expect live to be somewhat worse. The size of that gap tells you how realistic your cost assumptions were.

Step 6: Look at drawdown, not just return

Before trusting any bot, find:

Maximum drawdown: the largest peak-to-trough fall in equity.
Drawdown duration: how long it took to recover.
Worst losing streak: how many losses in a row.

Then ask whether you could sit through that without switching the bot off at the worst moment. A strategy you abandon mid-drawdown does not work for you, whatever the backtest says.

Crypto trading bots that work: red flags to avoid

Walk away, or at least dig much deeper, if you see:

Promises of fixed monthly returns or "guaranteed" profit.
Results with no trade count, no dates and no costs.
Only screenshots, no exportable trade log.
Pressure to deposit funds with the bot provider rather than using your own exchange account.
Requests for API keys with withdrawal permission. A bot needs trade-only keys, with withdrawals off and IP restriction on.

What honest results look like in practice

At BOTLAB, a bot is only labelled "ready for micro live" after passing all 6 statistical gates (G1–G6), defined on the site. Most bots do not pass.

As of 30/10/2026, BOTLAB tracks 212 bots in paper trading (simulated money, real prices): 1 is marked ready for micro live and 211 are not ready. The one that passed, mr4h/long, has 124 paper trades over 74 days (16/08/2026 to 29/10/2026) with a 71.0% win rate, and our own verdict is still "sample too small to conclude". Three Atlas trend bots, with 224–359 paper trades each over 78 days (08/08/2026 to 25/10/2026), passed only 2 of 6 gates, with the verdict "market beta, no proven edge". Publishing the losers is part of the method; see Day one: read the losers too.

That ratio is the honest answer to the search: bots that clearly work are rare, and even a bot that passes every test still needs forward data. You can read more about how bots are tested and monitored on the platform page. Not available in restricted jurisdictions (see the Service Agreement). You trade with your own exchange account; BOTLAB never holds funds.

If you have your own bot's trade history, you can run a first sanity check with the free tool: Check your bot.

A quick checklist you can use today

At least a few hundred trades across more than one market regime?
Fees, slippage and funding included?
Compared with simply holding the asset?
Tested out of sample or walk-forward?
Paper traded on live candles before any real money?
Max drawdown you could actually live with?
Trade-only API key, withdrawals off?

If any answer is "no" or "I don't know", the bot has not yet shown that it works.

FAQ

Are crypto trading bots worth it?

They can be useful for executing rules consistently and testing ideas, but that is different from being profitable. Whether one is worth it depends on evidence: trade count, costs, drawdown and forward results. Without that, you are paying for automation, not an edge. See also Is a Trading Bot Profitable?.

Trading bot vs human: who actually wins?

Neither wins by default. Bots are faster and do not panic, but they follow rules blindly when market conditions change. Humans adapt but break their own rules. The fair comparison is the same strategy, the same costs and the same period, judged on risk-adjusted results.

Is paper trading crypto useful before going live?

Yes. Paper trading on live prices catches execution problems, signal delays and unrealistic cost assumptions that backtests miss. It does not include real slippage or emotional pressure, so treat it as a filter, not proof.

What is a realistic trading bot success rate?

There is no fixed figure. A win rate means little without the average win, average loss and costs. Read Trading Bot Success Rate: What the Number Really Means for how to interpret it.

Key takeaways

No bot "works" in general; it either shows a tested edge after costs or it does not.
Check sample size, real costs, market beta and overfitting before trusting any result.
A high win rate can still lose money once fees and slippage are included.
Paper trade on live candles before risking capital, and expect live results to be worse.
Use trade-only API keys with withdrawals off, and avoid anyone promising fixed returns.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Want these checks run on your own strategy? See the strategy and backtest audit.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.

Solana Trading Bot: What to Backtest First

Bot LAB — Wed, 28 Oct 2026 04:06:22 +0000

Before you run a trading bot on Solana, backtest three things first: whether the strategy survives realistic fees, slippage and funding, whether it holds up across different volatility regimes, and whether it has enough trades to mean anything. A SOL bot that looks good on a clean chart often fails one of these tests, so check them before you spend time on settings.

Solana is getting a lot of attention today, and attention like this often draws new bot users. This guide does not predict where SOL goes next. It shows how to test a bot on a coin that is getting a lot of attention, so you can judge it on evidence instead of excitement.

Why Solana needs its own backtest

A strategy that worked on BTC will not automatically work on SOL. Three differences matter:

Higher volatility. Altcoins like SOL usually move more than BTC in percentage terms. Stops get hit more often, and leverage hurts faster.
Beta to BTC. SOL often moves with BTC, but more sharply. A bot that "wins" on SOL may simply be riding BTC's direction with extra risk on top. That is market beta, not an edge.
Attention spikes. When a coin trends, spreads, funding rates and order-book depth can change quickly. A backtest built on quiet weeks may not describe a busy one.

So treat a SOL bot as a new strategy, even if the logic was copied from a BTC bot.

Step 1: Price in every cost

Most bot backtests fail here. Gross results ignore what you actually pay.

Trading fees

Use your exchange's real taker and maker fees for USDT perpetuals, and count both entry and exit. If your bot uses market orders, assume taker fees on both sides.

Slippage

Your fill price is rarely the candle close. Model slippage as a percentage per side and make it pessimistic. Then rerun with double that slippage. If the result collapses, the edge was too thin to be real.

Funding

On perpetual futures, longs and shorts pay each other funding, usually every 8 hours. Funding can rise during trending periods. A bot that holds positions for days can lose a noticeable share of its gross result to funding alone. Use historical funding data for SOL perps, not a flat guess.

Step 2: Split the history into regimes

A single backtest number hides how the bot behaved in different market conditions. Cut your SOL history into periods and test each one separately:

Strong uptrend
Strong downtrend
Sideways and choppy
High-volatility spikes (days when SOL or BTC moved sharply)

A trend-following bot will often look good in the first two and bleed in the third. A mean-reversion bot is often the opposite. Neither is "bad", but you need to know which conditions the bot depends on.

Also compare the bot to simply holding SOL over the same period. If the bot only makes money when SOL rises, and loses when SOL falls, it may be giving you leveraged exposure to SOL rather than a strategy.

Step 3: Check the sample size

Twenty trades on a trending coin prove very little. Results from small samples swing wildly by chance. As a rough rule, you want enough trades across several regimes before drawing conclusions. We go deeper on this in How Many Trades Does a Backtest Need?.

If you tested many parameter combinations to find the "best" one, the best result is inflated by luck. The Deflated Sharpe Ratio is one way to adjust for this.

Step 4: Rule out backtest errors

Before trusting any number, check for:

Look-ahead bias: the bot uses information it could not have known at the time (for example, a candle's close before it closed). See How to Detect Look-Ahead Bias in Your Own Backtest.
Survivorship bias: testing only on coins that are popular today. SOL is trending now; that tells you nothing about how the bot would have picked coins in the past.
Unrealistic fills: limit orders assumed to fill whenever price touches them.

Worked example: how costs change a SOL bot

Illustration only. These are made-up numbers to show the arithmetic. They are not BOTLAB results and not a forecast for SOL.

Imagine a SOL perpetual bot with this backtest:

80 trades
Average gross result: +0.35% per trade (on position size)
Average holding time: 16 hours

Now add costs per round trip:

| Cost | Per trade | |---|---| | Fees (0.055% taker × 2 sides) | 0.11% | | Slippage (0.05% × 2 sides) | 0.10% | | Funding (0.01% per 8h × 2 periods, if paying) | 0.02% | | Total cost | 0.23% |

Net result per trade: 0.35% − 0.23% = +0.12%. Costs took about two thirds of the gross result.

Now stress-test it. During a busy, trending week, assume slippage doubles to 0.10% per side (0.20% per trade) and funding doubles to 0.04%:

Total cost: 0.11% + 0.20% + 0.04% = 0.35%
Net result per trade: 0.35% − 0.35% = 0.00%

The same bot is now flat before any bad luck. If a modest cost increase wipes out the edge, the edge is too thin to rely on.

What leverage does to this

At x10 leverage, a 10% move against your position is roughly a full loss of the margin on that trade, before fees. Large single-day moves are common in altcoins. Any leverage setting should be tested in the backtest against the worst historical moves, not the average ones.

Step 5: Paper trade forward before anything else

A backtest is a story about the past. Paper trading (simulated money, real live prices) tests the bot on data it has never seen, with real-time spreads and timing.

Run the SOL bot in paper mode for enough trades to cover at least a couple of different market conditions. Compare the paper results with the backtest:

Is the win rate similar?
Is the average trade close to the backtest after costs?
Are drawdowns deeper than the backtest suggested?

A large gap between backtest and paper results usually means the backtest was too optimistic.

How we judge bots at BOTLAB

We hold every bot to 6 statistical gates (G1–G6), defined on the site, and a bot is only marked "ready for micro live" after passing all six. Out of 209 bots tracked, 1 currently has that status and 208 are not ready. For example, our bot mr4h/long passed 6 of 6 gates in paper trading (simulated) from 16 Aug to 28 Oct 2026, with 121 trades and a 70.2% win rate, and our verdict is still "sample too small to conclude". Three Atlas trend bots, with 224 to 359 trades each in paper trading (simulated) from 8 Aug to 25 Oct 2026, were judged "market beta, no proven edge". We publish the bots that fail our gates as well as the ones that pass. You can see how the tools fit together on the platform page. All paper results are simulated.

If you already have a bot's trade history, you can run it through our free tool: Check your bot.

FAQ

Is a Solana trading bot profitable?

There is no general answer. Some strategies have made money on SOL in some periods and lost in others. The only honest way to judge a specific bot is a cost-aware backtest across several regimes, followed by forward paper trading. Even then, past results do not predict future results.

Should I use the same settings on SOL as on BTC?

Not without testing. SOL usually moves more than BTC, so stop distances, position size and leverage that suit BTC can be too tight or too risky on SOL. Backtest SOL separately.

Do BTC moves matter for a SOL bot?

They can. SOL often moves with BTC, so a bot's SOL results may partly reflect BTC's direction. Test how your bot did on days when BTC moved strongly in each direction, and check whether the bot adds anything beyond simply holding SOL.

How long should I paper trade a SOL bot?

Long enough to collect a meaningful number of trades across more than one market condition. A single trending week is not enough, because quiet and choppy periods often behave very differently.

Key takeaways

Test fees, slippage and funding first, then stress-test them at double the cost.
Split SOL history into trend, chop and spike regimes; know which ones your bot needs.
Compare the bot with simply holding SOL to separate edge from beta.
Small samples and heavy parameter searches inflate results.
Paper trade forward before trusting any backtest.
Crypto trading can lose money, including all capital.

Not available in restricted jurisdictions (see the Service Agreement). You trade with your own exchange account; BOTLAB never holds funds.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Want these checks run on your own strategy? See the strategy and backtest audit.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.

Grid Trading Bot Backtest: How to Test One Honestly

Bot LAB — Mon, 26 Oct 2026 04:06:21 +0000

A grid trading bot backtest is only useful if it models how grid orders actually fill, charges every fee and funding payment, and includes the moment price leaves your range. Most grid backtests look smooth because they skip at least one of those, so the honest test is less about the profit line and more about what happens at the edges.

This guide shows how to backtest a grid bot properly, where grid backtests usually lie, and how to read the result before you risk real money.

What a grid trading bot backtest has to prove

A grid bot places buy orders below the current price and sell orders above it, at fixed spacing. Each time price drops to a buy level and then rises back to the next sell level, the bot completes a "round trip" and books a small gain.

That design makes two promises your backtest must check:

In a range: many small round trips add up to more than fees.
Out of a range: the losses from holding inventory while price trends away do not erase everything the range earned.

A backtest that only shows the first part is half a test. Grid bots tend to look excellent in sideways data and fail in trending data, so the question is never "did it make money in this window?" but "what did it do in the windows it was not designed for?"

How to run a grid trading bot backtest step by step

1. Use data fine enough to see the fills

Grid levels are often 0.5–2% apart. On 1-hour or 4-hour candles, price can touch several levels inside one bar, and you cannot know the order in which it touched them.

If a single candle's high and low cross both a buy level and the sell level above it, a naive backtest books a full round trip. In reality the order may have been sell-first, or only one side filled.
Use 1-minute candles or trade data where you can. If you only have coarse candles, adopt a conservative rule: at most one fill per level per bar, and never a buy and its matching sell in the same bar.

2. Define a realistic fill rule

A limit order "touched" is not a limit order "filled". There is a queue in front of you.

Count a buy as filled only if price trades through the level (for example, one tick below), not just to it.
Run the test twice: once with touch-fills and once with trade-through fills. If the result collapses under the stricter rule, the edge was in the fill assumption, not the strategy.

3. Charge every cost

Grid bots trade a lot for small gains, so costs decide the outcome.

Fees: use your real maker and taker rates, both sides of every round trip. If some of your orders end up as taker (re-entries, stop-outs, market rebalances), charge taker for those.
Slippage: small on limit fills, real on any market order, especially exits during fast moves.
Funding: if you run a grid on perpetual futures, inventory held across funding times pays or receives funding. In a long trend against you, this adds up quietly. Include it from historical funding data, not an average guess.

4. Pick the range without peeking

This is the most common hidden bias in grid backtests. If you look at a chart, see that price stayed between two levels for three months, and then set your grid to exactly that range, you have used future information. Of course it worked: you drew the box around the answer.

Instead, set the range with a rule that only uses past data at the time, for example "range = last 30 days' high and low, recalculated weekly". Our guide on detecting look-ahead bias covers more ways this sneaks in.

5. Decide what happens at the edges

Your backtest must include an explicit rule for when price leaves the grid:

Stop the bot and close inventory at a loss?
Hold inventory and wait?
Shift the grid to follow price?

Each choice gives a very different equity curve. Whatever you choose, test it as part of the strategy, not as an afterthought.

6. Cover more than one market regime

Include at least one strong uptrend, one strong downtrend and one sideways period. A single calm month is a sample of one regime, as we put it in One sunny week isn't a climate.

Worked example: why the edges matter

Illustration only. These are made-up round numbers to show the arithmetic. They are not BOTLAB results and not a forecast.

Imagine a spot grid on a coin priced at 100 USDT:

Range 90 to 110, levels every 2 USDT (about 2% apart).
1,000 USDT split into 10 orders of 100 USDT each.
Fee 0.1% per side.

Inside the range. One round trip on a 100 USDT order with a 2-point gap earns about 2 USDT gross. Fees on both sides cost about 0.20 USDT. Net is about 1.80 USDT. If the backtest shows 40 round trips in a month, that is roughly 72 USDT net.

Then price breaks down to 80. Five buy orders filled on the way down, at 98, 96, 94, 92 and 90. At a price of 80, each is now worth less:

| Buy price | Loss at 80 (per 100 USDT order) | |---|---| | 98 | about 18.4 USDT | | 96 | about 16.7 USDT | | 94 | about 14.9 USDT | | 92 | about 13.0 USDT | | 90 | about 11.1 USDT | | Total | about 74 USDT |

One move of 20% wipes out the whole month of round trips, before any slippage on an exit. If this were a leveraged futures grid, the same move could hit liquidation and add funding costs.

The lesson: a grid backtest that ends while price is still inside the range is showing you the 72 USDT and hiding the 74.

How to read the results honestly

Trade count overstates your sample

A grid bot can log hundreds of round trips in a few weeks. That looks like a big sample, but those trades are highly correlated: they all depend on the same thing, price staying in the range. Three hundred round trips inside one sideways month are closer to one observation of "sideways market" than to 300 independent tests. See how many trades a backtest needs for why the number of independent outcomes matters.

Win rate will look high, and mean little

Grid bots close winners often and hold losers as open inventory. A 90% win rate on closed trades can sit next to a large unrealised loss. Always judge on:

Equity including open positions, marked to market every bar.
Maximum drawdown, including unrealised losses.
Profit after all costs, divided by the worst drawdown.

Check for overfitting

If you tested 50 combinations of range width, grid count and spacing, then the best one will look good partly by luck. Signs of overfitting:

Results change sharply when you move spacing slightly (say 1.8% vs 2.0%).
The best settings differ a lot between one year and the next.
Performance depends on one or two big trending bars landing at the right moment.

Use walk-forward testing: choose settings on one period, then test them unchanged on the next. Our honest backtesting guide walks through the process.

Then forward test on paper

A backtest is a hypothesis. The next step is paper trading on live prices for long enough to see a range break, then comparing paper fills with what the backtest predicted. The gap between them, from fills, latency and fees, is information you cannot get from historical data.

How we judge bots at BOTLAB

We run every bot through 6 statistical gates (G1–G6), defined on the site, and publish paper trading (simulated money, real prices) results, losers included. Of 204 bots tracked as of 26 Oct 2026, 202 are NOT_READY. One, mr4h/long, has passed all 6 gates with 110 paper trades between 16 Aug and 26 Oct 2026, and even there our verdict is "sample too small to conclude". That is the standard we suggest for any grid bot: passing tests is a reason to keep watching, not proof of an edge.

If you already have a bot's trade log, you can run it through our free tool: Check your bot. Details of the hosted software and plans are on /platform.

FAQ

Is a grid trading bot profitable?

It can make money in ranging markets and lose money in trending ones, and nobody can know in advance which regime is coming. A backtest can tell you how the bot behaved in past regimes after costs. It cannot tell you future results. Our article on whether a trading bot is profitable explains how to test that question.

Can I backtest a grid bot for free?

Yes. You can use free historical candle data and a spreadsheet or open-source backtesting library, as long as you apply strict fill rules and real fees. Free paper trading on live prices is a good second step before any real money.

What is the best grid trading bot strategy?

There is no single best setting. A useful grid strategy is one whose range rule, spacing and exit rule survive walk-forward testing across several regimes, with acceptable drawdown when price leaves the range. Be cautious of any setting that only works on one period.

Should a grid bot use spot or futures?

Futures add leverage, funding costs and liquidation risk, which a backtest must model explicitly. Spot grids avoid liquidation but still carry inventory risk when price trends down. This is a general description, not a recommendation for your situation.

Key takeaways

A grid trading bot backtest must model fills, fees, slippage and funding, or it will overstate results.
Set the range with a rule that only uses past data; drawing the range on a chart is look-ahead bias.
Always test what happens when price leaves the range; that is where grid losses come from.
Hundreds of grid trades in one regime are not a large independent sample.
Judge on equity including open positions and max drawdown, then forward test on paper.

Not available in restricted jurisdictions (see the Service Agreement). You trade with your own exchange account; BOTLAB never holds funds.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Want these checks run on your own strategy? See the strategy and backtest audit.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.

Crypto Trading Bot Backtesting: An Honest How-To Guide

Bot LAB — Fri, 23 Oct 2026 04:06:21 +0000

Crypto trading bot backtesting means running a bot's rules over past market data to see how it would have traded, before you risk any money. Done honestly, it does not tell you whether a bot will make money. It tells you whether a bot is worth testing further, and most bots fail that test.

This guide shows how to run a backtest that is hard to fool: realistic costs, enough trades, data the bot never saw, and a forward test on live prices.

What crypto trading bot backtesting can and cannot tell you

A backtest replays history. It can show:

How often the rules would have traded
How large the losing streaks and drawdowns could get
How sensitive results are to fees, slippage and funding
Whether the edge holds across different coins and time periods

It cannot show:

How the bot behaves in market conditions that never appeared in your data
Your real fills during fast moves or thin order books
Whether the edge was real or a pattern you found by trying many settings

A backtest is the first filter, not the final verdict.

Why most crypto bot backtests look better than reality

1. Costs are missing or too small

Many tools default to zero fees and perfect fills. On perpetual futures you pay a trading fee on every entry and exit, you lose some price to slippage, and you pay or receive funding every few hours while a position is open. A strategy that trades often can turn from positive to negative once these are included.

2. Overfitting

If you test 200 combinations of moving-average lengths and pick the best one, that "best" result is partly luck. The more variants you try, the better the top one looks by chance. The deflated Sharpe ratio is one way to correct for this; see Deflated Sharpe Ratio Explained.

3. Look-ahead bias

The bot uses information it would not have had at the time. A common example is acting on a candle's close while it is still forming. Our guide on how to detect look-ahead bias in your own backtest walks through the checks.

4. Too few trades

Twenty trades with a 70% win rate can easily be noise. You need enough trades for the result to be distinguishable from luck; see How Many Trades Does a Backtest Need?.

5. One market regime

A trend bot tested only during a strong rally will look excellent. That may be market beta (the coin went up), not skill. Always compare against simply holding the asset over the same period.

A step-by-step backtesting process

Step 1: Write the rules down before you test

State entry, exit, stop, position size and which coins and timeframes the bot trades. If you change the rules after seeing results, record every change. Each one counts as another attempt.

Step 2: Use clean, realistic data

Use the exchange's own candles for the instrument you will trade (spot vs perpetual prices differ).
Check for gaps, duplicate candles and exchange outages.
For perpetuals, include historical funding rates.

Step 3: Model costs pessimistically

Taker fee on both sides unless you are sure your orders rest as maker
Slippage per trade (larger for small-cap coins and fast moves)
Funding for every interval a position is held
If your account is funded in USDT, include any conversion or withdrawal costs you actually pay

If the strategy only works with costs set to zero, it does not work.

Step 4: Split your data

In-sample: where you design and tune the rules
Out-of-sample: a later period you do not touch until the rules are frozen
Walk-forward: repeat tune-then-test across rolling windows

If out-of-sample results collapse compared with in-sample, assume overfitting.

Step 5: Measure more than total return

Look at:

Number of trades and test period
Win rate together with average win and average loss (see Profit Factor vs Win Rate)
Maximum drawdown and the longest time spent under a previous peak
Result versus buy-and-hold over the same dates
Result per coin and per year, not only the total

Step 6: Stress test

Double your slippage estimate
Shift entries by one candle
Nudge each parameter by 10–20%
Remove the single best trade

A robust strategy degrades gradually. A fragile one falls apart.

Step 7: Forward test on paper

Run the frozen rules on live prices with simulated money. This is where the paper vs live trading gap starts to show: missed fills, latency, and conditions the backtest never saw. Only forward results should change your opinion of a bot.

Worked example: what costs do to a scalping bot

Illustration only. These are made-up numbers to show the arithmetic. They are not BOTLAB results and not a real bot.

A bot on a 5-minute chart shows this backtest with zero costs:

600 trades over 3 months
Average gross result per trade: +0.10% of position size

That looks like a steady edge. Now add realistic costs per round trip:

| Cost item | Per round trip | |---|---| | Taker fee, entry + exit (0.055% each) | 0.110% | | Slippage (0.015% each side) | 0.030% | | Average funding while held | 0.005% | | Total cost | 0.145% |

Net result per trade: 0.10% − 0.145% = −0.045%.

Across 600 trades, before compounding, that is roughly 600 × −0.045% = −27% of position size. The same rules that looked profitable now lose money. Nothing about the signal changed, only the honesty of the cost model.

The lesson: the more often a bot trades, the bigger its edge per trade must be to survive costs.

How we apply this in practice

BOTLAB uses 6 statistical gates (G1–G6), defined on the site, that a bot must pass before it is considered for anything beyond paper trading. Most bots do not pass.

Our published results include the losers. For example, in BOTLAB paper trading (simulated money, real prices), Atlas/donchian-20d made 353 trades between 2026-08-08 and 2026-10-23 with a 41.6% win rate, and our verdict was "market beta, no proven edge". In other words, it mostly followed the market rather than showing skill. We wrote it up in Graveyard story: Atlas/donchian-20d. Paper results are simulated, and past results do not predict future results.

If you already have a backtest or trade log, you can run it through the free Check your bot tool to see common warning signs, or read more about how the research platform works on /platform.

Common mistakes checklist

Before you trust a backtest, ask:

Are fees, slippage and funding all included?
Is there an out-of-sample or walk-forward period?
How many variants did I try before picking this one?
Are there enough trades to separate skill from luck?
Does it beat buy-and-hold over the same dates, after costs?
Does it survive small parameter changes?
Has it been forward tested on live prices?

If you answer "no" or "not sure" to several of these, the backtest is not evidence yet.

FAQ

Is there free trading bot backtesting software?

Yes. Many charting platforms and open-source libraries let you backtest for free. The tool matters less than the method: check that it lets you set fees, slippage and funding, and that you can hold back an out-of-sample period.

How do you backtest a grid trading bot?

Grid bots need a fill model at every grid level, fees on each small trade, and a test across trending periods, not only sideways ones. Grids often look smooth in ranges and then carry large losses when price breaks out of the range and keeps going. Include that scenario in your data.

Does bot trading work?

Some rule-based strategies have shown an edge for a while; many have not. A bot is a tool that executes rules. If the rules have no edge after costs, automation only loses money faster. Test honestly and expect most ideas to fail. Our guide Is a Trading Bot Profitable? How to Test One Honestly goes further.

Is a Python trading bot backtest more accurate?

Not automatically. Writing your own backtester gives control, but it also makes look-ahead bias and cost mistakes easier to introduce. Validate it against a few trades you can calculate by hand.

Key takeaways

Crypto trading bot backtesting is a filter, not a forecast.
Include fees, slippage and funding, pessimistically.
Count every variant you tried; overfitting grows with each one.
Use out-of-sample data, walk-forward tests and stress tests.
Compare against buy-and-hold to separate edge from market beta.
Only forward paper results on live prices should change your view of a bot.

Not available in restricted jurisdictions (see the Service Agreement). You trade with your own exchange account; BOTLAB never holds funds.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.

Chainlink Trading Bot: What to Backtest First

Bot LAB — Wed, 21 Oct 2026 04:06:22 +0000

Before you run a trading bot on Chainlink (LINK), backtest three things first: whether the strategy survives realistic fees, slippage and funding costs, whether it has enough trades to mean anything, and how deep its worst drawdown gets. A coin being in the news changes how many people watch it. It does not change how you should test a bot.

Chainlink is on today's trending list, and attention brings a familiar urge: point a bot at the hot coin and see what happens. This guide shows what to check before any bot gets near a real account. It says nothing about where LINK's price is heading, because a testing guide can't tell you that and shouldn't try.

Why a trending coin needs more testing, not less

When a coin trends, three things often change at once:

Volatility can change. A backtest built on calm months may not reflect a busier market, or the other way round.
Liquidity conditions shift. Spreads and order book depth on altcoin pairs can move a lot from one week to the next.
Your own bias grows. If you already expect a move, you are more likely to accept a backtest that agrees with you.

The rule is simple. Test the strategy as if the coin were boring. If the logic only works because of recent excitement, you have learned about the news, not about your bot.

Step 1: Put real costs into the backtest

Most altcoin bots that look good on paper fail here first. A backtest without costs is a sketch, not a test.

Fees

Count the fee on every entry and every exit. Use taker fees unless you have proof your orders fill as maker. Market and stop orders are usually taker.

Slippage

Slippage is the gap between the price your backtest assumed and the price you would actually get. On a mid-cap pair it is often larger than on BTC or ETH, and it tends to be worst exactly when the bot wants to trade: on fast candles and breakouts.

A practical check: rerun the backtest at 2x and 3x your slippage estimate. If the result flips from positive to negative, the edge is too thin to trust.

Funding cost on perpetuals

If the bot trades perpetual futures, it pays or receives funding while positions are open. Bots that hold for hours or days can lose a meaningful share of their gross result to funding. Model it from historical funding data rather than assuming zero. For more on funding-based filters, see Do Funding Rate and Open Interest Filters Improve a Crypto Bot?.

Worked example: a LINK bot before and after costs

The numbers below are a made-up illustration to show the method. They are not BOTLAB results and not results of any real bot.

Imagine a short-term LINK perpetual strategy with this backtest:

140 trades over 60 days
Average gross result per trade: +0.14%
Win rate: 58%

That looks fine. Now add costs, per round trip:

Taker fee 0.055% on entry plus 0.055% on exit = 0.11%
Estimated slippage, both sides = 0.04%
Average funding paid while holding = 0.01%

Total cost per trade = 0.11% + 0.04% + 0.01% = 0.16%.

Net result per trade = 0.14% − 0.16% = −0.02%.

The win rate did not change, but the strategy went from "working" to slowly losing. This is why win rate alone tells you little; see Profit Factor vs Win Rate for Trading Bots. Leverage does not fix this. It multiplies both the gross result and the losses, and it brings liquidation risk closer.

Step 2: Check the sample size

A backtest with 25 trades can look excellent by luck alone. Before you trust any LINK result, ask:

How many trades? Dozens are rarely enough. A few hundred, spread over different market conditions, tells you much more. Our guide How Many Trades Does a Backtest Need? goes into the details.
How many conditions? Did the test include trending, falling and sideways periods, or only one regime?
How concentrated is the result? If removing the best 3 trades erases the profit, the bot depends on rare events.

Step 3: Look for overfitting

Overfitting means the strategy learned the noise in past data instead of a repeatable pattern. Trending coins invite it, because it is tempting to tune parameters until the backtest catches the recent move perfectly.

Warning signs:

Many parameters for a small number of trades
Results that collapse when a setting changes slightly (say, a 20-period lookback works but 18 and 22 do not)
You tried dozens of variants and are reporting only the best one

Fixes:

Out-of-sample testing. Tune on one period, then test on data the strategy never saw.
Walk-forward testing. Repeat the tune-then-test cycle across rolling windows.
Adjust for the number of attempts. If you tested 50 variants, the best Sharpe ratio is inflated. The deflated Sharpe ratio corrects for this.
Check for look-ahead bias, where the backtest accidentally uses information that wasn't available at the time: How to Detect Look-Ahead Bias.

Step 4: Measure drawdown before you look at the total

Total result is the number people share. Maximum drawdown is the number that decides whether you can live with the bot.

What was the deepest peak-to-trough fall in the backtest?
How long did it take to recover?
What would that drawdown look like with the leverage you plan to use?

Expect live drawdowns to be deeper than backtest drawdowns. Set a drawdown alert in advance, a level where you pause the bot and investigate, rather than deciding in the middle of a losing streak.

Step 5: Paper trade forward and compare

A backtest replays history. A forward paper test (simulated money, live prices) shows how the bot behaves on candles it has never seen. Then compare:

Paper fills vs backtest assumptions
Trade frequency vs backtest frequency
Drawdown vs backtest drawdown

The paper vs live trading gap is real. Paper trading still doesn't capture every partial fill, rejected order or API delay, so treat even good paper results as a starting point, not a conclusion.

How we apply this at the lab

At BOTLAB, every bot is judged against 6 statistical gates (G1–G6), defined on the site, and we publish the losers alongside the rest. One example from our published paper trading (simulated) results: Atlas/donchian-20d made 347 trades from 2026-08-08 to 2026-10-18, with a 41.8% win rate, and our verdict was "market beta, no proven edge". That is a useful lesson in itself: plenty of trades and a long period still did not show an edge beyond following the market. The full story is in Graveyard story: Atlas/donchian-20d.

Before you trust a strategy, you can run it through our free tool: Check your bot. To see how hosted bots and paper results fit together, visit the platform page.

Not available in restricted jurisdictions (see the Service Agreement). You trade with your own exchange account; BOTLAB never holds funds.

A quick pre-launch checklist for any LINK bot

[ ] Fees modelled as taker on every entry and exit
[ ] Slippage stress-tested at 2x and 3x
[ ] Funding included for perpetual positions
[ ] Enough trades across more than one market regime
[ ] Out-of-sample or walk-forward test done
[ ] Number of variants tested written down
[ ] Max drawdown known, and a pause level set
[ ] Forward paper test compared with the backtest
[ ] API key set to trade-only, withdrawals off, IP-restricted

FAQ

Is a Chainlink trading bot different from a BTC bot?

The testing method is the same. Practical conditions often differ: altcoin pairs can have wider spreads, thinner order books and different funding behaviour, so cost assumptions that worked on BTC may be too optimistic for LINK. Test each pair with its own data.

Should I backtest only the recent trending period?

No. A test limited to a period when the coin was in the headlines tells you how the bot did in one unusual window. Include quiet and falling periods as well, then check that results hold out of sample.

Can a high win rate make up for trading costs?

Not by itself. As the illustration shows, a bot can win most of its trades and still lose money once fees, slippage and funding are counted. Look at net result per trade, profit factor and drawdown together.

How long should I paper trade before considering a live account?

There is no fixed number of days. What matters is enough forward trades across changing conditions to compare honestly with the backtest. If the paper results drift far from the backtest, find out why before going further.

Key takeaways

A coin trending does not make a strategy better; test it as if the coin were boring.
Model fees, slippage and funding first, since thin edges often disappear there.
Small samples and many tuned variants inflate results; use out-of-sample tests and adjust for the number of attempts.
Judge drawdown before total result, and set a pause level in advance.
Forward paper testing narrows the gap with live trading but doesn't close it.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.

Are Trading Bots Legit? How to Check One Honestly

Bot LAB — Mon, 19 Oct 2026 04:06:24 +0000

If you are asking "is trading bots legit?", the short answer is that trading bots are real software, but many of the claims made about them are not. A bot is only as legitimate as its evidence: verifiable trade history, honest costs, a large enough sample, and a setup that never gives anyone control of your funds.

This guide shows you how to separate a real, testable bot from marketing, using checks you can run yourself before risking any money.

Is trading bots legit? What the question really means

When people search "is trading bots legit", they usually mean one of three things:

Is the software real? Does it actually place trades, or is it a front for a deposit scheme?
Are the results real? Are the screenshots and win rates from actual trades, a backtest, or nowhere at all?
Is it safe? Can the bot or its seller take my money?

A bot can pass the first test and fail the other two. Plenty of genuine bots run exactly as coded and still lose money, because the strategy has no edge after fees. "Legit software" and "worth using" are different questions.

Red flags that a trading bot offer is not legit

Start by checking the offer itself. These are strong warning signs:

Promises of fixed returns. Markets do not pay a steady percentage every month. Any fixed-return claim is a reason to walk away.
"Risk-free" or "can't lose" language. Every leveraged crypto strategy can lose money, including all capital.
You must deposit funds with the seller. A legitimate bot connects to your own exchange account. If someone asks you to send them USDT to "run the bot", that is custody, not software.
Requests for sensitive credentials. No honest provider needs your password, 2FA codes, seed phrase, or an API key with withdrawal permission.
Only screenshots, no trade log. Screenshots are easy to edit and easy to cherry-pick.
Fake urgency or scarcity. "Only 3 spots left" or countdown timers are sales pressure, not evidence.
Testimonials you cannot verify. Anonymous success stories prove nothing.

If an offer shows two or more of these, you do not need to test the strategy. The offer has already failed.

How to judge whether a bot's results are real

If the offer looks clean, move on to the evidence. Here is a practical checklist.

1. Ask what kind of results you are looking at

There are three types, and they are not equal:

Backtest: the strategy run on past data. Useful, but easy to overfit.
Paper trading (forward test): simulated money on live prices, after the strategy was frozen. Better, because the future was unknown when the rules were set.
Live trading: real money, real fills, real slippage.

Many sellers blend these together. Ask directly: which numbers are backtest, which are forward paper, and which are live? There is often a gap between paper and live results caused by slippage, partial fills and latency.

2. Demand the full trade list

A legitimate track record includes every trade: entry, exit, size, fees and funding. Look for:

Number of trades. A handful of trades says almost nothing. See How Many Trades Does a Backtest Need? for practical thresholds.
Period covered. Two good weeks in a rising market is not a track record.
Losing trades. A history with no losers is either very short or edited.

3. Look past the win rate

A high win rate is the most common marketing number and one of the least useful. A bot that wins small and loses big can show 90% wins and still lose overall. Compare win rate with average win, average loss and profit factor. Our guide on Profit Factor vs Win Rate goes deeper.

4. Subtract real costs

Fees, slippage and perpetual funding payments add up fast, especially for bots that trade often. Ask whether the results include:

Exchange taker/maker fees on both sides
Realistic slippage, not mid-price fills
Funding paid or received on perpetual futures

5. Check for overfitting

If a strategy was tuned across hundreds of parameter combinations, the best one will look great by chance. Ask how many variations were tried. The Deflated Sharpe Ratio adjusts for exactly this problem.

6. Ask whether it is skill or just the market

In a rising market, almost any long-only bot looks good. A fair test compares the bot with simply holding the asset over the same period. If the bot only moves with the market, you are paying for exposure you could get more simply.

Worked example: a "90% win rate" bot

The numbers below are a made-up illustration, not real results from any bot.

A seller advertises a bot with a 90% win rate. You ask for the trade list and get 40 trades:

36 winning trades, average gain +1.0% each
4 losing trades, average loss −12.0% each
Round-trip fees of about 0.11% per trade

Now do the arithmetic (simple sums, to keep it clear):

Gains: 36 × 1.0% = +36.0%
Losses: 4 × 12.0% = −48.0%
Fees: 40 × 0.11% = −4.4%
Net: about −16.4%

The headline "90% win rate" is true. The bot still loses money in this illustration. And with only 40 trades, even a positive result would be too small a sample to draw firm conclusions. This is why the trade list matters more than the headline number.

How we apply this at a research lab

At BOTLAB, every bot has to pass 6 statistical gates (G1–G6), defined on the site, before it is labelled as ready for a small live test. Most ideas do not make it. We publish the failures too; see We show our receipts. Even ugly ones.

For example, in BOTLAB's published paper-trading (simulated) results, Atlas/supertrend-4h logged 298 trades between 2026-08-08 and 2026-10-18 with a 42.6% win rate. Its status is NOT_READY, with the verdict "market beta, no proven edge". In plain terms, its results so far look like market exposure rather than skill. That is the kind of honest verdict you should expect from any seller. You can see how results are tracked on the platform.

Is a trading bot safe to connect?

Even a legitimate bot needs safe setup. Follow these rules with any provider:

Use trade-only API keys. Turn withdrawals off.
Restrict the key by IP address if your exchange supports it.
Never share passwords, 2FA codes or seed phrases with anyone.
Keep funds on your own exchange account. The bot should place trades, not hold money.
Start in paper trading before using real funds, and compare paper results with what the seller claimed.
Check leverage settings. High leverage magnifies losses as well as gains, and can liquidate a position quickly.

If you want a quick first pass on a bot's numbers, try the free tool: Check your bot. It is a starting point, not a guarantee of anything.

FAQ

Is a trading bot real or a scam?

Both exist. Real bots are software that places trades through your exchange account using your API key. Scams usually ask you to deposit funds with them, promise fixed returns, or show only screenshots. Ask for the full trade list and never hand over custody of your money.

Is a trading bot reliable?

Reliability has two parts: does the software run without errors, and does the strategy hold up over time? A bot can be technically reliable and still lose money. Judge it on a large sample of forward-tested trades, with costs included, over different market conditions.

Is using a trading bot legal?

It depends on where you live and on the exchange's terms of service. Many exchanges allow automated trading through their official API. Check your local rules and your exchange's terms before you start. Never use workarounds to access a service that is not available in your country.

Are trading bots worth it?

Only if the evidence supports it after costs. For many people, the most useful step is paper trading first. It lets you see how a strategy behaves on live prices without risking capital. Read more in Is a Trading Bot Profitable? How to Test One Honestly.

Key takeaways

Trading bots are real software. Whether a specific bot or offer is legit depends on its evidence and its setup.
Walk away from fixed-return promises, "risk-free" claims, deposit requests and requests for sensitive credentials.
Demand the full trade list, a clear period, and a large number of trades.
Win rate alone means little. Check average loss, costs and overfitting.
Compare the bot with simply holding the market.
Use trade-only, IP-restricted API keys with withdrawals off, and paper trade first.

Not available in restricted jurisdictions (see the Service Agreement). You trade with your own exchange account; BOTLAB never holds funds.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.

Trading Bot Success Rate: What the Number Really Means

Bot LAB — Fri, 16 Oct 2026 04:06:22 +0000

A trading bot success rate, usually shown as the percentage of winning trades, tells you how often a bot wins, not whether it makes or loses money overall. To judge a bot honestly, you need its win rate together with average win and loss size, trading costs, number of trades and drawdown, ideally measured over a forward test rather than only a backtest.

This guide covers what "success rate" means, why high win rates can hide losing systems, and a simple process you can use to test any bot before trusting it with real capital.

What "trading bot success rate" actually measures

When a sales page says a bot has an "85% success rate," it almost always means:

Win rate: winning trades divided by total trades.
Sometimes it means something looser, like "85% of signals hit the first target," which ignores the trades that hit the stop.

Win rate on its own says nothing about:

How big the wins are compared to the losses.
Fees, spread, slippage and funding, which are charged on every trade, win or lose.
How many trades the figure is based on. 9 wins out of 10 trades is not the same evidence as 900 out of 1,000.
When it was measured: in a backtest, on paper, or live.

So the honest answer to "what is a good trading bot success rate?" is: there is no good win rate in isolation. A 40% win rate can be fine, and a 90% win rate can be a slow road to an empty account.

Why a high win rate can still lose money

The key idea is the break-even win rate. For any bot, you can calculate the win rate it needs just to break even:

Break-even win rate = average loss / (average win + average loss)

If a bot's average loss is much larger than its average win, it needs a very high win rate just to stay flat. Many grid, martingale and "small take-profit, wide stop" bots look like this. They win often and quietly, then give back weeks of gains in one bad move.

Expectancy is the number that matters

Expectancy is the average result per trade:

Expectancy = (win rate × average win) − (loss rate × average loss) − costs per trade

If expectancy is negative after costs, the win rate does not matter. For a deeper comparison of these metrics, see Profit Factor vs Win Rate for Trading Bots.

Worked example: two bots, two success rates

Illustration only. These numbers are made up to show the math. They are not results from any real bot.

Assume both bots pay 0.11% per round trip in fees and slippage.

Bot A: "75% success rate"

Win rate: 75%
Average win: +0.4%
Average loss: −1.5%
Expectancy before costs: (0.75 × 0.4) − (0.25 × 1.5) = 0.30 − 0.375 = −0.075% per trade
Expectancy after costs: −0.075 − 0.11 = −0.185% per trade
Break-even win rate: 1.5 / (0.4 + 1.5) ≈ 79%

Bot B: "40% success rate"

Win rate: 40%
Average win: +2.0%
Average loss: −0.9%
Expectancy before costs: (0.40 × 2.0) − (0.60 × 0.9) = 0.80 − 0.54 = +0.26% per trade
Expectancy after costs: 0.26 − 0.11 = +0.15% per trade
Break-even win rate: 0.9 / (2.0 + 0.9) ≈ 31%

Bot A has nearly double the success rate and still loses money in this illustration. Bot B loses more often than it wins, but its wins are large enough to cover the losses and costs.

Even Bot B's positive figure would not prove anything on its own. You would still need enough trades, a realistic cost model and a forward test.

How sample size changes the picture

A win rate is an estimate, and small samples are noisy.

Illustration only: a bot that shows a 70% win rate over 90 trades has a statistical uncertainty of roughly ±10 percentage points. Its "true" win rate could plausibly be anywhere from about 60% to 80%. That range can be the difference between a profitable system and a losing one, depending on the win/loss sizes.

Practical rules of thumb:

Under 30 trades: treat any win rate as anecdote.
30–100 trades: early signal only, wide error bars.
Several hundred trades across different market conditions: starting to mean something.

We go into this in detail in How Many Trades Does a Backtest Need?.

A real-world example from paper trading

At BOTLAB, every bot is checked against 6 statistical gates (G1–G6), defined on the site, and a bot is only labelled "ready for micro live" after passing all six. Out of 181 bots tracked, none currently meet that bar.

Here is how win rate compares with those verdicts in our published paper-trading (simulated) results:

mr4h/long: 69.7% win rate over 89 paper trades (2026-08-16 to 2026-10-16). Passes 5 of 6 gates. Status: WATCH. Verdict: sample too small to conclude.
Atlas/supertrend-4h: 43.0% win rate over 293 paper trades (2026-08-08 to 2026-10-15). Passes 4 of 6 gates. Status: NOT_READY. Verdict: market beta, no proven edge.
Atlas/live: 41.1% win rate over 382 paper trades (2026-08-08 to 2026-10-15). Passes 1 of 6 gates. Status: NOT_READY.

The bot with the highest win rate is still not considered proven, because 89 trades is not enough evidence. A strong-looking success rate earned a "watch," not a "go." You can see the full breakdown on the platform page. Paper results are simulated and do not predict future results.

How to judge a trading bot's success rate honestly

Use this checklist on any bot, whether you built it, bought it or are reading its sales page.

1. Ask for the full trade list, not a headline number

Total trades, period covered, and every win and loss.
If you only get a percentage and a screenshot, treat it as marketing.

2. Calculate expectancy and break-even win rate

Compare the actual win rate with the break-even win rate.
A bot whose win rate sits just above break-even has very little margin for error.

3. Add realistic costs

Exchange fees on both entry and exit.
Spread and slippage, especially on smaller coins and during volatile moves.
Funding payments on perpetual futures if positions are held across funding times.

High-frequency bots with small targets are the most sensitive to costs. A strategy that wins 0.2% per trade can turn negative from fees alone.

4. Check drawdown, not just wins

Max drawdown: the largest drop from peak equity.
Longest losing streak: can you sit through it without switching the bot off?
A high win rate with rare but large losses often shows up here first.

5. Separate backtest, paper and live results

Backtest: easy to overfit; look for look-ahead bias and too many parameter tweaks.
Paper trading (simulated money, real prices): a forward test on unseen data, but fills are idealised.
Live: real fills and real costs, but only meaningful after enough trades.

A success rate that drops sharply from backtest to paper is a classic overfitting sign. See Is a Trading Bot Profitable? How to Test One Honestly.

6. Check whether the bot just followed the market

If a bot only made money while the market went up, it may be "market beta": riding the trend rather than adding an edge. Compare its results with simply holding the asset over the same period.

If you want a quick structured check of these points, you can run your own numbers through Check your bot.

Red flags in success rate claims

"90%+ success rate" with no trade count or period.
Results shown only in a rising market.
Win rate quoted without average loss size.
No mention of fees, slippage or funding.
Screenshots instead of exportable trade history.
Any claim of guaranteed or fixed monthly returns.

FAQ

What is a good success rate for a trading bot?

There isn't a universal good number. A trend-following bot can work with a 35–45% win rate if its wins are much larger than its losses, while a scalping bot may need 70%+ just to cover costs. Compare the win rate with the bot's break-even win rate after costs.

Does bot trading work?

Some bots show a measurable edge for a period, and many do not. Bots can execute rules consistently, but they cannot remove market risk, and edges can disappear as conditions change. The only way to find out is to test with enough trades, realistic costs and a forward test.

Are trading bots legit?

The software itself is usually legitimate; the claims around it are where problems appear. Be careful with anyone asking for API keys with withdrawal permission, seed phrases or deposits into their wallet. A safe setup uses your own exchange account with a trade-only, IP-restricted API key and withdrawals disabled.

How do I backtest a trading bot's success rate?

Run the strategy on historical data with realistic fees and slippage, keep part of the data unseen for validation, and record every trade. Then forward-test on paper before risking capital. Watch for look-ahead bias and over-tuned parameters.

Key takeaways

Success rate usually means win rate, which alone does not show profitability.
Always compare win rate with the break-even win rate after costs.
Expectancy, drawdown and trade count matter more than the headline percentage.
Small samples produce noisy win rates; the highest win rate is not automatically the best bot.
Separate backtest, paper and live results, and treat big drops between them as a warning.

Crypto trading can lose money, including all capital. Not available in restricted jurisdictions (see the Service Agreement). You trade with your own exchange account; BOTLAB never holds funds.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.

How to Detect Look-Ahead Bias in Your Own Backtest

Bot LAB — Wed, 14 Oct 2026 04:06:23 +0000

Look-ahead bias is the failure where your backtest uses information that did not exist yet at the moment it made a decision. You detect it mechanically, not by reading your code: compute your indicator twice — once over the full price history the way a vectorised backtest does, and once bar by bar on history truncated at that bar the way a live bot sees it — then compare the two values at the same bar. If they differ anywhere, something in your pipeline peeked at the future. That is the whole method, and it takes about ten lines.

This matters because look-ahead is the one backtest failure that never announces itself. Overfitting at least leaves a trail: good in-sample, bad out-of-sample. A leak looks like skill in every period, including your out-of-sample window, because the leak travels with the data. Reading the code does not reliably catch it either — the leak is usually not in a line that says shift(-1). It is in a .mean() over a whole column, a resample that joins a daily close onto hourly bars, a center=True you typed six months ago, or a gap-filling call that borrows the next bar's price.

The test

python full = signal(df) # vectorised, whole file for i in sampled_bars: inc = signal(df.iloc[:i+1]) # only data up to and including bar i assert full[i] == inc[-1] # any difference = look-ahead

Two details make it honest. First, truncate at the bar, not at the row index of some already-merged frame — if your feature table was built by joining timeframes, rebuild the join inside the truncated call. Second, sample bars from across the whole history, not just the end; some leaks only fire where the data has gaps, or where a higher-timeframe boundary falls.

What it looks like on real data

We ran this on 3,000 closed BTCUSDT 1-hour candles from Bybit (2026-06-11 03:00 UTC to 2026-10-14 02:00 UTC), auditing 120 randomly sampled bars with lookahead_analysis from our MIT-licensed library. Each row is a signal written the way people actually write signals.

| Signal construction | Bars checked | Mismatches | Leaks? | |---|---|---|---| | EMA(20) over EMA(50) cross | 120 | 0 | no | | z-score vs trailing 200-bar mean/std | 120 | 0 | no | | close.shift(-1) > close | 120 | 64 | yes | | Daily close joined onto 1h bars, not shifted | 120 | 57 | yes | | rolling(21, center=True).mean() | 120 | 32 | yes | | Min-max normalised over the whole file | 120 | 31 | yes | | z-score vs full-sample mean/std | 120 | 4 | yes |

Three things are worth reading off that table.

The obvious bug (shift(-1)) and the subtle one (a daily close joined onto hourly bars without shifting it forward) are equally fatal: 64 and 57 bad bars out of 120. The second is far more common in real code, because resampling and merging feels like data plumbing rather than a modelling decision.

Normalisation is a leak. Min-max scaling over the whole file mismatched on 31 of 120 bars, because the minimum and maximum of a column are facts about the future. Anyone who has scaled features before splitting train and test has done this.

A leak can be small and still be a leak. The full-sample z-score mismatched only 4 times in 120 bars — the mean and standard deviation of four months of hourly closes barely move when you add one more bar. It is still disqualifying: the value at bar i depends on bars after i, so the number your backtest traded on is a number your bot cannot compute.

The boolean trap

Here is the result that changed how we run this check. We took the same series with every seventh bar deleted, filled the holes with bfill() — backward fill, which copies the next available price into the gap — and computed an EMA(20) over it.

| What we audited | Bars checked | Mismatches | |---|---|---| | The EMA value itself | 120 | 15 | | The boolean close > EMA built from it | 120 | 0 |

Same bug, same bars. Audit the final true/false signal and the test passes. Audit the number underneath and the leak is plainly there. A boolean is a lossy summary: a contaminated value has to cross a threshold before the comparison flips, so most of the corruption is invisible at the signal level — until a day when it is not. Audit every intermediate value you compute, not only the entry flag.

Multi-timeframe and warm-up

If your strategy reads a 4h or daily candle while deciding on a 1h bar, the rule is simple: every higher-timeframe row you touch must have closed by the close of the bar you are evaluating. A partial candle is legal only if you build it yourself from lower-timeframe candles that have closed. Most exchange APIs return the currently-forming candle as the first element of the response, so this bug gets written by accident constantly. Our own fetch helper drops any candle whose close time is in the future, and the audit then checks the surviving rows against the decision timestamp.

A related failure produces the same symptom — backtest results your bot cannot reproduce — without any future data at all. Long indicators depend on how much history you loaded. Computing EMA(200) on the real BTC series above with only 100 bars of warm-up, versus 1,000 bars, moved the value by a median of 0.48% and up to 2.18%. That sounds harmless until you look at the trend boolean it feeds: close > EMA(200) flipped on 25% of the bars we evaluated (n = 20 evaluation bars, so treat the exact percentage as indicative, not precise). With 300 bars of warm-up the drift fell to 0.07% median and nothing flipped. Your backtest loads years of history; your live bot usually loads whatever its first API call returned.

What a leak is worth

To put a size on it, we ran one trading rule twice on the same 3,000 bars, with the same exits (stop at max(ATR14, 0.6%), target 1.5x the stop, 25-bar time stop) and the same cost assumption (0.055% taker fee per side, charged in R). The only difference is the entry condition: the second run compares the next close to the current one.

| Entry condition | Trades | Mean R | Win rate | Total R | |---|---|---|---|---| | EMA(20)/EMA(50) cross (clean) | 24 | +0.044R | 50.0% | +1.1R | | Next close > current close (leak) | 232 | +0.240R | 57.8% | +55.6R |

One bar of hindsight turns a rule with no detectable edge into one that looks like a business. The trade counts differ — the leaky condition triggers far more often — so this is an illustration of magnitude, not a controlled comparison. The direction is the point: leaks do not nudge results, they manufacture them.

What this method does not prove

A clean look-ahead audit is a licence to keep testing, nothing more.

It does not prove your edge is real. It proves only that your numbers were computable at the time. Overfitting, too few trades, concentration in two coins and ignored costs are separate failures with separate tests. For scale: across the 128 strategy books we track, as of 2026-10-14, zero pass our six readiness gates — and almost all of them are look-ahead clean.
It only covers the code you hand it. If the leak lives in how your trade ledger was assembled, or in a cached feature file built earlier over the whole history, auditing the signal function will not see it.
It is a sampled test. We checked 120 bars, not 3,000. Zero mismatches means "no leak at those bars", which is strong evidence, not proof. Increase the sample when a result looks surprisingly good.
Your data vendor can leak. Prices revised after the fact, timestamps labelled with a candle's close instead of its open, or funding rates stamped at the start of a settlement period rather than the end, will all pass a self-consistency check and still be wrong.
Nothing here says anything about fills. A signal that was computable at 14:00 can still be impossible to fill at the price your backtest assumed.

What this means for your own bot

Write a signal(df) -> one value per bar function with no hidden state and no reads outside df. If you cannot, that is your first finding.
Run the full-versus-truncated comparison on at least 100 bars spread over your whole history. Any mismatch stops everything else until it is fixed.
Audit values, not booleans. Every indicator, every normalised feature, every merged higher-timeframe column — and the entry flag last.
Grep for the usual suspects as a second pass, never as the first: shift(-, center=True, bfill, backfill, .interpolate(), resample(...).last(), and any .mean(), .std(), .min() or .max() taken over a full column.
Drop unclosed candles at the source. Timestamp every input with the moment it became available, and compare that timestamp to the decision time rather than trusting row order.
Fix warm-up before comparing backtest to live. Load the same amount of history live as your backtest effectively used, and measure the sensitivity rather than assuming it is small.
Re-run the audit after every change to the feature pipeline. Leaks arrive with refactors, not with new ideas.

The Python implementation of all of the above — the full-versus-truncated audit, the warm-up sensitivity test, the multi-timeframe closed-candle check, plus the cost model and the statistical gates we use on our own books — is MIT-licensed at github.com/botlabtrade/botlab-oss. Install numpy and pandas, point it at your own data, and you get the same report we run on ours. If you would rather not install anything, there is a browser version of the checks at botlab.org.uk/#tool, which runs locally on a CSV of your trades.

This is educational material about testing methodology. Nothing here is financial advice, and no result above is a live trading record.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.

NEAR Protocol Trading Bot: What to Test First

Bot LAB — Wed, 14 Oct 2026 04:06:22 +0000

Before you point a trading bot at NEAR Protocol or any other coin that is trending right now, test four things first: real trading costs at today's spreads, a large enough sample of trades, how the strategy did on data it never saw, and how it behaves when the hype fades. A backtest that only looks good during a hot streak usually reflects the streak, not an edge.

This guide shows how to run those checks step by step. It does not say anything about where NEAR's price is going, and it won't. The goal is to judge the bot, not the coin.

Why trending coins are a trap for backtests

When a coin like NEAR Protocol, Injective or Optimism shows up on trending lists, three things usually change at once:

Volatility jumps. Bigger candles mean bigger wins and bigger losses per trade.
Volume and attention change quickly. Order books can look deep at one moment and thin the next.
The recent past is unusual. A bot tuned on the last few weeks is tuned to an unusual regime.

A strategy that "would have made money" on a trending coin may only be showing that the coin moved a lot in one direction. That is market beta, not skill. A simple buy-and-hold over the same window would often show the same thing.

Step 1: Count the trades before you look at returns

The first number to check is not profit. It is the trade count.

A trending window is often short, so a bot may only have taken 15–30 trades on it. With that few trades, one or two lucky outliers can create the whole result. We cover this in depth in How Many Trades Does a Backtest Need?. In short:

Under ~30 trades: treat any result as anecdotal.
30–100 trades: early signal at best, wide uncertainty.
Several hundred trades across different market conditions: now you can start comparing.

If the coin doesn't have enough history for a meaningful sample, test the same rules across several similar coins and pool the results. If the rules only work on one hot coin, that is a warning sign.

Step 2: Put realistic costs in first

Costs decide whether a strategy survives, especially on fast timeframes. During a trend spike, two costs rise:

Spread and slippage. Your fill price can be noticeably worse than the candle close your backtest assumed.
Funding (for perpetual futures). When a coin is crowded on one side, funding payments can become a real drag on positions held for hours or days.

Fees in USDT add up quickly on small accounts too. Always use your exchange's actual fee tier, and assume taker fees unless your bot genuinely posts limit orders that get filled. Our Lab News post Costs come first explains why we subtract costs before looking at anything else.

Step 3: Split the data and test out-of-sample

Never judge a bot on the same data used to choose its settings. A basic honest setup:

In-sample (e.g. first 60–70% of the data): pick parameters here.
Out-of-sample (the remaining 30–40%): run once, no tweaking.
Walk-forward (better): repeat the split on rolling windows, so every period gets tested on data the parameters never saw.

If performance collapses out-of-sample, the strategy was probably fitted to noise. The more parameter combinations you tried, the more likely the best one looks good by chance. That is what the Deflated Sharpe Ratio is designed to correct for.

Step 4: Check the regime, not just the total

Split results by market condition:

Trending up
Trending down
Sideways / choppy
High-volatility spikes (the "trending coin" moments)

A trend-following bot will often look great in a strong move and bleed slowly in sideways markets. A mean-reversion bot often does the opposite. Neither is wrong, but you need to know which one you have, and what happens to it when the trending phase ends.

Step 5: Look past win rate

A high win rate can hide a bad bot if the few losses are large. A low win rate can be fine if winners are much bigger than losers. Look at these together:

Profit factor (gross wins ÷ gross losses, after costs)
Average win vs average loss
Max drawdown and how long it took to recover
Longest losing streak

We compare the first two in Profit Factor vs Win Rate for Trading Bots.

Worked example (illustration only)

The numbers below are made up to show the method. They are not BOTLAB results and do not describe any real bot or coin.

Imagine a 1-hour breakout bot backtested on a trending altcoin over six weeks:

Trades: 60
Average gross result per trade: +0.60%

Now subtract realistic costs, assuming:

Fees: 0.06% per side → 0.12% round trip
Slippage during volatile hours: 0.15% per side → 0.30% round trip
Total cost per trade: 0.42%

Net per trade: 0.60% − 0.42% = +0.18%. Two-thirds of the apparent edge disappeared.

Next, split the trades by time:

First 40 trades (in-sample, during the strongest trend): +0.45% net per trade
Last 20 trades (out-of-sample, after the trend cooled): −0.36% net per trade

The "profitable" backtest was really one strong move. On data it hadn't seen, the bot lost money after costs. With only 20 out-of-sample trades, you can't even say confidently how bad it is. The honest conclusion: not proven, keep paper trading or drop it.

Step 6: Paper trade on live candles before any real money

A backtest replays the past. Paper trading (simulated money, real market prices) runs the bot forward on candles it has never seen, with no chance of hindsight leaking in. It also exposes practical problems a backtest misses: delayed signals, missed fills, API errors and funding at the moment it actually applies.

Our view is simple: every bot flies the simulator first. For a trending coin, paper trade long enough to see the trend end, not just while it's hot.

How we judge bots at BOTLAB

We run every bot through 6 statistical gates (G1–G6), defined on the site. A bot is only marked "ready for micro live" after passing all six.

Passing the gates isn't the same as being proven. Of the 159 BOTLAB bots tracked when the site was last built (2026-10-14), 1 is marked ready for micro live, 1 is on watch and 157 are not ready. The one that passed, mr4h/long, has 80 paper trades from 2026-08-16 to 2026-10-13 (58 days) with a 73.8% win rate, and our own verdict is still "sample too small to conclude." Another bot, Atlas/ichimoku-4h, passed 4 of 6 gates over 229 paper trades (2026-08-08 to 2026-10-13) and is flagged as a suspected overfit. Those are paper trading results, and they don't predict future results.

If you have your own bot's trade history, you can run it through the same kind of checks with the free tool: Check your bot.

A quick checklist before running a bot on a hot coin

[ ] At least several dozen trades, ideally hundreds across different conditions
[ ] Fees, slippage and funding included at realistic levels
[ ] Out-of-sample or walk-forward results reviewed, not just in-sample
[ ] Results split by regime (trend, chop, spike)
[ ] Profit factor, drawdown and losing streaks checked, not only win rate
[ ] Paper traded on live candles, including after the trend cooled
[ ] Exchange API key set to trade-only, withdrawals off, IP-restricted
[ ] You've decided in advance the maximum loss you can accept, including losing all of it

FAQ

Is it a good idea to run a trading bot on a trending coin like NEAR Protocol?

That depends on the bot, not the trend. A trending coin gives you a short, unusual sample with higher costs and sharper reversals. Test the rules out-of-sample and across several coins before trusting any result. This guide makes no prediction about NEAR or any other coin.

How long should I backtest a bot on a new trending coin?

Long enough to include more than one market regime and enough trades to be meaningful. If the coin's history is too short, test the same rules on similar coins with longer histories and pool the trades.

Why does my bot look profitable in the backtest but lose in paper trading?

The most common reasons are underestimated costs (especially slippage in volatile hours), parameters fitted to the in-sample period, and a regime change after the backtest window. Paper trading on live candles is designed to catch exactly this.

Does a high win rate mean the bot is safe?

No. A high win rate with occasional large losses can still lose money overall and produce deep drawdowns. Check profit factor, average loss size and max drawdown alongside win rate.

Key takeaways

Judge the bot, not the coin. Trending markets inflate backtests.
Count trades first; small samples prove very little.
Subtract fees, slippage and funding before reading any result.
Only out-of-sample and forward (paper) results count as evidence.
Even a bot that passes every gate can still have too small a sample to conclude anything.
Use trade-only API keys with withdrawals off, and never risk money you can't afford to lose.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.

Deflated Sharpe Ratio Explained: Why Your Backtest Looks Better Than It Is

Bot LAB — Mon, 12 Oct 2026 16:06:37 +0000

A Sharpe ratio tells you how much return a strategy produced per unit of wobble. The Deflated Sharpe Ratio asks a harder question: given how many versions of this strategy you tried before picking this one, how impressive is that number really?

The gap between the two is where most backtests quietly die. This guide explains what the deflation does, how to compute it, and what number you should expect your own bot to produce.

The problem in one example

Take a strategy with no edge at all. Now test 50 variants of it: different moving-average lengths, different stop distances, different hours of the day. Keep the best one.

That winner will have a good-looking equity curve and a respectable Sharpe ratio. Not because it works, but because you ran 50 lotteries and kept the winning ticket. The ordinary Sharpe ratio has no way of knowing this happened. It sees one strategy and one track record, and it answers the question you asked rather than the question you should have asked.

The Probabilistic Sharpe Ratio (PSR) and the Deflated Sharpe Ratio (DSR), both from work by Marcos López de Prado and David Bailey, close that hole.

PSR: is this Sharpe ratio distinguishable from zero?

PSR(0) is the probability that a strategy's true Sharpe ratio is above zero, given the Sharpe you observed, the number of observations, and the shape of the return distribution.

It rises with sample size, and it falls when returns are negatively skewed or have fat tails — which is exactly the profile of a strategy that wins small and often and then loses big. Two bots can show the same Sharpe ratio and have very different PSR values if one of them earned it over 1,000 trades and the other over 60, or if one of them has a hidden tail.

A common working threshold is PSR(0) ≥ 0.95: at least a 95% probability the true Sharpe is positive.

DSR: the same question, after counting your attempts

DSR takes PSR and deflates the benchmark it is measured against. Instead of asking whether the Sharpe beats zero, it asks whether the Sharpe beats the Sharpe you would expect the best of N trials to produce by pure chance.

That expected maximum grows with the number of trials, and it grows faster than people's intuition. The intuition to carry around is the one from order statistics: the expected largest value from N independent standard-normal draws rises roughly with the square root of twice the natural log of N. Sixty trials put the bar near 2.9 standard deviations; a thousand trials push it past 3.7. The number of attempts is not a footnote to the result. It is part of the result.

Two things follow:

DSR is always lower than PSR, and the gap widens with every variant you try.
A strategy can have PSR(0) = 0.99 and DSR = 0.30 at the same time. That combination is the signature of overfitting, and it is the single most informative pair of numbers you can compute about a backtest.

What counts as a trial

This is where almost everyone under-counts. A trial is any variant you looked at and could have chosen, including:

every parameter combination in a grid search, not just the ones you wrote down;
every entry filter you added and then removed because it did not help;
every coin universe you tried;
every version of the strategy from earlier sessions, if the current version descends from it;
every timeframe you tested before settling on the one you kept.

If you ran a 10 by 10 grid, that is 100 trials, not 1. If you then added a filter and ran it again, that is 200. The honest number is almost always larger than the number you remember, and the correct response to uncertainty is to use the larger estimate. Deflating by too many trials makes you slow. Deflating by too few makes you confident about noise.

A worked comparison

Two of our own demonstration strategies, both audited the same way:

| | Honest trend-follower | Curve-fitted variant | |---|---|---| | What it is | EMA crossover with a band, past bars only | the best of 50 variants: a crossover that only trades on two weekdays, at one hour, held for exactly 36 bars | | Variants tried | 3 | 50 | | PSR(0) | 0.95 | 0.98 | | DSR | 0.74 | 0.39 | | Verdict | not yet enough evidence | not ready, and the gap says why |

The curve-fitted one has the better ordinary statistics. It is the one you would pick if you only looked at PSR, or at the equity curve, or at the win rate. Its DSR is what gives it away: once the 50 attempts behind it are priced in, most of its apparent edge is explained by having tried 50 times.

Note also that the honest strategy does not pass either. That is normal and it is the point. A real edge usually needs more trades before it can be told apart from luck, and "not yet" is a legitimate verdict.

How to use these numbers in practice

Write down your trial count before you compute anything. Deciding it afterwards, when you can see which number you need, is how the count ends up at 1.
Report PSR and DSR together. PSR alone flatters. DSR alone hides whether the problem is sample size or selection.
Set the bar in advance. Ours: PSR(0) ≥ 0.95 and DSR ≥ 0.5, alongside a minimum trade count, a recency check, concentration limits and a drawdown limit. Six fixed gates, decided before the result is known.
Expect to fail. Across the hundred strategy books we track, mostly paper, none currently passes all six gates at our 300-trade floor. That is the honest base rate, and a tool that frequently tells you yes is not measuring anything.

What these statistics cannot do

DSR works on your list of trades. It cannot see your code. So it will not catch:

look-ahead bias, where the backtest used information that did not exist yet — that needs a separate audit that recomputes the signal on truncated history and checks it does not change;
wrong cost assumptions — if your R values were computed with optimistic fees, every statistic downstream inherits the optimism;
a backtest that never could have been filled at the prices it assumed.

Get the trades right first. Then deflate.

Compute it on your own trades

The implementation we use — PSR, DSR, minimum track record length, the six gates, the cost model and the look-ahead audit — is MIT-licensed Python at github.com/botlabtrade/botlab-oss. There is also a checker that runs in your browser: paste a CSV of closed trades, enter how many variants you tried, and read the six gates with your own numbers. Nothing is uploaded.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.

Do Funding Rate and Open Interest Filters Improve a Crypto Bot?

Bot LAB — Mon, 12 Oct 2026 16:06:35 +0000

Exchange data is sold as the missing ingredient for crypto bots. Funding rate, open interest, the long/short account ratio, the perp premium: add one as an entry filter, the pitch goes, and your signal starts skipping the bad trades.

We tested that claim properly and the answer was mostly no. Out of 60 filter-and-dataset combinations, one cleared the bar that separates a real effect from the best of sixty coin flips. This guide shows the test, the numbers, and the reason the result is so one-sided.

What we tested

Five trade lists, all on 15 USDT perpetual contracts on Bybit:

| Dataset | What it is | Trades | Baseline mean R per trade | |---|---|---|---| | 15m | a 20-indicator voting scalp signal | 113,013 | -0.188R | | 30m | the same signal on 30-minute bars | 62,585 | -0.151R | | 4h (all) | a 4-hour mean-reversion bot's full ledger | 6,159 | -0.111R | | 4h (subset) | the part that bot actually trades | 424 | +0.101R | | 1D | a Donchian-20 daily breakout, 2 ATR stop | 886 | +0.205R |

R is the result of a trade measured in units of its own risk: risk 1% of the account, make 2%, that is +2R. Every R above is after costs — taker fee 0.055% per side, slippage measured by walking a real order book for the trade size, and average funding multiplied by holding time.

Twelve filters, each with fixed rules taken from tools that already existed, nothing tuned for this test:

Price and trend: BTC daily regime against its 200-day EMA, multi-timeframe EMA agreement on 4h, the Ichimoku cloud, Supertrend, ADX between 20 and 35, position in the 20-day Donchian range, Choppiness below 55.
Exchange data: funding not crowded on our side of the trade, open interest rising with price over 24 hours, no open-interest spike above 8% in 4 hours, the long/short account ratio contrarian against its 30-day median, the perp premium contrarian against its 7-day mean.

How we avoided fooling ourselves

Three decisions did most of the work.

Every data point carries the moment it became knowable. Funding is stamped at its settlement time, open interest and the long/short ratio at the end of their hour, candle-derived values at candle close. A trade may only read rows that were available strictly before its entry. We re-checked a random sample of 48 trades against the live exchange API and they matched. Without this rule, a filter that quietly reads the current hour's open interest will look brilliant and be worthless.

The split is by time, not at random. The oldest 60% of entries are the training period, the newest 40% the test period. A filter counts as helping only if the trades it agrees with beat the baseline in both periods, with at least 30 agreeing trades in each. Random splits leak: a trade from June sitting in training while its neighbour from the same June afternoon sits in test is not an out-of-sample test of anything.

We counted our own attempts. Twelve filters across five datasets is 60 trials. If all 60 were pure noise, the largest t-statistic you would expect to see by chance is roughly the square root of twice the natural log of 60, about 2.86. That is the bar. A filter scoring t = 2.0 in a 60-trial study has not found anything; it is simply the luckiest of sixty.

Because trades opened on the same day share the same market, we also computed a daily-clustered statistic: the average of each day's agree-minus-disagree difference, rather than treating every trade as independent. This matters more than most people expect. A filter that tags 400 trades across 30 days has roughly 30 independent observations, not 400.

What came back

One combination cleared 2.86. Multi-timeframe EMA agreement on the 4-hour bot: both the fast pair and the slow pair pointing the same way as the trade. It helped in training, it helped in test, and it cleared the noise bar. Everything else either failed one period, or beat the baseline by less than the study's own luck threshold.

The funding and open-interest guardrails almost never disagree. Across all ten cells where they applied, they agreed with 84% to 100% of trades, and in six of those ten they were effectively constant — they say "fine, go ahead" nearly every time. That is a useful property for a risk check, which should only ever stop you in a genuinely extreme state. It is a useless property for a signal, because a filter that never says no cannot improve anything.

The long/short ratio changed its mind by dataset. It helped on 15m, on 30m and on the 4-hour ledger, overfit on the 4-hour subset, and did nothing on the daily. A filter whose direction depends on which dataset you show it is describing the dataset, not the market.

The reason, which is simpler than the statistics

Look at the fee arithmetic on the 15-minute signal. Fees alone are 0.055% twice, so 0.11% per round trip, before slippage and before funding. The minimum stop is 0.6%. So 0.11 divided by 0.6 is about 0.18R of pure cost per trade — almost exactly the size of that signal's loss per trade of -0.188R.

The 15-minute signal does not have a filtering problem. It has a cost problem. No entry filter can rescue an edge smaller than the cost of taking it; the best a filter can do is make you lose more slowly by trading less.

On the daily breakout, with a stop measured in multiples of ATR, the same 0.11% is a rounding error. This is why the same filter can look useless on one timeframe and plausible on another: the thing that changed was the denominator.

What this means for your own bot

Check costs before you check filters. Divide your round-trip cost by your typical stop distance. If the answer is a meaningful fraction of your expected edge per trade, no filter will save the strategy.
Count every variant you tried, including the ones you abandoned, and raise your evidence bar accordingly. The honest number is almost always larger than the one you remember.
Treat exchange data as a guardrail, not as alpha. Funding and open-interest extremes are good reasons to stand aside. They are poor reasons to enter.
Check how often your filter disagrees. If it agrees with 95% of your trades, it cannot be doing much, however good its numbers look.

What we are not claiming

The 60-trial count covers this study alone. These five datasets came from strategies that were themselves selected after earlier experiments, so the true number of attempts behind them is larger and every figure here is, if anything, flattering. The 15m and 30m lists are backtests of our own scalp signal rather than live bots. The order-book slippage uses a recent snapshot, which understates the cost of trading in thinner past markets. And the split is a single cut in time, not a walk-forward.

The one surviving result is a reason to keep testing multi-timeframe trend agreement on new trades. It is not a reason to trade it.

Run the numbers yourself

The statistics behind all of this — the probabilistic and deflated Sharpe ratios, the minimum track record length, the six readiness gates, the cost model and the look-ahead audit — are MIT-licensed Python at github.com/botlabtrade/botlab-oss. Point it at your own trade list and you can reproduce the method on your own data. There is also a browser version that needs no install.

Paper trading results are simulated. Past results don't predict future results. Crypto trading can lose money, including all capital. Not financial advice.

Originally published on BOTLAB. Score your own bot's trade log free: Check your bot.