Summary
When commission_type=strategy.commission.cash_per_contract is set, PyneCore charges the cash-per-contract commission on the entry order only. The exit order is not charged. For a round-trip $1.70/side strategy, PyneCore reports $1.70 commission per trade instead of the expected $3.40 (both legs).
Filing for verification — would appreciate confirmation that the intended behavior is to charge both legs.
Reproduction
Minimal script:
from pynecore.lib import strategy
@strategy("cash_per_contract_repro",
default_qty_value=1,
commission_type=strategy.commission.cash_per_contract,
commission_value=1.70)
def main():
if bar_index == 100:
strategy.entry("L", strategy.long)
if bar_index == 200:
strategy.close("L")Expected commission per round-trip trade per Pine v6 docs: 1 * 1.70 + 1 * 1.70 = $3.40. Observed in PyneCore output: $1.70. Delta: $1.70 per round-trip (50% under-report).
Suspected location
pynecore/lib/strategy/__init__.py — fill-handling path. The exit-fill code path appears not to invoke the commission deduction that the entry-fill path does for cash_per_contract. (The percent-commission path was found to have the inverse problem in #48 — it has now been fixed in v6.4.5; cash_per_contract may share related fill-path logic worth checking.)
Proposed fix direction
The exit-fill commission deduction for cash_per_contract should match the entry-fill deduction: commission_charged += filled_qty * commission_value on both legs.
Workaround currently in use
Post-trade analyzer adds the missing exit-side commission:
# both legs
commission_usd = 2 * commission_value * size
Validation evidence
Discovered during NQ 1m strategy validation alongside the futures-PnL pointvalue issue. With both workarounds applied (pointvalue multiplier + dual-side commission), PyneCore output matches TradingView strategy tester within tolerance for identical Pine source.
Verification request
Could you confirm whether this is a bug or whether cash_per_contract is intended to charge only the entry leg? If the latter, please point us at the docs so we can update our integration.
Environment
Related
Discovered alongside #48 (percent-commission, fixed in v6.4.5) and the futures-PnL pointvalue issue filed separately. Together with the pointvalue issue, this makes PyneCore's PnL output for futures strategies essentially unreliable without consumer-side correction.
Summary
When
commission_type=strategy.commission.cash_per_contractis set, PyneCore charges the cash-per-contract commission on the entry order only. The exit order is not charged. For a round-trip $1.70/side strategy, PyneCore reports $1.70 commission per trade instead of the expected $3.40 (both legs).Filing for verification — would appreciate confirmation that the intended behavior is to charge both legs.
Reproduction
Minimal script:
Expected commission per round-trip trade per Pine v6 docs:
1 * 1.70 + 1 * 1.70 = $3.40. Observed in PyneCore output:$1.70. Delta: $1.70 per round-trip (50% under-report).Suspected location
pynecore/lib/strategy/__init__.py— fill-handling path. The exit-fill code path appears not to invoke the commission deduction that the entry-fill path does forcash_per_contract. (The percent-commission path was found to have the inverse problem in #48 — it has now been fixed in v6.4.5; cash_per_contract may share related fill-path logic worth checking.)Proposed fix direction
The exit-fill commission deduction for
cash_per_contractshould match the entry-fill deduction:commission_charged += filled_qty * commission_valueon both legs.Workaround currently in use
Post-trade analyzer adds the missing exit-side commission:
Validation evidence
Discovered during NQ 1m strategy validation alongside the futures-PnL pointvalue issue. With both workarounds applied (pointvalue multiplier + dual-side commission), PyneCore output matches TradingView strategy tester within tolerance for identical Pine source.
Verification request
Could you confirm whether this is a bug or whether
cash_per_contractis intended to charge only the entry leg? If the latter, please point us at the docs so we can update our integration.Environment
Related
Discovered alongside #48 (percent-commission, fixed in v6.4.5) and the futures-PnL pointvalue issue filed separately. Together with the pointvalue issue, this makes PyneCore's PnL output for futures strategies essentially unreliable without consumer-side correction.