The four parameters that decide your backtest
Costs in Pine live in the strategy() declaration, not in the logic. A
strategy with perfect entries and no costs configured is not an optimistic
backtest — it is a backtest of a market that does not charge you to trade.
| Parameter | What it sets | Values [1] |
|---|---|---|
commission_value | cost per trade | a number, interpreted by commission_type |
commission_type | how that number is read | strategy.commission.percent or strategy.commission.cash_per_contract |
slippage | price movement between placing and filling | ticks, not points or currency |
initial_capital | starting funds | a number |
A real declaration, with all four set:
strategy("My strategy", initial_capital = 10000.0,
commission_type = strategy.commission.percent, commission_value = 0.1,
slippage = 3)
Two of these are misread constantly.
slippage is in ticks [1]. Not pips, not currency, not percent. A tick is
the instrument's minimum price increment, so the same number means very
different things on EURUSD and on an index CFD. Getting this wrong by a factor
of ten is easy and quiet.
commission_type changes what commission_value means entirely. With
strategy.commission.percent, commission_value = 0.1 is a tenth of a percent
of trade value. With strategy.commission.cash_per_contract the same 0.1 is
ten cents per unit. Set one and assume the other and the backtest is wrong by
orders of magnitude.
Position size is part of the cost picture
default_qty_type takes strategy.fixed — a constant number of contracts — or
strategy.percent_of_equity, a share of available capital [1].
default_qty_value is the number that pairs with it.
That choice decides whether your equity curve compounds. Percent-of-equity compounds and will make a mediocre edge look dramatic over a long backtest; fixed size does not, and is the harder test to pass.
Execution controls that change results without changing logic
| Parameter | Effect [1] |
|---|---|
pyramiding | maximum simultaneous entries from strategy.entry() — defaults to 1 |
process_orders_on_close | fills at bar close instead of the next open |
calc_on_order_fills | recalculates on fills, enabling intrabar execution |
pyramiding defaulting to 1 is worth knowing before debugging "why did my
second entry not fire". It was not your condition; it was the declaration.
One official warning worth repeating
TradingView states plainly that non-standard chart types produce unrealistic results by default, and that standard charts should be used for realistic backtesting [1]. Heikin Ashi and Renko charts in particular will produce an equity curve that cannot be reproduced with real fills.
Choosing values you can defend
There is no correct commission number to copy. Spreads, commissions and typical slippage differ by broker, by instrument and by account tier, so any figure published here would be wrong for most readers in a way they could not see. What transfers is the method.
Take the numbers from your own account, not from an article. Your broker publishes its commission schedule and typical spread per instrument. That is the input. If you cannot find it, that is itself worth knowing before risking capital.
Set slippage from the instrument's tick size, not from a habit. Slippage is in ticks [1], so start from what one tick is worth on the instrument you are testing, then decide how many ticks a realistic fill costs you at the size and session you actually trade.
Test the strategy at more than one cost level. This is the step that separates an edge from an artefact. Run the same strategy at your expected costs, and again at roughly double. A strategy that survives both is interesting. A strategy that only works at the lower figure is telling you its entire result is the cost assumption.
Reading the result honestly
Two questions to ask of any backtest once costs are in:
How much of the profit did costs consume? Compare net to gross. A strategy whose costs eat most of a small gross edge is a strategy whose result depends on getting better fills than you will get.
Does the trade count make sense for the cost model? Costs scale with frequency. A high-frequency result is far more sensitive to a small error in slippage than a position-trading result — so a scalping strategy needs the tighter cost estimate, which is exactly the case where the estimate is hardest.
The academic point, stated carefully
The surveyed evidence on technical trading rules finds the picture much weaker once transaction costs are accounted for [2]. That is the finding, and it is worth citing precisely because it is inconvenient: not that rules never work, but that results before costs are not evidence of anything.
This is the reason the cost parameters are worth more attention than the entry logic they sit above.
Tactix AI on this workflow
AlfaTactix includes Tactix AI: use Tactix Studio to describe your idea in plain language and draft timeframes, signals, filters, and risk into the same six-step Strategy Builder form — or open Tactix Guide on any step when you only need a field explained. Review every value, then export MQL5 or Pine Script from Code Generator (form-first — not untested prompt-to-code).