Guide
Is your TradingView backtest too good to be true?
Last reviewed: 14 September 2026·Tradelyze
A TradingView backtest usually looks too good to be true because of too few trades, zero trading costs, settings tuned to past prices, or a script that peeks at future prices. Each leaves a sign you can check in the Strategy Tester or the script. Fix those, then test on prices the strategy was not tuned on.
In plain English
The Strategy Tester is the panel under a TradingView chart that backtests a strategy: it shows how the strategy's rules would have traded on past prices. A great result can come from how the test was set up rather than from rules that work. This page is a checklist of ten warning signs, with where to find each one and what to do about it. The ordered, step-by-step procedure is in How to validate a trading strategy.
New to this? Start with What is backtesting?
Which warning signs can you see in the Strategy Tester?
Ten warning signs cover the usual reasons a TradingView backtest looks better than trading the same rules would be. No study ranks how often each one happens, so they are listed in the order you can check them. Signs 1 to 5 are numbers in the strategy report. Signs 6 to 8 are in the chart settings or the script. Signs 9 and 10 depend on how you tested.
| Warning sign | Where to look | Why it flatters the result |
|---|---|---|
| 1. Few trades | Total trades in the strategy report | A handful of lucky trades can make any figure look good. |
| 2. Zero commission and slippage | The strategy's Properties tab, or its strategy() line | Every trade fills at the price it wanted and pays no fee. |
| 3. A very high profit factor | Profit factor in the strategy report | A few small losing trades push it up, often by luck. |
| 4. A win rate of 90% or more | Percent profitable in the strategy report | Small targets with wide stops win often and lose big. |
| 5. A tiny drawdown percentage | Max drawdown in the report, and Initial capital in the Properties tab | A 1,000,000 default account makes any dollar loss look small. |
| 6. A Heikin Ashi, Renko or other non-standard chart | The chart type button above the chart | Orders can fill at prices that never traded. |
| 7. Orders filling on the bar that triggered them | process_orders_on_close in the script, and entry prices in the trade list | A live order often cannot fill at a close that has already happened. |
8. request.security() with lookahead on | The script's request.security() calls | Past bars can read higher-timeframe prices before those prices existed. |
| 9. Many settings tried | Your own testing history; nothing in the report | The best of many tries is flattered by luck. |
| 10. Results that change when the start date moves | The date range of the strategy report | The edge rests on a few trades or one stretch of market. |
1. Does the backtest have too few trades?
Where to look: Total trades, in the strategy report. Read it before any other figure, because every other number depends on it.
Why it flatters the result: with few trades, luck decides the result. As constructed arithmetic, 12 wins in 20 trades is a 60% win rate; if two of those wins had been losses, it would be 50%. Profit factor and net profit swing just as easily. Fewer than about 30 closed trades supports almost no conclusion, and about 100 or more across different kinds of market is a sturdier base. Neither figure comes from a study: both are rules of thumb with no primary source.
More: how many trades a backtest needs.
2. Are commission and slippage set to zero?
Where to look: the strategy's Settings, on the Properties tab, or the commission_value and slippage arguments in the script's strategy() declaration. Commission is the fee a broker or exchange charges per order. Slippage is the gap between the price an order wanted and the price it actually got.
Why it flatters the result: zero is TradingView's default, not an estimate. On commission, TradingView's Pine Script documentation says the default commission_value "is 0, meaning that the strategy does not simulate commission unless the user specifies a nonzero value." On slippage, the same documentation says that with the default of 0, "the strategy fills orders at their expected prices without simulating any slippage."
As constructed arithmetic, take one Micro E-mini Nasdaq-100 (MNQ) futures contract, where one tick of price movement is worth $0.50. A $1.00 commission per fill plus one tick of slippage per fill costs $3.00 per round trip, the entry and the exit together. Over 400 trades, that is $1,200 a zero-cost backtest never shows. Strategies with small average trades lose the largest share of their profit to costs.
More: what commission, spread and slippage cost per trade.
3. Is the profit factor unusually high?
Where to look: Profit factor, in the strategy report. Profit factor is gross profit divided by gross loss, so 2.0 means $2 won for every $1 lost.
Why it flatters the result: profit factor does not know how many trades it rests on. As constructed arithmetic, 9 wins of $100 and 1 loss of $50 give a profit factor of $900 ÷ $50 = 18. One more $50 loss halves it to 9. For the same reason, an optimizer told to maximize profit factor tends to pick settings that barely trade.
Many trading education sites call a profit factor of 1.5 to 2.0 good, but that range is convention with no primary research behind it. No published threshold marks a profit factor as too high either, so read it next to Total trades.
More: what counts as a good profit factor and why optimizing for profit factor breaks.
4. Is the win rate 90% or higher?
Where to look: Percent profitable, TradingView's name for win rate: winning trades divided by closed trades.
Why it flatters the result: a high win rate is easy to build and says nothing about the size of each trade. A small profit target with a wide stop wins often and loses big. Expectancy, the average profit or loss per trade, shows whether the strategy makes money:
As constructed arithmetic, a strategy that wins 90% of the time with $100 wins and $1,000 losses loses $10 per trade: (0.9 × $100) − (0.1 × $1,000) = −$10. In a short backtest, a lucky run can hide that loss for a long time, because a single $1,000 loss erases ten wins.
More: why a very high win rate is a warning sign.
5. Is the drawdown percentage tiny because initial capital is 1,000,000?
Where to look: Max drawdown in the strategy report, shown as an amount and a percentage, and Initial capital on the Properties tab. Maximum drawdown is the largest fall in account value from a peak to a later low.
Why it flatters the result: the percentage is worked out on an account that starts at initial capital, and TradingView's default is large. TradingView's Help Center article Initial capital says that when no value is given in the settings or code, "the field is set to 1,000,000," in the currency of the chart's symbol. TradingView's Pine Script documentation gives the same default for initial_capital.
As constructed arithmetic, a $1,500 drawdown with a fixed order size is 0.15% of 1,000,000 but 3.0% of a $50,000 account. A prop firm's loss limit is set against your real account, so read the dollar figure first.
More: reading Max drawdown in TradingView's report and maximum drawdown.
6. Was the backtest run on a Heikin Ashi, Renko or other non-standard chart?
Where to look: the chart type button on the toolbar above the chart. Standard candles or bars use real prices. Heikin Ashi, Renko, line break, Kagi, point & figure and range charts draw synthetic bars, meaning prices calculated from real prices rather than prices anyone traded at.
Why it flatters the result: on a synthetic chart, the Strategy Tester can fill an order at a price that never traded. TradingView's Pine Script documentation says strategy results on these chart types "do not reflect actual market conditions by default," and that running a strategy on one "typically produces unrealistic results."
TradingView's Strategy properties article describes a Using standard OHLC option. The article says it "forces strategies running on Heikin Ashi charts to fill orders using actual OHLC prices." It changes fill prices on Heikin Ashi charts only; the signals still come from the Heikin Ashi candles. Renko is worse: TradingView's support article on non-standard charts says a Renko strategy "will use the price levels from the Renko bricks rather than from real market prices." The safe route is to backtest on a standard candlestick chart.
More: what Fill orders using standard OHLC changes.
7. Do orders fill on the same bar that triggered them?
Where to look: process_orders_on_close = true in the script's strategy() declaration, or the matching option on the Properties tab. In the list of trades, entries priced at the close of the bar that gave the signal are the symptom.
Why it flatters the result: by default a script runs once at the close of each historical bar. TradingView's Pine Script FAQ says "The next possible moment for an order to be filled is the beginning of the next bar." process_orders_on_close removes that one-bar wait. The same FAQ warns that "processing orders on close might not give accurate results."
The FAQ's example is a signal on a session's last bar: a real order could only fill the next trading day, while the backtest fills it at the previous close. It says this "can lead to repainting, where the behavior of the strategy's simulation on historical bars differs from that seen in live trading."
A related sign is a stop and a target that often fit inside one bar. TradingView's documentation says the Strategy Tester assumes the path price took inside a bar, for example open → high → low → close when the bar opens nearer its high. Which order filled first is then an assumption, not a record.
More: what the fill settings change and how the Strategy Tester decides when orders fill.
8. Does the script call request.security() with lookahead on?
Where to look: open the script in the Pine Editor, search for request.security, and read each call's lookahead argument.
Why it flatters the result: request.security() reads data from another symbol or timeframe, such as the daily high on a 5-minute chart. Its default is barmerge.lookahead_off. The danger is barmerge.lookahead_on with no [1] offset on the requested value. For that case, TradingView's repainting documentation says the call "will return data from the future on historical bars, which is dangerously misleading." A strategy that trades against today's daily high before the day has ended looks perfectly timed and cannot be traded.
dailyHigh = request.security(syminfo.tickerid, "D", high, lookahead = barmerge.lookahead_on)
// documented non-repainting pattern: yesterday's completed high
dailyHigh = request.security(syminfo.tickerid, "D", high[1], lookahead = barmerge.lookahead_on)
Check the pattern against TradingView's current Pine Script documentation before editing your script. This leak is the look-ahead bias described in the next section. TradingView's documentation on other timeframes says scripts that use lookahead to leak future data are "extremely misleading" and are not allowed as script publications.
More: Pine Script repainting and look-ahead bias.
9. How many settings were tried before this one?
Where to look: nowhere in the report. The Strategy Tester shows only the settings on the chart now, not the ones you tried and dropped. Count them yourself: inputs changed by hand, optimizer runs, and whole strategies you abandoned.
Why it flatters the result: every setting tried is another chance for luck to produce a winner. As constructed arithmetic, three inputs tested at 10 values each make 1,000 combinations. Bailey, Borwein, López de Prado and Zhu (2014) show that a backtest with impressive results is easy to find after a fairly small number of tries. The more tries, the more likely that winner is overfit: tuned to random noise in one stretch of history, so it will not repeat.
More: why the number of trials matters more than the number of inputs.
10. Do the results change a lot when the start date moves?
Where to look: the date range of the strategy report. TradingView's Pine Script documentation says the report lets you customize the testing period. Move the start by a month or a quarter and compare Net profit, Profit factor and Total trades.
Why it flatters the result: a result that flips when the start moves by a few weeks is fragile. It rests on a few trades, or on one stretch of market that suited the rules. The start date also decides when indicators first have enough bars to calculate, which can move the first trades.
Do not keep whichever start date looks best. Picking dates after seeing results is tuning by another name, and it uses up history you could have tested on. Walk-forward analysis does this check in a structured way: it tunes on one stretch of history and tests on the next, window after window.
More: why results change when the start date shifts and walk-forward analysis.
What does an inflated backtest look like once the warning signs are fixed?
The table follows one strategy through two fixes. It is a constructed illustration, not measured data. The TradingView report shows an MNQ strategy on a 5-minute chart trading 2 contracts, with TradingView's default 1,000,000 initial capital and no costs. It has 36 trades: 28 wins averaging 20 points and 8 losses averaging 25 points. At $2 per point on 2 contracts, a win is $80 and a loss is $100. The losses come in two runs of four in a row: the first run opens the backtest, and at least ten wins separate it from the second.
The second column sets initial capital to a $50,000 account and adds $1.00 commission and one tick of slippage per contract per fill. That is $6.00 per trade on 2 contracts, so each win nets $74 and each loss costs $106. The third column turns two of the 28 wins into losses, the kind of swing luck alone can produce on 36 trades.
| Report figure | As first tested | Real account and costs | Two wins become losses |
|---|---|---|---|
| Initial capital | 1,000,000 | $50,000 | $50,000 |
| Total trades | 36 | 36 | 36 |
| Percent profitable | 77.8% | 77.8% | 72.2% |
| Net profit | $1,440 | $1,224 | $864 |
| Profit factor | 2.80 | 2.44 | 1.82 |
| Max drawdown | $400 | $424 | $424 or more |
| Max drawdown as % of initial capital | 0.04% | 0.85% | 0.85% or more |
The arithmetic: 28 × $80 = $2,240 of gross profit against 8 × $100 = $800 of gross loss gives a profit factor of 2.80. After costs, 28 × $74 = $2,072 against 8 × $106 = $848 gives 2.44. With two wins flipped, 26 × $74 = $1,924 against 10 × $106 = $1,060 gives 1.82. The maximum drawdown is the opening run of four losses: 4 × $100 = $400, or 4 × $106 = $424 after costs, which is 0.04% of 1,000,000 and 0.85% of $50,000. Ten or more wins after that run lift the account to a new high, so the second run cannot go deeper. Turning a win into a loss lowers every later equity point, so the maximum drawdown in the last column cannot shrink.
The rules never changed. The first report left out costs and measured drawdown against a huge account, and 36 trades cannot tell two lucky wins from skill. Profit factor fell from 2.80 to 1.82 and net profit by 40%.
The table cannot show signs 6 to 10. A look-ahead leak, same-bar fills or a synthetic chart changes which trades exist at all. Only a re-run after fixing the script shows what is left.
Which backtesting biases sit behind these warning signs?
A backtesting bias is a systematic error that makes a historical test look better than trading the same rules would have been. Three biases sit behind most of the ten warning signs: look-ahead bias, data-snooping bias and selection bias. A fourth, survivorship bias, matters less for a strategy tested on a single futures or forex chart.
What is look-ahead bias?
Look-ahead bias is using information in a backtest that was not available when the trade would have been placed. In Pine Script, look-ahead bias comes from request.security() with lookahead on and no offset (sign 8). It also comes from fills at a close the order could not have reached in time (sign 7). Synthetic chart prices (sign 6) are a close relative: the fill price did not exist in the market. More history or more trades cannot fix look-ahead bias, because every bar carries the same leak. Find it in the script and remove it.
What is data-snooping bias?
Data-snooping bias is the flattering result that comes from testing many ideas or settings on the same data and keeping whatever worked best. Lo and MacKinlay studied data-snooping biases in tests of asset pricing models in 1990. White (2000) proposed the Reality Check, a test of whether the best of many models beats a benchmark by more than luck. In a TradingView strategy, data snooping is sign 9, many settings tried. It shows up as a very high profit factor (sign 3) or as results tied to one start date (sign 10). The defense is data the tuning never saw.
What is selection bias in backtesting?
Selection bias in backtesting is judging a strategy by the winner you picked instead of by everything you tried. The strategy on your chart is the one that survived your testing, so its report shows the best case of the lot. Bailey, Borwein, López de Prado and Zhu (2014) show that the chance a chosen backtest is overfit grows with the number of configurations tried. Few trades (sign 1) make selection bias worse, because luck has more room to crown a winner. Choosing which market or timeframe to trade after seeing which one backtests best is selection bias too.
Does survivorship bias matter for a single futures or forex strategy?
Survivorship bias comes from testing only instruments that still exist, leaving out those that were delisted, went bankrupt or closed. It inflates tests run across a basket of stocks or funds; Brown, Goetzmann, Ibbotson and Ross examined it in performance studies in 1992. A strategy tested on one futures contract or one forex pair has no basket to drop the losers from, so survivorship bias matters less there.
Two related checks still apply. Picking the one market that happened to backtest best is selection bias. A continuous futures chart such as MNQ1! is stitched together from expiring contracts, and how the joins are handled changes historical prices; see continuous futures in the data export guide.
What should you do next if your backtest shows these signs?
Fix what can be fixed in the script before judging the strategy. Signs 2, 5, 6, 7 and 8 are settings or code, so their fixes are mechanical. Signs 1, 3, 4, 9 and 10 need more evidence, not edits.
- Write your broker's commission, a realistic slippage in ticks and your real account size into the
strategy()declaration, usingcommission_value,slippageandinitial_capital. See writing settings into strategy(). - Switch the chart to standard candles, and fix any
request.security()call that uses lookahead without a[1]offset. - Decide whether same-bar fills from
process_orders_on_closematch how you would really place orders. If not, remove the setting. - Re-run the backtest and read Total trades, Profit factor, Percent profitable and Max drawdown in dollars again.
- Work through the ordered checks in How to validate a trading strategy: reproduce the backtest, count trades, test on unseen data, stress the trade order, check prop firm rules and forward test.
Several of those checks happen outside TradingView and need two files: the trade list and the price data. Exporting TradingView trades and price data explains both.
The trap to avoid
Fixing the warning signs usually makes a backtest look worse, and that is the point: the new numbers are closer to what the rules can do. Do not re-tune the settings until the old numbers come back. Every re-run after seeing a result is another trial, which turns the fix into sign 9. See the re-optimizing trap.
Which warning signs does Tradelyze check, and which does it not?
Tradelyze is a web app, in beta, that re-runs an uploaded TradingView Pine Script strategy on price data you upload and compares its trades with your exported TradingView trade list. It then searches for better settings, runs walk-forward analysis and a five-check robustness score, and checks prop firm rules. Tradelyze reports figures for several of the ten warning signs. It does not detect repainting or look-ahead bias, and it does not forward test.
| Warning sign | What Tradelyze does | What stays with you |
|---|---|---|
| 1. Few trades | Shows Trade Count in Best Metrics. Its permutation test needs at least 20 closed trades to return a p-value, and its deflated Sharpe ratio check needs at least 5. Below those counts, the check scores zero. | Deciding whether the trade count is enough. No primary source sets a general minimum. |
| 2. Zero costs | Re-runs with the costs and initial capital written in the script's strategy() declaration, and has no cost fields of its own. A script with zero costs is re-run at zero cost. | Writing realistic costs into the script before exporting and uploading. |
| 3. High profit factor | Shows Profit Factor in Best Metrics and in the Top Trials table, next to trade counts. | Reading profit factor next to the trade count. |
| 4. High win rate | Shows Win Rate. It does not show expectancy. | Working out expectancy, for example from a trial's downloaded trades. |
| 5. Tiny drawdown % | Shows Max Drawdown, and each prop firm's Rule Results compare drawdown with that firm's limits. Initial capital comes from the script. | Setting initial_capital to the account you will trade. |
| 6. Non-standard chart | Re-runs on the price file you upload, so trades from a Heikin Ashi or Renko test can show up as TV Only and BT Only and lower the Match Rate. It does not detect the chart type. | Backtesting on standard candles. |
| 7. Same-bar fills | Re-runs whatever the script declares. A fill setting changed only in TradingView's Properties tab can move trades and lower the Match Rate. It does not judge whether same-bar fills are realistic. | Deciding whether your real orders could fill that way. |
| 8. Lookahead | Does not detect repainting or look-ahead bias. A script that leaks future data is re-run as written, so the Match Rate can still be high. It asks for extra timeframe price files when a script calls request.security(). | Checking every request.security() call yourself. |
| 9. Many settings tried | Optimizing runs at least 60 trials when the trial budget is automatic. The deflated Sharpe ratio and permutation test correct for the distinct settings this search tried. Walk-forward analysis tests the tuning on data it did not see. | Counting tuning done before upload, which Tradelyze cannot see. |
| 10. Start date | Does not re-run the strategy from different start dates. Walk-forward analysis splits history into windows, 2 by default, and Per-Window Results show how the windows differ. | Moving the start date in TradingView yourself. |
| Forward testing | Nothing. Tradelyze places no trades and does not forward test or paper trade. | All of it, on your charting platform or with your broker. |
Every Tradelyze result is hypothetical and built from the files you supply. Tradelyze does not give financial advice or guarantee a prop firm challenge pass. Each card in a report is explained in How Tradelyze validates a strategy.
Where this appears in Tradelyze
In Tradelyze, the re-run of your TradingView backtest appears as Match Rate on the Conversion Result card, and the tuned figures appear as Best Metrics. To judge the whole report, not one tile, use the pre-trade checklist. When a card comes back weak, what to do when a strategy fails validation covers each case.
Tradelyze re-runs an uploaded TradingView Pine Script strategy on your price data and compares its trades with your exported trade list. It then runs parameter optimization, walk-forward analysis, a five-check robustness score and prop-firm rule checks. It does not place trades, give financial advice or guarantee a challenge pass, and it is in beta.
Already a user? Open your strategies.
Frequently asked questions about backtests that look too good to be true
Questions about Tradelyze accounts, results and credits are answered in the Learn FAQ.
How can I tell if my TradingView backtest is too good to be true?
Check ten warning signs. In the Strategy Tester: too few trades, zero commission and slippage, a very high profit factor, a win rate of 90% or more, and a tiny drawdown percentage caused by 1,000,000 of initial capital. Elsewhere: a Heikin Ashi or Renko chart, same-bar fills, request.security() with lookahead on, many settings tried, and results that change when the start date moves.
Why is my backtest so profitable?
A backtest is often very profitable because of how it was set up, not because the rules work. The usual causes are costs left at TradingView's default of zero, a small number of lucky trades, settings tuned on the same prices they are scored on, and a script that reads future data through request.security() with lookahead on. Fix those, re-run it, then test on unseen data.
Why does the TradingView Strategy Tester show unrealistic results?
The Strategy Tester simulates fills from chart data, and several defaults and settings flatter the result. TradingView's Pine Script documentation says a strategy simulates no commission or slippage unless you set them, and that strategies on non-standard charts such as Heikin Ashi and Renko typically produce unrealistic results. Same-bar fills and request.security() lookahead can also create trades that could not happen live.
Is my Pine Script strategy overfit?
A Pine Script strategy is probably overfit when its settings were picked from many tries and its results fall apart on prices the tuning never saw. Warning signs include few trades, a very high profit factor and results that change when the start date moves. Count every setting you tried, then test the chosen settings once on held-back data or with walk-forward analysis.
What is look-ahead bias in a backtest?
Look-ahead bias is using information in a backtest that was not available when the trade would have been placed. In Pine Script the common cause is request.security() with lookahead on and no [1] offset, which TradingView's documentation says returns data from the future on historical bars. A backtest with look-ahead bias looks well timed on history and cannot be traded the same way live.
What are the main backtesting biases?
Three biases sit behind most warning signs of an inflated backtest. Look-ahead bias uses information not available at the time. Data-snooping bias keeps the best of many ideas tested on the same data. Selection bias judges the survivor of your testing instead of everything you tried. Survivorship bias, testing only instruments that still exist, matters more for baskets of stocks than for one futures or forex chart.
Does survivorship bias matter for a futures or forex backtest?
Less than for stocks. Survivorship bias comes from testing only on instruments that still exist, leaving out those that were delisted or closed. A strategy tested on one futures contract or forex pair has no basket to drop losers from. Picking the market that happened to backtest best is still selection bias, and a continuous futures chart such as MNQ1! is stitched together from expiring contracts.
Why is my max drawdown percentage so small in TradingView?
Often because initial capital was never changed. TradingView's Help Center says initial capital is set to 1,000,000 when neither the settings nor the code give a value. With a fixed order size, a $1,500 drawdown is only 0.15% of 1,000,000 but 3.0% of a $50,000 account. Set initial_capital to the account you will trade, and read the dollar figure first.
Does TradingView include commission and slippage by default?
No. TradingView's Pine Script documentation says commission_value defaults to 0, so a strategy simulates no commission unless you set a nonzero value, and that with the default slippage of 0 a strategy fills orders at their expected prices. Write your broker's commission and a realistic slippage in ticks into the strategy() declaration, then check how much of the profit survives.
Is a 90% win rate realistic in a backtest?
A 90% win rate is possible, but treat it as a warning sign until you have checked trade size. A small profit target with a wide stop wins often and loses big. As constructed arithmetic, winning 90% of trades at $100 and losing 10% at $1,000 loses $10 per trade. Read Percent profitable next to the average win and average loss, and work out expectancy.
Why do my backtest results change when I change the start date?
Results that swing with the start date usually rest on a few trades or on one stretch of market that suited the rules. Moving the start changes which trades are included and when indicators have enough bars to work. Compare net profit, profit factor and trade count across a few start dates, but do not keep the date that looks best: picking dates after seeing results is tuning too.
Does Tradelyze detect repainting or look-ahead bias?
No. Tradelyze does not check Pine Script for repainting or for future data leaked through request.security() lookahead. It re-runs your script on the price data you upload and compares the trades with your TradingView export, so a script with a leak can still show a high Match Rate. Check every request.security() call yourself before trusting a backtest from TradingView or from Tradelyze.
Can a backtest with none of these warning signs still fail in live trading?
Yes. Every check on this page uses historical prices, and markets change. Live trading also adds real slippage, missed fills and delays that a backtest only estimates. A backtest free of the ten warning signs has not been shown to be inflated, but it has not been shown to work either. Test it on unseen data, stress the trade order and forward test before risking money.
Sources
- TradingView, Pine Script User Manual, “Declaration statements” (Language section),
strategy()parameters:commission_value“is 0, meaning that the strategy does not simulate commission unless the user specifies a nonzero value”; with the default slippage of 0, the strategy “fills orders at their expected prices without simulating any slippage”;initial_capitaldefaults to 1000000. tradingview.com/pine-script-docs/language/declaration-statements, retrieved September 2026. - TradingView, Pine Script User Manual, “Strategies” (Concepts section): the broker emulator fills orders using only chart data by default; the intrabar path assumption; the notice that results on non-standard charts do not reflect actual market conditions by default; customizing the testing period. tradingview.com/pine-script-docs/concepts/strategies, retrieved September 2026.
- TradingView, Pine Script User Manual, FAQ, “Strategies”: entry “Why are my orders executed on the bar following my triggers?”, on
process_orders_on_closeand repainting. tradingview.com/pine-script-docs/faq/strategies, retrieved September 2026. - TradingView, Pine Script User Manual, “Repainting” (Concepts section): section “Future leak with request.security()”. tradingview.com/pine-script-docs/concepts/repainting, retrieved September 2026.
- TradingView, Pine Script User Manual, “Other timeframes and data” (Concepts section): the
lookaheadparameter ofrequest.security(), its defaultbarmerge.lookahead_off, and the notice that scripts leaking future data through lookahead are not allowed as publications. tradingview.com/pine-script-docs/concepts/other-timeframes-and-data, retrieved September 2026. - TradingView Help Center, Initial capital, article 43000777193: a default of 1,000,000, in the currency of the chart's symbol, when no value is set in the settings or code. tradingview.com/support/solutions/43000777193, retrieved September 2026.
- TradingView Help Center, Strategy properties, article 43000628599: the Using standard OHLC option for Heikin Ashi charts. tradingview.com/support/solutions/43000628599, retrieved September 2026.
- TradingView Help Center, “Strategy produces unrealistic results on non-standard chart types (Heikin Ashi, Renko, etc.)”, article 43000481029: strategy orders fill at the chart's OHLC values, a strategy on a Renko chart uses the Renko brick prices, and the Using standard OHLC option is described for Heikin Ashi charts. tradingview.com/support/solutions/43000481029, retrieved September 2026.
- David H. Bailey, Jonathan M. Borwein, Marcos López de Prado and Qiji Jim Zhu, Pseudo-Mathematics and Financial Charlatanism: The Effects of Backtest Overfitting on Out-of-Sample Performance, Notices of the American Mathematical Society 61(5), May 2014, beginning on page 458, DOI 10.1090/noti1105. The abstract on Western Michigan University's ScholarWorks record for the paper (scholarworks.wmich.edu/math_pubs/40, retrieved September 2026) reads: “We prove that high simulated performance is easily achievable after backtesting a relatively small number of alternative strategy configurations” and “The higher the number of configurations tried, the greater is the probability that the backtest is overfit.” Basis for sign 9 and the selection-bias section.
- Andrew W. Lo and A. Craig MacKinlay, Data-Snooping Biases in Tests of Financial Asset Pricing Models, Review of Financial Studies 3(3), July 1990, pages 431–467, DOI 10.1093/rfs/3.3.431.
- Halbert White, A Reality Check for Data Snooping, Econometrica 68(5), September 2000, pages 1097–1126, DOI 10.1111/1468-0262.00152.
- Stephen J. Brown, William Goetzmann, Roger G. Ibbotson and Stephen A. Ross, Survivorship Bias in Performance Studies, Review of Financial Studies 5(4), October 1992, pages 553–580, DOI 10.1093/rfs/5.4.553.
- Trade-count conventions of about 30 and about 100 closed trades: no primary source, as set out in how many trades a backtest needs. The profit factor range of 1.5 to 2.0: convention with no primary research, as set out in what counts as a good profit factor.
- MNQ tick value of $0.50 (a 0.25-point tick at $2 per point): Tradelyze's futures lookup table; confirm against the exchange's contract specifications.
- Every example on this page, including the 36-trade worked example, the per-trade costs, the profit factor and win-rate arithmetic and the drawdown percentages: constructed arithmetic, not measured data.
- Tradelyze implementation, reviewed September 2026: runs use the Pine Script's own
strategy()andinput()defaults, with custom backtest options switched off; trades are compared with the uploaded TradingView trade list; no repainting or look-ahead detection exists in the optimizer; the permutation test needs 20 closed trades to return a p-value and the deflated Sharpe ratio check needs 5, and below those counts each check scores zero; the multiple-testing corrections count the distinct settings the optimizer tried; the automatic optimization budget is at least 60 trials; walk-forward analysis uses 2 windows by default; extra timeframe price files are requested when a script callsrequest.security()orrequest.security_lower_tf(). Labels are quoted as shown in the app.