v6.4.5 percent-of-equity sizing still produces large per-trade PnL drift vs TradingView

[Zombajo]

Summary

Following the v6.4.5 fix for issue #48 (percent-commission underreport on entry fills, thank you for the fast turnaround), we re-validated against TradingView strategy tester output across multiple strategy shapes. Fixed-qty + percent commission now reconciles cleanly (499/517 trades within $0.10 on BTCUSDT.P 30m 2024). However, percent-of-equity sizing + percent commission still shows large divergence: only 5/517 trades within $0.10, with cumulative PnL drift up to several percent of starting equity over a year.

The merge note for v6.4.5 indicated the entry-fill formula now matches "exit-fill and position-sizing behavior," which we read as full consistency across the three commission code paths. We expected percent-of-equity to reconcile cleanly on v6.4.5 without our previous post-trade R5 correction. It does not. Filing for verification — there may be a separate bug in the percent-of-equity sizing path that is independent of the commission formula consistency.

Reproduction

Same Pine source as the fixed-qty test that now passes, with one change:

//@version=6
strategy("pcteq_repro",
         default_qty_type=strategy.percent_of_equity,
         default_qty_value=10,
         commission_type=strategy.commission.percent,
         commission_value=0.055)

ema5  = ta.ema(close, 5)
ema21 = ta.ema(close, 21)
if ta.crossover(ema5, ema21)
    strategy.entry("L", strategy.long)
if ta.crossunder(ema5, ema21)
    strategy.close("L")

Run on BTCUSDT.P 30m calendar year 2024. Compare PyneCore output vs TradingView strategy tester for the same source/data.

Result on v6.4.5: 5 of 517 trades within $0.10 of TV per-trade PnL. Cumulative PnL difference grows over the year, consistent with a compounding sizing-path divergence rather than a constant per-trade offset.

For comparison, the same script with default_qty_type=strategy.fixed, default_qty_value=1 and otherwise identical settings reconciles cleanly on v6.4.5 (499/517 within $0.10).

Suspected location

Earlier inspection (pre-v6.4.5) suggested two distinct percent-commission code paths: an execution path at strategy/__init__.py:821 (fixed in v6.4.5) and a sizing path at strategy/__init__.py:1961-1964. The v6.4.5 commit appears to harmonize the formula across these paths.

If the formulas now match, the residual percent-of-equity divergence likely comes from one of:

• An order in which equity is updated relative to commission deduction (sizing computed against pre-commission equity vs post-commission equity)
• Compounding: per-trade qty is determined from current equity, so even a small per-trade error grows over the year as equity drifts
• A different rounding or lot-size convention applied in the sizing path that doesn't apply on entry-fill

Validation evidence

Reconciliation report at research/pynecore_verification/STAGE_V645_VALIDATION.md (we'll attach if helpful — full per-trade table with PyneCore PnL, TV PnL, delta, applied qty per side, applied commission per side).

Test environment:

• PyneCore version: 6.4.5
• Python: Python 3.13.7
• OS: Windows 11
• Data: BTCUSDT.P 30m 2024 (Binance perpetual)
• DST-aware Europe/Sofia → UTC conversion applied to TV timestamps

Verification request

Could you confirm whether percent-of-equity is expected to reconcile within tolerance against TV on v6.4.5, and if so, where to look for the residual gap? If percent-of-equity is known to have additional sizing-path semantics that differ from TV (e.g., different equity-update timing), please point us at the docs so we can align our integration.

Related

• Percent commission underreported on entry fills — sizing path uses correct formula, execution path uses buggy formula #48 (entry-fill percent-commission, fixed in v6.4.5 — thanks)
• Three additional issues in flight: barstate.isconfirmed under request.security, futures pointvalue not multiplied, cash_per_contract single-leg