Pine Script Backtest Accuracy: Why Results Look Too Good

TL;DR: A Pine Script backtest often looks better than live trading because of its settings, not the strategy: commission and slippage default to zero, "fill on bar close" trades at a price you could not have acted on, calc_on_every_tick and request.security lookahead can leak future information, and funding on perps appears not to be modeled. Fix those settings first; if you rebuild the strategy in Trigr, fees are always applied, fills happen at the next bar's open, data is point-in-time, and slippage and funding are one switch away.

Is the TradingView Strategy Tester wrong?

No. The Strategy Tester does what its settings tell it to do, and TradingView documents those settings carefully. The problem is that several defaults and popular options are optimistic, and most people never open the properties tab.

A backtest is a model of how orders would have filled. Every assumption in that model either costs you money or quietly gives you money. The sections below go through the assumptions that most often flatter a Pine strategy, with what TradingView's own documentation says and how Trigr handles the same question. The pillar on point-in-time backtesting covers the general principles.

Which Strategy Tester defaults flatter results?

Costs start at zero

According to TradingView's strategy() declaration reference, commission_value and slippage both default to 0. A strategy with no costs set pays nothing to trade, which is never true on a real exchange.

When you do set costs, commission can be a percent of value, currency per contract or currency per order. Slippage is set in ticks and applied to market and stop orders, against you on both sides; limit orders are not slipped, per TradingView's strategy properties page.

Zero-cost backtests hurt most on high-frequency strategies. A system that trades several times a day on 15-minute bars can turn from profitable to unprofitable on fees alone. Slippage and funding in perp backtests shows how to think about gross versus net.

Capital, sizing and margin

Initial capital defaults to 1,000,000 and pyramiding defaults to 1. The margin settings (margin_long, margin_short) are documented with a default of 100, meaning positions are fully funded with no leverage. That is a reasonable neutral default, but it also means a strategy tested at 1:1 tells you little about how it behaves at the leverage you plan to trade on a perp venue.

No funding on perps

We could not find any strategy() parameter for funding payments, so the Strategy Tester appears not to model perpetual futures funding. We have flagged this as an inference from TradingView's documentation rather than a stated fact.

For a strategy that holds perps for hours or days, funding is a real cash flow. Long positions in a crowded bull market can pay funding for weeks. Leaving it out can inflate a trend-following long strategy and hide a structural cost.

When does a Pine backtest fill at a price you could not get?

By default, the Strategy Tester calculates at the bar's close and fills the order at the next bar's open. TradingView's docs put it plainly: once a bar has closed it cannot be traded, so the earliest fill is the next bar's open. That default is sound.

Two settings change it:

• process_orders_on_close (Fill orders "On bar close") executes market orders at the same bar's close that generated the signal. In live trading you only know the close once the bar has finished, so the fill you get is later and usually at a different price.
• Non-standard charts. On Heikin Ashi, Renko and similar charts, results do not reflect actual market conditions by default, because the synthetic bar prices are not tradable prices. TradingView offers "Fill orders using standard OHLC" (fill_orders_on_standard_ohlc) to fix this.

Inside a bar, the broker emulator has to guess the price path. If the open is closer to the high, it assumes open, high, low, close, and it assumes no gaps inside the bar. The Bar Magnifier (use_bar_magnifier) uses lower-timeframe data instead, as described in the Pine Script strategies guide. Without it, a bar that touched both your stop and your target is resolved by that assumption rather than by what happened. Stop-loss and take-profit in the same candle explains why this matters.

How do repainting and lookahead leak the future?

This is the most dangerous category, because it can make a worthless strategy look excellent.

calc_on_every_tick. On historical bars, the script only calculates at the close, while in real time it recalculates on every tick. TradingView warns that strategies using this option "will repaint" and "will not show realistic results on historical bars."

request.security with lookahead. Fetching a higher timeframe with lookahead = barmerge.lookahead_on and no one-bar offset returns data from the future on historical bars. A daily close is visible from the first hour of the day. TradingView's repainting documentation recommends request.security(syminfo.tickerid, tf, close[1], lookahead = barmerge.lookahead_on), and notes that neither the offset nor the lookahead can be removed without compromising the result.

Unconfirmed bars. Signals that depend on a bar still forming can appear and disappear. Gating logic on barstate.isconfirmed avoids that.

A useful test: if your backtest's win rate drops sharply when you add [1] to higher-timeframe inputs, the original result was probably reading ahead. Look-ahead bias in crypto backtests has more examples.

How does Trigr handle the same questions?

Trigr is a no-code strategy builder with its own backtest engine for Hyperliquid perps. It makes a different set of choices, most of which remove options rather than add them:

A few honest caveats about Trigr's side. Slippage is a flat number of basis points you choose; there is no order-book, spread or market-impact model. Slippage and funding are off by default, and a first result is labeled gross, so you still need to turn them on. Historical funding comes from Binance's 8-hour USDT-M series, while Hyperliquid itself pays hourly. And a plain backtest reports the equity curve, trade log and an audit trail, but not the Deflated Sharpe Ratio or PBO; those come from an ML optimization run. The backtesting docs list every setting.

What this means for you: when you rebuild a Pine strategy in Trigr, a lower result is usually information, not a bug. It tells you how much of the TradingView number came from settings.

What should you check when rebuilding a Pine strategy in Trigr?

Use this checklist before you compare numbers:

1. Record the Pine settings. Note commission, slippage, process_orders_on_close, calc_on_every_tick, pyramiding, chart type and any request.security calls.
2. Rerun the Pine version honestly first. Set realistic commission and slippage, turn off same-bar fills, use standard OHLC, and offset higher-timeframe series by one bar. This gives you a fairer baseline.
3. Map each rule to a node. Entry condition to TRIGGER, extra conditions to FILTERs, the combination to SIGNAL, and sizing, leverage, TP/SL, ATR trail and time stop to RISK.
4. List what does not translate. Custom Pine math, limit or stop entries, partial exits and custom exit logic have no direct equivalent in Trigr. Decide whether the approximation is still the same strategy.
5. Run gross, then net. Run once without frictions, then with slippage and historical funding, and compare.
6. Read the trade log, not just the curve. Match trade counts and exit reasons against TradingView's list of trades. Large differences point to a translation or settings gap.
7. Change one thing at a time. Test variants as labelled experiments inside one strategy so the number of trials stays visible.
8. Forward-test before capital. A paper agent builds a record on data that did not exist when you chose the strategy.

If you work with an AI assistant, the steps above can be run over MCP; importing a TradingView strategy with MCP walks through the exact prompts and tools.

Backtests are not guarantees; perps are leveraged and can lose more than expected.

Next steps

Pick one Pine strategy, note its settings, and rebuild it in Trigr to see how much of the edge survives realistic costs. The comparison of Trigr and TradingView's Strategy Tester covers the broader differences, and plans and credits explain what a backtest costs.