Guide

TradingView strategy properties

Last reviewed: 16 September 2026·Tradelyze

Strategy properties are the settings that tell TradingView's Strategy Tester how to simulate a Pine Script strategy's orders: starting capital, order size, commission, slippage, pyramiding and when orders fill. The script's strategy() declaration sets their defaults, and the Properties tab can override them. Commission and slippage both start at zero, so an untouched backtest ignores trading costs.

New to this? Start with how to backtest on TradingView.

What are strategy properties in TradingView?

Strategy properties are the simulation settings of a TradingView strategy: initial capital, account currency, order size, leverage, pyramiding, commission, slippage and the rules for when and how orders fill. They decide what each simulated trade costs and how large it is. That changes net profit, drawdown and every other number in the strategy report, even though no rule of the strategy changes.

A strategy property has two homes. The Pine Script author writes a default into the strategy() declaration, the first line of a strategy script. Anyone using the script on a chart can then override that default in the strategy's Settings/Properties tab. TradingView's Pine Script documentation describes this pattern for each property below. The documentation adds that a published strategy's report has a Properties tab. It lists the properties the author used, including initial capital, account currency, order size, leverage, pyramiding, commission and slippage.

Two of those defaults are easy to leave in place by accident. TradingView's Declaration statements page says initial_capital defaults to 1000000, and the Initial capital help article says the same figure is used in the chart symbol's currency when neither the settings nor the code sets one. The same documentation page says default_qty_type defaults to strategy.fixed and default_qty_value to 1, so an untouched strategy trades one contract, share, lot or unit against a 1,000,000 account. Every percentage in the report is then measured against 1,000,000 rather than the account you would trade.

Why it matters for your money: a prop firm challenge fee or a live account gets sized from these numbers. If the properties are wrong, the report describes a cheaper, smaller or more leveraged strategy than the one you would trade.

What do commission, spread and slippage cost per trade?

Commission, spread and slippage are the three costs of turning a signal into a filled order. Each round trip pays them on the way in and again on the way out. On a small futures contract they can easily add up to a meaningful share of a short-term trade's profit.

• Commission is, in TradingView's documentation's words, the fee that a broker or exchange charges when executing orders. It can be a flat fee per order, a fee per contract, share, lot or unit, or a percentage of the transaction value.
• Spread is the gap between the best price buyers bid and the best price sellers ask. A market buy pays the ask and a market sell receives the bid, while a chart bar records only one price per moment.
• Slippage is the difference between the price an order was meant to fill at and the price it actually filled at. TradingView's documentation says slippage "is dynamic and unpredictable, making it impossible to simulate precisely".

Worked example (constructed illustration, not measured data): one Micro E-mini Nasdaq-100 (MNQ) contract. Tradelyze's futures lookup table lists MNQ with a point value of $2 and a tick size of 0.25, so one tick is worth $0.50. Confirm both against the exchange's contract specifications. Assume a commission of $1.00 per contract per fill and one tick of slippage on each fill, with both entry and exit sent as market orders. Use your own broker's fee schedule for real figures.

A trade that gains 20 ticks (5 points) before costs makes $10.00 gross and $7.00 net. A trade that loses 20 ticks costs $10.00 gross and $13.00 net. The strategy looked like it risked $10 to make $10; after costs it risks $13 to make $7. Over 400 such trades, $3.00 each is $1,200 that a zero-cost backtest never shows. The backtest vs live trading page works through a larger version of the same gap.

Why don't Properties-tab changes travel with the script, and how do you write them into strategy()?

A change made in TradingView's Settings/Properties tab overrides the script's default on that chart only; it is not written back into the Pine Script source. Copy the code or share the file, and whoever runs it next gets the values in the strategy() declaration, not the values you typed into the tab.

TradingView's Pine Script documentation describes each property the same way. Programmers specify the default with an argument in the strategy() declaration statement. Script users can override it with an input in the Settings/Properties tab. To make a cost permanent, write it into the declaration. The commission argument takes one of three types:

Worked example (constructed illustration, not measured data): this declaration writes the MNQ assumptions from the cost example into the script, so they travel with it.

Write every value as a plain number rather than an expression. After saving, apply the script to the chart again. Then open the strategy's Settings/Properties tab and check that it shows the values you declared. A value changed earlier in that tab can hide a declared default. In its limit-order example, TradingView's documentation describes a Reset settings option in the Defaults dropdown at the bottom of the Properties tab, which restores the default declared in strategy().

