You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
default_qty_type = strategy.percent_of_equity above 100 with margin_long = 0: TradingView sizes the order at 100% of equity, PineForge at the full percentage #805
With margin_long = 0 and a default order size above 100% of equity, TradingView fills the same quantity as it does for 100%: the scripts with 150, 1000 and 10000 give the trade list of the script with 100. PineForge sizes the order at the full percentage.
TradingView's documentation describes margin 0 as no margin requirement, so this is a measured difference, not a documented rule. It applies to percent-of-equity sizing only: an explicit qty above equity fills in full on both sides, and with margin_long = 50 the 150% script gives the same quantities on both sides.
Versions
pineforge-engine v1.11.0 (a4472324) with pineforge-codegen 1.11.0, and v1.10.0 with Codegen 1.10.0: the same trade lists on both. Apple clang 17.0.0, macOS 15.8 arm64. BTCUSDT 1h bars from 2024-01-01 to 2024-03-01 (1,441 bars), initial capital 10000, no commission or slippage, mintick 0.01, qty_step and mincontract 0.00001, input timeframe = script timeframe = 1h.
TradingView: BINANCE:BTCUSDT, 1h, Deep Backtesting over the same dates, measured on 2026-11-10.
The other rows change only default_qty_value, the two margin arguments, or replace the default size with qty = 1 on the entry.
First entry, 2024-01-04 17:00 at 43915.70 (equity 10000, so 100% is 0.22770):
default_qty_value, margin
TradingView
PineForge
100, margin 0
0.22770
0.22770
150, margin 0
0.22770
0.34156
1000, margin 0
0.22770
2.27708
10000, margin 0
0.22770
22.77089
150, margin 50
0.34156
0.34156
qty = 1 on the entry, margin 0
1
1
Whole run:
TradingView gives 26 trades for every row (25 closed, one open at the end of the range). The four margin-0 percentage rows have identical trade lists, e.g. the second entry is 0.22397 in all four.
PineForge equals TradingView in all 25 closed trades for the rows 100, margin 0, 150, margin 50 and qty = 1.
PineForge with 150, margin 0 gives 26 trades at 150% of equity (second entry 0.33328), the same list as its 150, margin 50 run.
PineForge with 10000, margin 0 gives one trade: 22.77089 loses 15705.31, equity is negative, and no later entry fills.
On TradingView the strategy's Properties showed order size 150% of equity and margin for long positions 0 for the 150, margin 0 script. Changing only that margin field from 0 to 1 on the same script instance made the first entry 0.34156.
Expected
For percent-of-equity sizing with margin 0, the quantities TradingView fills (100% of equity in these runs).
Workaround
Declare a non-zero margin that allows the intended size (for 150%, margin_long = 50), or keep default_qty_value at 100 or below.
Thank you for the report and the script. It is received and in triage: we are reproducing it on your script and comparing against TradingView. I will post the result here, confirmed or not and with the planned fix version, by 2026-11-11 12:00 (Taipei time). If it is confirmed as a wrong value that ships in a released version, the release notes will say so with a workaround.
Trigger: default_qty_type = strategy.percent_of_equity with default_qty_value above 100 and margin_long = 0 (margin_short = 0). Affected versions: reproduced on 1.11.0; the reporter sees the same trade lists on 1.10.0. Effect: PineForge sizes the order at the declared percentage (150 percent of 10000 gives 0.34156 BTC at the first entry of the reporter's run); TradingView, as the reporter measured, fills the quantity of 100 percent (0.22770). With 10000 percent PineForge opens one trade that loses 15705 and then cannot enter again. Workaround: keep default_qty_value at 100 or below (PineForge then gives 0.22770 and 26 trades, as TradingView does), or declare a margin that allows the intended size, for example margin_long = 50 for 150 percent (PineForge gives 0.34156, as TradingView does according to the reporter). Plan: we are measuring the rule on TradingView ourselves before changing the sizing; this difference stays listed until then.
Checked on the 1.12.0 release (engine v1.12.0 6e27d0f2, pineforge-codegen 1.12.0), built from source on macOS 15.8 arm64, with the scripts from this issue (BTCUSDT 1h, 2024-01-01 to 2024-03-01, capital 10000, no commission).
150%, 1000% and 10000% of equity with margin_long = 0: 26 trades each, first entry 0.22770, the same list as the 100% control and as TradingView (1.11.0: first entry 0.34156, 2.27708 and 22.77089).
The two reference scripts are unchanged: margin 50 still enters 0.34156, and an explicit qty = 1 still enters 1.
Activity
luisleo526 commentedon Nov 10, 2026
Thank you for the report and the script. It is received and in triage: we are reproducing it on your script and comparing against TradingView. I will post the result here, confirmed or not and with the planned fix version, by 2026-11-11 12:00 (Taipei time). If it is confirmed as a wrong value that ships in a released version, the release notes will say so with a workaround.
luisleo526 commentedon Nov 10, 2026
Result (2026-11-10): confirmed.
Trigger: default_qty_type = strategy.percent_of_equity with default_qty_value above 100 and margin_long = 0 (margin_short = 0). Affected versions: reproduced on 1.11.0; the reporter sees the same trade lists on 1.10.0. Effect: PineForge sizes the order at the declared percentage (150 percent of 10000 gives 0.34156 BTC at the first entry of the reporter's run); TradingView, as the reporter measured, fills the quantity of 100 percent (0.22770). With 10000 percent PineForge opens one trade that loses 15705 and then cannot enter again. Workaround: keep default_qty_value at 100 or below (PineForge then gives 0.22770 and 26 trades, as TradingView does), or declare a margin that allows the intended size, for example margin_long = 50 for 150 percent (PineForge gives 0.34156, as TradingView does according to the reporter). Plan: we are measuring the rule on TradingView ourselves before changing the sizing; this difference stays listed until then.
Merge the engine 1.11.1 train into the percent default quantity cap
Merge the engine 1.11.1 train into the percent default quantity cap a…
luisleo526 commentedon Nov 11, 2026
Fixed on the engine main branch in 360c4ab (#825). It will be in the next engine release.
letiep97 commentedon Nov 13, 2026
Confirmed fixed in 1.12.0, thank you.
Checked on the 1.12.0 release (engine v1.12.0
6e27d0f2, pineforge-codegen 1.12.0), built from source on macOS 15.8 arm64, with the scripts from this issue (BTCUSDT 1h, 2024-01-01 to 2024-03-01, capital 10000, no commission).margin_long = 0: 26 trades each, first entry 0.22770, the same list as the 100% control and as TradingView (1.11.0: first entry 0.34156, 2.27708 and 22.77089).qty = 1still enters 1.