Title here
Summary here
Alignment with TradingView
Whale‑E follows TradingView’s calculation and backtesting conventions wherever possible. The goal is not to promise exact parity in every case, but to keep the engine consistent and deterministic. With the same settings and the same test context, you will usually get the same signals, trades, and results, subject to the documented limits on this page.
What alignment with TradingView covers
Alignment with TradingView means that Whale‑E reproduces the same strategy calculations and the same main backtesting rules when the test setup is equivalent.
That means using at least the same symbol, the same exchange, the same timeframe, the same analysis period, and the same strategy parameters. If even one of those changes, the results can diverge.
Part of Whale‑E’s [backtest] block maps directly to the parameters used by TradingView in the strategy() declaration and in the Strategy Tester settings. When Whale‑E exports Pine Script, it carries those parameters over into the generated script.
| Key | Purpose |
|---|---|
initial_capital | Sets the initial capital for the backtest. |
default_qty_type | Sets the global position sizing mode: fixed, cash, or percent_of_equity. |
default_qty_value | Sets the value used by the selected sizing mode. |
pyramiding | Sets the maximum number of entries that can be stacked in the same direction. |
commission_type | Sets how fees are applied. |
commission_value | Sets the numerical value of those fees. |
backtest_fill_limits_assumption | Sets the condition a LIMIT order must satisfy to be filled. |
slippage | Sets a fixed slippage in ticks. |
margin_long | Sets the margin requirement for long positions. |
margin_short | Sets the margin requirement for short positions. |
process_orders_on_close | Sets whether an order created on a bar close can also be filled on that same close. |
use_bar_magnifier | Enables intrabar evaluation from a lower timeframe. |
close_entries_rule | Sets the rule used to decide which entries are closed. |
Parameters from strategy() that are not listed in this table cannot be configured in Whale‑E and are not exported to the generated Pine Script. As long as those parameters stay at their default TradingView values, they do not break alignment.
Whale‑E-specific backtest settings
Some backtest settings do not have a direct equivalent in TradingView.
auto_slippage_enabled turns on a Whale‑E-specific slippage mode. Once you use it, strict alignment with TradingView no longer applies because TradingView does not provide the same mechanism.
long_size_multiplier and short_size_multiplier are not native TradingView parameters. Whale‑E can still reproduce their effect in the exported Pine Script through the generated logic, so using them remains compatible with alignment.
The end-of-backtest behavior controlled by close_open_position_at_end is explained in the next section.
Valuing open positions at the end of a backtest
At the end of a backtest, a position can still be open. The engine then needs a cutoff point to value that position and compute the final portfolio state.
In Whale‑E, close_open_position_at_end controls that valuation boundary. This parameter is true by default. It applies the engine’s end-of-backtest convention so the final state stays bounded and comparable from one run to another. It does not change the signals, entries, or exits produced during the backtest. It only affects the final valuation of positions, or legs, that are still open when the test ends.
When close_open_position_at_end = false, Whale‑E stops valuing the position at end_date. The executed trades remain the same, but the final metrics can change because open positions are no longer marked beyond that date.
For example, if your backtest ends on January 31 and a long position is still open on that date, Whale‑E can freeze Open P&L on January 31, while TradingView may keep updating it with the later bars still loaded on the chart.
TradingView works on a bounded history, but it may continue to value an open position up to the last bar available on the chart. In this mode, Whale‑E explicitly freezes the final state at end_date. If positions are still open when the test ends and close_open_position_at_end = false, Whale‑E and TradingView can therefore display different final metrics even though the signals, entries, exits, and executed trades are aligned.
The difference first appears in Open P&L. It also affects Total P&L and some metrics derived from portfolio equity, especially max equity drawdown and max equity run-up. By contrast, metrics based only on closed trades, such as Net P&L or Total trades, do not change.
When differences can appear
A difference between Whale‑E and TradingView does not automatically mean that one of the two engines is wrong. In many cases, the gap simply comes from the test setup or from a limitation specific to either Whale‑E or TradingView. Whale‑E stays aligned whenever possible, but it does not change the engine’s execution semantics just to work around an external constraint.
The most common causes are the following:
- The symbol, exchange, timeframe, or analysis period is not exactly the same on both sides.
- TradingView’s “Deep Backtesting” mode uses its own windowing rules and can produce differences relative to Whale‑E.
- TradingView does not always load as much history as Whale‑E. The amount of available history depends in particular on the TradingView account type, while Whale‑E can use the full history provided by the exchange.
- With Bar Magnifier, TradingView limits how much lower-timeframe intrabar data can be used. Whale‑E does not have that same limitation.
- The price values used by TradingView can differ slightly from the ones provided by the exchange used by Whale‑E.
- Market constraints, especially
mincontractandmintick, can differ between TradingView and Whale‑E. The next section explains this point. - Whale‑E’s automatic slippage mode, enabled with
auto_slippage_enabled, has no TradingView equivalent. - Sharpe and Sortino ratios are not designed to replicate TradingView. Whale‑E calculates them from portfolio equity returns observed at each close of the backtest’s native timeframe, then annualizes them so results from different timeframes can be compared consistently.
- Buy-and-Hold can differ between TradingView and Whale‑E because Whale‑E calculates it over the defined backtest period, not over the full chart history currently loaded in TradingView.
Possible misalignment on mincontract and mintick
A mismatch can appear when Whale‑E and TradingView do not use the same market constraints, especially mincontract and mintick. By default, Whale‑E uses the values provided by the exchange. For some symbols, TradingView may apply different values.
That gap changes the quantity that can actually be executed. It can then affect how some positions are entered or exited, lead to different partial margin calls, and shift the entire PnL path as well as the trade sequence.
On OKX:BTCUSDT, for example, Whale‑E uses mincontract = 0.00000001, which matches the exchange value, while TradingView uses mincontract = 0.000001. Quantity rounding therefore happens at a different level, and that initial difference can be enough to shift the entire backtest.
When you run a Pine script exported by Whale‑E in TradingView, you may see an orange label in the top-right corner of the chart. Whale‑E exports the market parameters used during the backtest, namely mincontract, mintick, and pointvalue. If TradingView applies different values for the same symbol, that label warns you that misalignment is possible.
In that case, Whale‑E lets you override the symbol parameters with [[symbol_override]]:
[[symbol_override]]
symbol = "OKX:BTCUSDT"
mincontract = 0.000001Without an override, Whale‑E keeps the exchange parameters. With [[symbol_override]], it applies the values you define. On affected symbols, that makes it possible to reproduce the market constraints used by TradingView.
On spot crypto markets, the difference mainly comes from mincontract and sometimes from mintick. pointvalue is usually 1, so it matters much less often.
Different Sharpe and Sortino calculations from TradingView
In Whale‑E, these two ratios are primarily used to compare and rank optimization results. They are calculated from portfolio equity returns observed at each close of the backtest’s native timeframe.
Whale‑E then annualizes those ratios so strategies running on different timeframes can still be compared on a consistent basis. TradingView uses its own calculation method, notably based on monthly returns. A difference on these two metrics is therefore normal, even when trades and PnL are aligned.
For the full specification, see Metrics.
Different Buy-and-Hold calculation from TradingView
TradingView and Whale‑E do not measure Buy-and-Hold over the same window.
TradingView calculates Buy-and-Hold from the strategy’s first purchase to the last bar available on the chart, while Whale‑E calculates it from the start to the end of the selected backtest period.
Whale‑E works on a strictly bounded window. Outside “Deep Backtesting,” TradingView relies on the bars that are actually loaded on the chart. “Deep Backtesting” follows different rules, and Whale‑E does not align with it.
For this calculation, Whale‑E only compares the start and end prices of its own reference window. Fees, slippage, execution rounding, and quantity flooring are not part of this calculation.
The percentage is the relative price change between those two bounds. The cash return is then derived from that ratio using the initial capital. Whale‑E therefore stays consistent with a benchmark interpretation of Buy-and-Hold while still keeping its own bounded backtest window.