How much slippage should a backtest use?

No single slippage figure is right for every market. Use a figure in ticks based on your own fills, then check whether the strategy still makes money one tick worse. TradingView's documentation says a small, fixed amount of slippage on every order can help a backtest's results line up more closely with reality. It also warns that too much can make results unrealistically worse, because constant slippage can push fills outside the bar's range.

Slippage in TradingView is a fixed number of ticks applied to the fill prices of market and stop orders, in the unfavorable direction: TradingView's Declaration statements page says the strategy adds the ticks to the fill prices of long orders and subtracts them from the fill prices of short orders. TradingView's Strategy properties help article adds that the setting can be used to account for the spread. A tick is the smallest step a price can move, so convert a price difference to ticks by dividing it by the tick size.

Where the typical difference comes from: your broker's execution reports. For each market or stop order, compare the price when the order was sent with the price it filled at. Look separately at busy periods such as the open or news releases. This page gives no rule-of-thumb figure because none found has a primary source; verify any number you are given against your own broker's fills.

Then run the backtest at 0, 1 and 2 ticks. If the profit disappears at one tick, the strategy's edge is smaller than a normal fill error. Limit orders are a separate case. TradingView's documentation notes that a limit order cannot fill at a worse price than its level. The risk it models for limits is not filling at all, covered under the limit-order fill setting below.

What does pyramiding do to drawdown and trade count?

Pyramiding is the maximum number of entries a strategy may stack in the same position. Raising it lets a strategy add to a trade it already holds. That increases the size at risk, deepens the drawdown when price turns, and multiplies the number of trades in the report.

TradingView's documentation says pyramiding counts the open trades from strategy.entry() calls in a single position. The default of 1 means a strategy can open new positions but cannot add to them with strategy.entry() orders. Users can change the limit with the Pyramiding input in the Settings/Properties tab. The documentation adds two exceptions: strategy.order() ignores pyramiding, and several price-based entry orders filling on the same tick can exceed the limit.

Worked example (constructed illustration, not measured data): an MNQ strategy with pyramiding = 3 buys one contract at 21,500, adds one at 21,510 and another at 21,520. Price reverses and all three exit at 21,480. The losses are 20, 30 and 40 points, 90 points in total, or $180 at $2 per point before costs. With pyramiding = 1, only the first entry exists and the loss is 20 points, or $40. The same reversal costs 4.5 times as much, and the report shows three losing trades instead of one, which also lowers the win rate.

For a prop firm challenge, the largest position a strategy can hold is its pyramiding limit times its order size. That combined position is what hits a daily loss limit or trailing drawdown. Size it from that worst case; see position sizing for prop firm challenges and maximum drawdown.

Fixed quantity or percent of equity: why does compounding inflate a backtest?

A fixed quantity trades the same number of contracts or shares every time. A trade in the first year and a trade in the last year are then measured on the same scale. Percent-of-equity sizing makes each order a percentage of current equity, so profits compound. Early wins make later positions bigger, and a long backtest's dollar totals grow far faster than the strategy's per-trade edge.

TradingView's documentation says a strategy's default order size comes from default_qty_type and default_qty_value, adjustable through the Default order size inputs in the Properties tab. It also says a non-na qty argument in strategy.entry() or strategy.order() ignores those defaults.

Worked example (constructed illustration, not measured data): a $10,000 account takes 200 winning trades in a row. Sized at a fixed amount, every trade makes $100, 1% of the starting account, and the account ends at $30,000. Sized as a percentage of equity, every trade makes 1% of the account as it stands when the trade is placed. Each position is therefore 1% larger than the last, and the account ends at $10,000 × 1.01²⁰⁰ ≈ $73,160. The trades are identical; only the sizing rule differs.

Compounding also moves the risk to the end of the test. A losing streak late in a percent-of-equity backtest costs more dollars than the same streak early on. A prop firm drawdown limit written in dollars does not grow with the account. Percent-of-equity sizing also depends on initial_capital, so declare both explicitly. For comparing a strategy with dollar-based rules, fixed quantity keeps each trade's contribution readable.

What do process_orders_on_close, calc_on_every_tick and the limit-order fill setting change?

