DEV Community

Tyler Francis
Tyler Francis

Posted on

Modeling Prop Firm Trailing Drawdown in Pine Script (So Your Backtest Stops Lying)

#pinescript #trading #tutorial #fintech

If you write TradingView strategies for futures prop firm accounts (Apex, Topstep, MyFundedFutures), there's a structural problem with your backtest: Pine Script's strategy() framework evaluates terminal equity, but prop firms evaluate a path-dependent constraint called trailing drawdown. A strategy can be profitable in the Strategy Tester and still fail evals consistently. Here's how to model the constraint correctly.

What trailing drawdown actually does

On most futures firms, your drawdown floor ratchets up with your account's high-water mark — and on many firms, that high-water mark includes unrealized profit. If you're up $600 open on a trade and it stops out at breakeven, your closed P&L is unchanged but your drawdown floor moved up $600 permanently. The backtest sees a scratch. The eval sees lost cushion.

Step 1: Track the unrealized high-water mark 

//@version=6
strategy("Eval-Aware Backtest", overlay=true,
     initial_capital=50000, commission_type=strategy.commission.cash_per_contract,
     commission_value=0.67, slippage=1)

float liveEquity = strategy.equity

var float hwm = strategy.initial_capital
hwm := math.max(hwm, liveEquity)
Enter fullscreen mode Exit fullscreen mode

strategy.equity in Pine already includes open profit, which is what we want for the high-water mark approximation. Run this on 1-minute bars for the closest approximation to tick-level ratcheting.

Step 2: Compute the trailing floor and breach condition 

float trailDD = 2500.0  // 50k account, typical
float floorLevel = hwm - trailDD

float floorCapped = math.min(floorLevel, strategy.initial_capital + 100)

bool breached = liveEquity <= floorCapped
var bool evalFailed = false
if breached
    evalFailed := true
    strategy.close_all(comment="DD BREACH")
Enter fullscreen mode Exit fullscreen mode

Step 3: Gate entries on eval state 

bool profitTargetHit = strategy.equity >= strategy.initial_capital + 3000
bool canTrade = not evalFailed and not profitTargetHit

if canTrade and longSignal
    strategy.entry("L", strategy.long)
Enter fullscreen mode Exit fullscreen mode

Once evalFailed flips, the account is dead — letting the backtest keep trading after a breach is the single most common way Pine backtests overstate eval performance.

Step 4: Report what matters 

var table t = table.new(position.top_right, 1, 3)
if barstate.islast
    table.cell(t, 0, 0, evalFailed ? "EVAL FAILED" : profitTargetHit ? "EVAL PASSED" : "IN PROGRESS")
    table.cell(t, 0, 1, "Floor: " + str.tostring(floorCapped, "#.00"))
    table.cell(t, 0, 2, "Cushion: " + str.tostring(liveEquity - floorCapped, "#.00"))
Enter fullscreen mode Exit fullscreen mode

Net profit is now a secondary metric. The number you optimize is whether the path ever touched the floor.

What changes when you do this

When I retrofitted this onto a library of strategies that all looked fine in the standard tester, about two-thirds failed simulated evals. The failures clustered: strategies with high MAE relative to target, and strategies with win rates under 40%.

The survivors — low MAE, 40-60% win rate, hard daily-loss gating — are a genuinely different population than "most profitable backtest." That's the core insight: the eval is a different objective function, and you have to encode it.

Run your own strategies through this harness before paying for another evaluation. If you'd rather start from strategies already built and validated against these exact constraints — with full source code so you can verify everything — that's what I sell at propfirmpinescripts.com, alongside free tools (drawdown calculator, eval simulator) that run this math in the browser.

Top comments (0)