These settings change when and at what price the Strategy Tester fills orders, not what the strategy's rules say. process_orders_on_close moves fills by a bar, calc_on_every_tick changes behavior only on live bars, and the limit-order fill setting decides whether touching a limit price counts as a fill.

By default, TradingView's documentation says, a strategy executes once on each bar's closing tick and fills new orders at the open of the following bar. process_orders_on_close = true lets the broker emulator fill orders created on a bar's close on that same closing tick instead. Users can change it with the Order execution delay dropdown in the Settings/Properties tab. Switching it moves every affected entry and exit to a different bar and price.

calc_on_every_tick sets how a strategy executes on realtime bars: with true, the script recalculates on every new tick of an open live bar. Its default is false, and historical bars follow a separate argument, calc_on_every_history_tick, which is also false by default. TradingView's documentation limits that “On history bar tick” setting to Premium and Ultimate plans and to standard chart types, and says a strategy that declares it raises a runtime error where it is not available. A backtest on history can therefore look the same either way while forward-test results differ. A related argument, calc_on_order_fills, adds an execution on each tick where an order fills, on historical and live bars alike, and is false by default.

The setting traders look for as "verify price for limit orders" is the backtest_fill_limits_assumption argument in TradingView's documentation. It sets the number of ticks price must move beyond a limit order's level before the order fills there, 0 by default. The Limit order execution input in the Properties tab can override it. The documentation warns that verified limit orders still fill at their limit price. Fills can then land at times that would not be possible in real trading, especially with a large value.

One more fill setting lives outside the costs: Bar Magnifier. TradingView's documentation says Premium and Ultimate plan users can select High historical bar detail, or declare use_bar_magnifier = true, so fills use lower-timeframe bars where possible. How that changes stop and target fills is explained in TradingView backtest accuracy.

What does Fill orders using standard OHLC change?

Fill orders using standard OHLC makes a strategy on a Heikin Ashi chart fill its orders at real market prices instead of the chart's averaged prices. It changes fill prices only. The strategy's signals still come from the Heikin Ashi candles, and on Renko, range, Kagi, line break and point & figure charts the setting does nothing.

A standard chart draws each bar from prices that really traded: its open, high, low and close, or OHLC. Non-standard charts draw synthetic bars, meaning prices calculated from real prices rather than prices anyone traded at. TradingView's help article Understanding Heikin Ashi charts says Heikin Ashi candles “show the average prices, not the actual prices.” A Heikin Ashi open is the average of the previous Heikin Ashi open and close. A Heikin Ashi close is the average of the real bar's open, high, low and close. TradingView's support article on non-standard charts says “Strategy orders are filled using the chart's OHLC values.” On a Heikin Ashi chart, the Strategy Tester can therefore fill an order at a price that never traded.

TradingView has given the fix several names. Its release blog of 30 June 2023 introduced it as Fill orders using standard OHLC, disabled by default. Its Strategy properties help article lists it as Using standard OHLC, in the Fill orders group. The Pine Script Strategies guide now describes choosing Standard bars from the Heikin Ashi mode input in the Settings/Properties tab. In code, the same switch is fill_orders_on_standard_ohlc = true in the strategy() declaration.

Worked example (constructed illustration, not measured data): a 5-minute MNQ bar really opens at 21,488.00, trades between 21,484.00 and 21,512.00, and closes at 21,508.00. The Heikin Ashi candle before it opened at 21,462.00 and closed at 21,478.00.

By default, TradingView fills an order created at a bar's close at the next bar's open. On the Heikin Ashi chart, a market buy therefore fills at 21,470.00. The market really opened at 21,488.00, 18 points higher. At $2 per point, that is $36 per MNQ contract the backtest keeps and a real account never gets. A buy limit at 21,475.00 is a bigger problem. The Heikin Ashi low of 21,470.00 reaches it, so the backtest fills it. The real low was 21,484.00, so nobody traded at 21,475.00 during that bar.

With the option on, the same market buy fills at the real open of 21,488.00, and the limit at 21,475.00 does not fill. TradingView's Strategy properties article shows the effect on a real chart. An order on a daily AAPL Heikin Ashi chart filled on 25 September 2023 at a synthetic 175.61 USD, and at 174.20 USD once Using standard OHLC was enabled.

What the option does not change is the signal. TradingView's support article says “a strategy can be calculated on the data from a Heikin Ashi chart, but still open and close positions based on non-synthetic data from a standard chart.” A rule such as “buy when a Heikin Ashi candle closes above its open” still reads the averaged candle; only the fill price becomes real. TradingView's Pine Script FAQ words it differently, saying the argument makes the strategy “calculate on standard chart data.” Compare the trade list with the option off and on rather than assuming which description fits your script.

Renko, range, Kagi, line break and point & figure charts cannot be fixed the same way. TradingView's Pine Script FAQ says these chart types “form new price units based on price movement only and omit the element of time.” It adds that the option “has no effect on other non-standard chart types, because they use non-standard time as well as price.” TradingView's 2023 release blog also says Renko backtests keep filling at the synthetic chart prices, whatever the setting. TradingView's support article explains why Heikin Ashi is the exception: every regular bar has exactly one Heikin Ashi bar. A Renko brick has no single real bar behind it to take a fill price from. The only fix is to rebuild and test the strategy on a standard chart.

This matters before you upload to Tradelyze. Tradelyze re-runs your script on the OHLCV price file you upload. Its Upload Market Data step asks for candle data “for the same instrument and timeframe as your strategy.” If that file holds standard candles, a script written for Heikin Ashi or Renko bars reads real candles in the re-run. Its signals can fire on different bars, and its fills use real prices. Trades that do not line up count as TV Only and BT Only on the Conversion Result card and lower the Match Rate. Trades that do line up can still show different profits. So do not expect a backtest run on Heikin Ashi or Renko prices to match a Tradelyze re-run on standard candles.

Two points are not verified. Tradelyze's strategy() declaration reader does not list fill_orders_on_standard_ohlc among the settings it reads. Whether the backtester behind it applies the argument anyway was not checked. Whether a chart-data download taken from a Heikin Ashi chart holds real or averaged prices was not checked either. The safe route avoids both questions:

1. Switch the TradingView chart to standard candles before you backtest.
2. If the strategy needs Heikin Ashi candles, calculate their open and close inside the script from real prices, using the formulas in the table. The rules then read smoothed values while the chart, the fills and the price file stay on real prices.
3. Run the backtest again, export the trade list, and download price data from the same standard chart, as described in exporting TradingView trades and price data. Upload both with the saved script.

How do costs move the breakeven win rate and profit factor?

Costs are subtracted from every winning trade and added to every losing trade, so they shrink the average win and grow the average loss at the same time. That raises the win rate a strategy needs to break even and pulls its profit factor toward 1.0. The effect is largest when the average trade is small compared with the cost.

Worked example (constructed illustration, not measured data): 100 trades win 55 times. Before costs, every win is $100 and every loss is $100. After $10 of costs per round trip, every win nets $90 and every loss costs $110.

The size of the average trade decides how much costs matter. With $1,000 wins and losses, the same $10 cost gives $990 and $1,010, and the breakeven win rate only moves from 50% to 50.5%. Short-term strategies with small targets feel costs most. The formulas are explained further in win rate and expectancy and profit factor.

Why must strategy properties match before you upload to Tradelyze?

Tradelyze re-runs your strategy with the defaults written in its strategy() declaration and input() calls, not with values changed in TradingView's Properties or Inputs tabs. If a property was changed only in TradingView, the trades you exported came from a strategy the uploaded file does not describe, and Tradelyze's re-run will not reproduce them.

Tradelyze's Strategy Options step, step 4 of the new-strategy wizard, says so on screen. Initial capital, commission, slippage, order size, pyramiding and input values are all taken from the script's strategy() header and input() defaults. It asks anyone who changed these in TradingView's Properties or Inputs tab before exporting to update the defaults in the script and upload it again. The step has no cost fields to fill in, and Tradelyze's backtester reads costs from the declaration inside the uploaded script and nowhere else.

In a Tradelyze report, trades that do not line up are counted as TV Only or BT Only on the Conversion Result card and lower the Match Rate. When too few trades match, the run halts on an Optimization stopped card with Continue anyway and Review comparison buttons. The card warns that continuing optimizes the strategy as it was re-run, so every number describes that build rather than the one your TradingView export came from. Fix the script instead; when Continue anyway is reasonable covers the exceptions.

A cost-only difference can hide: commission changes profits without moving a single entry time. Compare Final Value and PnL % in the Backtest Metrics on the Conversion Result card with the net profit in TradingView's report as well. The other causes of mismatched trades, such as timezones and price-data ranges, are covered in why re-run trades do not match TradingView.

1. Open the strategy's Settings/Properties and Inputs tabs in TradingView and note every value.
2. Write each value into the script's strategy() declaration and input() defaults as a plain number.
3. Save the script, apply it to the chart again, and check that the Settings/Properties tab shows the values you wrote.
4. Export the trade list from that run, as described in exporting TradingView trades and price data.
5. Upload the saved script and that trade list together.

Frequently asked questions about TradingView strategy properties

Questions about Tradelyze accounts, results and credits are answered in the Learn FAQ.

Sources

• TradingView, Pine Script User Manual, “Strategies” (Concepts section): sections Properties tab, Adjusting historical bar detail, Pyramiding, Position sizing, Currency, calc_on_every_tick, calc_on_order_fills, calc_on_every_history_tick, process_orders_on_close, Commission, Slippage and unfilled limits, Margin and leverage, and Backtesting and forward testing, and the notice on non-standard charts. tradingview.com/pine-script-docs/concepts/strategies, re-fetched and re-checked 16 September 2026.
• TradingView, Pine Script User Manual, “Declaration statements” (Language section), the strategy() parameters: pyramiding default 1; slippage default 0, applied to the fill prices of all market and stop orders, added for long orders and subtracted for short ones; backtest_fill_limits_assumption default 0; default_qty_type default strategy.fixed and default_qty_value default 1; initial_capital default 1000000 and currency default currency.NONE; commission_type default strategy.commission.percent and commission_value default 0; margin_long and margin_short default 100. tradingview.com/pine-script-docs/language/declaration-statements, retrieved 16 September 2026.
• TradingView Help Center, “Initial capital”, article 43000777193: a default of 1,000,000 when no value is given in the settings or code, in the currency of the chart’s symbol. tradingview.com/support/solutions/43000777193, retrieved 16 September 2026.
• TradingView, Pine Script User Manual, FAQ, “Strategies”: entry “Why is backtesting on Heikin Ashi and other non-standard charts not recommended?” tradingview.com/pine-script-docs/faq/strategies, re-fetched and re-checked 16 September 2026.
• TradingView Help Center, “Strategy produces unrealistic results on non-standard chart types (Heikin Ashi, Renko, etc.)”, article 43000481029. tradingview.com/support/solutions/43000481029, re-fetched and re-checked 16 September 2026.
• TradingView Help Center, “Strategy properties”, article 43000628599: the Fill orders section, the 1,000,000 initial-capital default, and the statement that the slippage value in ticks is added to the fill price of market or stop orders and “can be used to account for the spread”. tradingview.com/support/solutions/43000628599, re-fetched and re-checked 16 September 2026.
• TradingView Help Center, “Understanding Heikin Ashi charts”, article 43000619436. tradingview.com/support/solutions/43000619436, retrieved 15 September 2026.
• TradingView Blog, “New features in Pine Script™: realistic backtests on Heikin Ashi charts, built-ins to access symbol info, and more”, 30 June 2023. tradingview.com/blog, retrieved 15 September 2026.
• TradingView, Pine Script v6 Reference Manual, strategy() entry: tradingview.com/pine-script-reference/v6. The page renders with JavaScript and is not quoted on this page; the User Manual's Declaration statements page, cited above, names every strategy() parameter default and every commission and quantity constant used here.
• Tradelyze implementation, reviewed 14 September 2026 and 15 September 2026: the Strategy Options step of the new-strategy wizard and its on-screen text; custom backtest options switched off so runs use the Pine Script's own defaults; the backtester reading costs from the strategy() declaration inside the uploaded script; the strategy() arguments the declaration reader recognizes, a list that does not include fill_orders_on_standard_ohlc; the Upload Market Data step's request for candle data for the same instrument and timeframe as the strategy; the Optimization stopped card; the Conversion Result card labels; and the futures lookup table values for MNQ (point value 2, tick size 0.25) and ES (point value 50, tick size 0.25).
• Worked examples on this page (per-trade costs, slippage conversions, pyramiding, compounding, the Heikin Ashi bar, breakeven win rate and profit factor) and the numbers in Figure 1 are constructed illustrations, not measured data. No primary source was found for a general rule-of-thumb slippage figure, or for how many ticks of slippage to add for the bid-ask spread, so neither is given.