DEV Community: Okeke Jenny

VPS latency is a trading rule, not an infrastructure detail

Okeke Jenny — Tue, 13 Oct 2026 18:34:31 +0000

The connection between your trading terminal and the broker's server is usually filed under "infrastructure". On a prop firm evaluation it is a rule, because several of the rules that end accounts are enforced on time rather than on price. A stop that triggers on your chart and a stop that triggers on the firm's server are two different events, and latency is the distance between them.

This is worth taking seriously because the failure it produces is invisible in a backtest and looks like bad luck in a journal: the price never touched your stop, yet you were stopped out; or the daily loss limit fired and the loss you see is larger than the loss you sized.

The three rules that are actually clocks

Almost every drawdown rule that causes a surprise has a time component:

The daily loss limit reset. It resets at a fixed server time — often the firm's midnight, sometimes the market's daily close in a specific timezone. The exact instant your "day" starts and ends is a server-defined boundary, not the one on your wall clock.
The news window. Restrictions on opening or holding positions are defined as intervals around an event (e.g. "two minutes either side of a high-impact release"). The window is measured on the server's clock.
The maximum trade duration / overnight cutoff. Some programmes require positions to be closed within a session or before a cutoff time. The cutoff is a server timestamp.

If your terminal's clock, your VPS's clock and the broker's clock disagree, a trade you believe is inside the window can be outside it — and there is no "close enough". The rule evaluates a timestamp.

Why a home connection is the wrong reference

Two distinct problems, and it is worth separating them:

Latency. The round-trip time between your terminal and the server. On a routed home connection in a different region this can be tens of milliseconds with high variance. That variance is the issue, not the absolute number: a variable delay means a stop order that arrives late by exactly the amount the price moved in that window, which on a fast instrument during a release can be the difference between a $200 loss and a $600 one.

Timing. Most prop-firm rule enforcement happens server-side, so latency does not change whether the rule fired — it changes the price at which your order filled relative to the trigger. But a home connection with an unstable clock can also change what your terminal thinks the time is, which matters for a manual decision near a cutoff.

A VPS fixes both by placing the client in the same datacentre region as the broker, cutting round-trip time to single-digit milliseconds and removing the domestic-connection jitter.

The arithmetic of a late fill

The reason this matters to the account rather than to comfort is that the loss from a late fill is proportional to size:

extra loss = slippage_per_unit × size (in units)

Take a scenario: during a news release, price moves 8 pips in the 40 ms between your stop triggering and your order reaching the server under a home connection, versus 1 pip on a co-located VPS. On a position where one pip is worth $10:

Home connection: 8 pips × $10 = $80 of slippage on that single exit.
Co-located VPS: 1 pip × $10 = $10.

Neither fills at the stop price, so both are worse than the chart suggests. The difference is $70 on one trade. Repeat it across a strategy that exits several times a day and the VPS is not a luxury — it is a direct reduction in the slippage that eats into a drawdown budget already measured in dollars.

The second-order effect is worse. A stop that fills 8 pips late is 8 pips closer to the floor than planned, and the trader's sizing assumed the planned stop. The trade was correctly sized for one loss and delivered a larger one. Over a series, that drift is exactly what "my account died earlier than my backtest" looks like.

What the firms require

Many firms make a VPS mandatory for automated trading (EAs and bots), for two reasons: to keep the strategy's latency predictable, and to satisfy the firm's own requirement that the client runs continuously. The requirement is usually stated in the automated-trading or technical section of the rules rather than on the pricing page, which is why it surprises traders who read only the marketing.

The practical checklist before running anything automated on an evaluation:

Location. The VPS region should match the broker's server region. Latency is a function of geography, not of how much RAM you bought.
Always-on. The client must not sleep. A dropped connection during an open position is a rule risk (some firms treat a dropped EA as a violation).
Clock sync. NTP synchronisation, so the terminal's timestamps agree with the server's for window-based rules.
Standby power and redundancy. A VPS that reboots on the daily boundary can miss the cutoff. The failure mode is a position held through a window that should have been closed.

What to do this week

Measure your actual round-trip latency to the broker's server, not to a generic internet host, and note the variance over a session.
Find the firm's reset time and news windows in server time, and convert them into the timezone your terminal displays. Put the conversions on the chart.
Price the slippage you are currently paying. If it is a meaningful fraction of your daily drawdown allowance, co-location pays for itself faster than any strategy tweak.
Size from the realistic stop, not the ideal one. If you know your exits slip, the budget should include the slip.

None of this is alpha. It is the difference between a rule that fires on the server at the moment it is written to fire and a rule that fires on your side of the connection at a moment you did not choose. On an account whose entire margin is a few thousand dollars of drawdown, that difference is not infrastructure — it is risk.

The practical setup — which programmes require a VPS, what region to pick for each broker, and how the timing rules are written — is in the VPS requirements breakdown. If you would rather model the cost of slippage on your own sizing before choosing, the prop firm profit calculator works in the same account currency.

Multiple funded accounts are one position, not several

Okeke Jenny — Tue, 13 Oct 2026 18:33:55 +0000

A trader runs three funded accounts at the same firm, same instrument, same strategy, and treats them as three independent shots at a payout. Then a single bad session takes all three at once. The accounts were not three positions. They were one position, tripled, with three drawdown floors reporting the same loss.

The diversification a trader thinks they own from multiple accounts is a function of correlation between the account strategies, not the number of accounts. Getting this wrong is one of the most expensive modelling errors available, because it converts what looks like risk reduction into concentrated risk with three times the fee surface.

Why the independence assumption is so tempting

Three accounts feels safer than one for an obvious reason: three floors means three separate opportunities for at least one to survive. That intuition is correct if the strategies are independent. The arithmetic is the same as any portfolio:

One account, probability of breach on a given day: p.
Three accounts, probability that all breach on a given day: p³ (if independent).

At p = 0.2, that is 0.8% — reassuring. But the same three accounts trading the same strategy on the same instrument in the same session have correlated daily returns. In the limit of perfect correlation, all three breach together:

Three perfectly correlated accounts, probability all breach: p = 20%.

The two scenarios have identical account counts and identical per-account risk. They differ only in correlation, and the difference in joint-breach probability is a factor of twenty-five.

That is the whole point: accounts are not the unit of diversification; strategies are.

Where the correlation actually comes from

It is worth naming the sources, because they are all avoidable and none of them is visible on a dashboard:

Same instrument, same direction. Two accounts long the same index in the same session is one bet, expressed twice.
Same strategy, same signals. A mean-reversion system run on three accounts generates the same entries. The trades are duplicates.
Same session. Two different edges traded in the same overlapping hours share the market regime, and regimes are the dominant risk factor.
Same firm's shared constraint. If the firm applies a portfolio-level or per-trader rule, three accounts at one firm are not even independent at the rule level.

Only the first is obvious. The second and third are the ones that actually bite, because a trader running a breakout strategy on three accounts in the same 90-minute window is, mechanically, running one breakout strategy at triple size.

The measurable version

If you keep trade logs per account, the correlation is computable and it is not hard:

// Pearson correlation of daily returns between two accounts.
function corr(a, b) {
  const n = Math.min(a.length, b.length);
  const ma = mean(a.slice(0, n));
  const mb = mean(b.slice(0, n));
  let num = 0, da = 0, db = 0;
  for (let i = 0; i < n; i++) {
    const xa = a[i] - ma;
    const xb = b[i] - mb;
    num += xa * xb;
    da += xa * xa;
    db += xb * xb;
  }
  return num / Math.sqrt(da * db);
}

function mean(xs) {
  return xs.reduce((s, x) => s + x, 0) / xs.length;
}

Run it on the daily P&L of account A against account B. A value near 1.0 means the two accounts are one position. A value near 0 means the second account is genuinely diversifying. Most "multiple accounts" setups measure above 0.8, which is why the downside arrives correlated even when the accounts look independent on paper.

For more than two accounts, the object you want is the correlation matrix, and the useful summary is its largest eigenvalue: if one factor explains most of the variance, you have one strategy wearing several hats.

The consequences for drawdown

Correlation does not just change the probability of a joint breach. It changes the shape of the loss you have to survive:

Independent accounts: losses arrive at different times. One account can be funded and paying while another is recovering. The equity curve of the portfolio of accounts is smooth.
Correlated accounts: losses arrive together. Every account is down on the same day, against floors that are all measured from peaks that all rose together. The worst day in one account is the worst day in all of them.

Because drawdown is a function of the worst path, not the average, correlated accounts concentrate exactly the event that ends them. The trailing-floor mechanic makes this worse: a good run raises all three floors simultaneously, so all three accounts are at maximum vulnerability at the same moment.

What to do about it

None of this means multiple accounts are a mistake. It means the diversification has to be engineered rather than assumed:

Measure the correlation before adding the third account. Two accounts at 0.9 are one account with double fees.
Diversify the strategy family, not the instrument. Two correlated instruments (an index and its futures) are not diversifying; an intraday momentum system and an overnight mean-reversion system may be.
Stagger the session, not just the signal. If both accounts trade the same hours, they share the regime.
Check the firm's portfolio-level rules. Some firms cap aggregate risk across a trader's accounts, which makes the accounts correlated by policy regardless of strategy.
Reserve the uncorrelated account for the worst day. The value of the second account is highest when it is the one not in the drawdown. That only happens if it holds a different bet.

A funded account is a small business with a hard floor. Running three of them is running three businesses — and three businesses selling the same thing in the same market on the same day are one business with three sets of overheads. Correlation is the number that tells you which you have.

The practical firm-level detail — per-trader account caps, whether one firm's accounts share a risk limit, and how the rules treat multiple accounts at the same or different firms — is in the multiple accounts at one firm breakdown.

Weekend holding: what an overnight gap does to a funded account

Okeke Jenny — Tue, 13 Oct 2026 18:33:20 +0000

Here is a rule that costs more accounts than almost any other and gets discussed the least: what happens to an open position between Friday's close and Monday's open. Many prop firms restrict or forbid holding across the weekend. The restriction is easy to read and easy to ignore, because a backtest rarely tells you it exists — and because the strategy that violates it often looks better than one that respects it.

This is about the gap: why overnight and weekend exposure is a different instrument from intraday exposure, and how to decide whether your edge can live inside the rule.

The gap is not a bigger candle

An overnight gap is a discontinuity, and discontinuity behaves differently from volatility in one specific way: it cannot be stopped out at a price.

Consider a long on an instrument that closes at $1.0000 on Friday. Over a weekend, news moves the open to $0.9800 on Sunday night. A stop at $0.9950 did not get you out at $0.9950. It got you out at the first available price, which is $0.9800 — 150 pips below your intended exit, on a single bar, with no chance to react.

That difference matters most in exactly the situation a funded account is most vulnerable: right after a good run. A trader who is up $6,000 on a $50,000 account with a $2,500 trailing floor has a floor that has climbed to $53,500. A weekend gap of 180 pips on a size that translates to 3% of the account is not a loss on the weekend. It is a hard breach at the open, before the first trade of the new week.

The gap did not exceed the drawdown. It exceeded the stops.

Why the rule exists at the firm

Two reasons, and it is worth understanding both because they shape how tightly firms enforce it:

Risk control across the book. A firm holding hundreds of accounts cannot hedge a shared directional exposure that every account carries into a weekend. Forbidding the hold removes a correlated tail risk from the entire portfolio at once.
Accountability for the gap. A gap is un-hedgeable and uncontrollable, which makes it the worst possible event for a firm that has to defend a maximum drawdown. It is the one loss that cannot be managed by skill, so the rule removes it by construction.

That is why the rule is usually a hard restriction with no fee-based workaround, unlike a daily-loss soft breach. Firms are not selling you a product you can pay to keep; they are removing an unmanageable risk from their book.

The two shapes of the rule

"Don't hold over the weekend" is written in at least three different ways, and they are not equivalent:

No positions held through Friday's close. You must be flat before the close. The strictest form.
No positions opened within a window before the close. You may hold a position opened earlier, but cannot add near the close. This is a hedging of the same risk, and it interacts with your entry timing rather than your holding policy.
Instrument-specific. Some firms ban weekend holds on indices and FX but allow them on others, or vice versa. The restriction is in the instrument list, not the general rulebook.

Assume the strictest interpretation until you have read the firm's specific account-type rules. A general marketing page saying "swing trading allowed" frequently refers to the funded account, not the evaluation, or to a specific programme.

Is your edge actually a gap edge?

The question that decides everything: strip the overnight moves out of your backtest and look at what is left.

A quick way to do it — recompute the strategy using only the intraday path:

// Does the edge survive without the gap?
// Take the same signals, but close the position before the session ends
// and re-enter at the next open instead of holding through it.
function withoutGaps(trades) {
  return trades.map((t) => ({
    ...t,
    // Replace the overnight return with zero: the position is flat across the gap.
    pnl: t.pnlIntraday,
  }));
}

function withGaps(trades) {
  return trades.map((t) => ({ ...t, pnl: t.pnlIntraday + t.overnight }));
}

If the difference between withGaps and withoutGaps is most of the strategy's total return, the edge lives in the gap. That is not a flaw in the strategy — it is information. It means the strategy is incompatible with any firm that forbids the hold, and the correct response is to filter the firm list by that constraint before comparing anything else, not to try to trade it anyway.

If the difference is small, the strategy has an intraday core and the overnight component is noise. In that case the rule costs you little and you can ignore it.

The failure mode to guard against

The dangerous version of this is a trader who knows the rule, believes the overnight component is small, and is wrong — because the backtest understated it. Backtests frequently misprice overnight exposure in three ways:

They fill at the close rather than the open, silently avoiding the gap.
They assume the stop was honoured at its price on the gap bar.
They use continuous synthetic bars that do not have gaps at all.

Each of those turns a real weekend risk into a modelled non-event. The fix is to reconstruct the strategy on actual session-boundary data, with the open price as the only fill available after a gap.

What to write down

Before buying any evaluation, three numbers:

The rule, in the firm's exact wording. Which instruments, which programme, which account type.
The overnight share of your edge. The withGaps minus withoutGaps difference, as a fraction of total P&L.
The gap risk in account currency. The worst historical weekend gap in your instrument, times your typical size — expressed in the drawdown's units, not pips.

If (2) is large, the rule is disqualifying for that firm and no sizing fixes it. If (3) is large relative to your remaining room, the same is true even for a small gap edge. The rule is not a formality you sign past; it is a constraint that eliminates some strategies and some firms, and the arithmetic that decides which is short and knowable in advance.

The firm-by-firm version of the rule — which programmes permit weekend holds, which ban them outright, and where the instruments differ — is in the weekend holding rules breakdown.

A soft breach and a hard breach are different failures

Okeke Jenny — Tue, 13 Oct 2026 18:32:44 +0000

Two traders each lose an evaluation. One is told their account is closed with a balance of $96,000 on a $100,000 starting account with a $10,000 drawdown. The other is told their account is "soft breached" and they may continue for a fee. Both headlines say "failed". They are not the same event, and the difference decides whether you have any money left to attack the problem with.

Defining the two

A hard breach is a terminal event. Equity touches the floor — the maximum drawdown level, or the daily loss limit measured intraday. The account is closed, the evaluation is over, and nothing you do afterwards matters for that account.

A soft breach (sometimes called a warning, violation, or soft breach fee) is a non-terminal violation. The firm flags a rule that was bent — most often the daily loss limit, a news window, or an overnight hold — and offers to continue the account for a fee, or takes a slice of the eventual profit, without closing it outright.

The distinction sounds procedural. It is actually structural, because the two events leave you in different states:

	Hard breach	Soft breach
Account state	Closed	Continues
Cost	Full evaluation fee, again	A fee, or a profit haircut
Trader's equity	Zero (of that attempt)	Preserved or partially preserved
Optionality	Buy a new attempt	Keep the existing one

Two attempts that both read "failed" in a statistics table are, in this framing, a total loss and a discounted continuation. Averaging them into one failure rate destroys exactly the information that would help a trader.

The mechanic that makes soft breaches dangerous

The trap is that a soft breach looks like a reprieve and behaves like a debt.

Suppose the daily loss limit on a $100,000 account is 5%, and you breach it by $400 — you lose $5,400 on a day whose limit was $5,000. A soft-breach rulebook may let you continue for a $150 fee. The account survives. But consider what you have just bought:

You are now $5,400 below the day's starting equity, and that loss is real. The profit target, measured from the starting balance, has grown by $5,400.
If the drawdown trails, your peak has not moved but your equity has — so your room to the floor is now smaller than it was.
You have paid a fee to hold an account that is materially harder to pass than a fresh one at the same price.

In the arithmetic, a soft breach is not "get out of jail free". It is a new attempt bought at a discount, and the discount is paid for by carrying a loss that the fresh attempt does not have. If a fresh evaluation costs $500 and a soft-breach continuation costs $150, the comparison is not $150 versus $500 — it is $150-plus-a-$5,400-deficit versus $500 on a level field.

When a soft breach is genuinely worth taking

The continuation is worth it when the violation is accounting-shaped rather than equity-shaped:

A news-window violation where the position was profitable and the loss is zero. You have a procedural mark against you but your equity curve is intact. Continuing is close to free.
A minimum-day or hold-time violation that cost nothing in P&L. Same logic.
A daily-loss breach on a day that closed well above the floor. Here the loss is real but small relative to the remaining room, and the fee is cheaper than a reset.

It is not worth it when the loss that triggered the breach has eaten a large fraction of the remaining drawdown. At that point you are paying to trade a smaller, harder account than the one you could buy fresh.

The decision rule

Write two numbers before you decide:

Remaining room = current equity − current floor.
Effective cost = continuation fee + the loss you are carrying.

If effective cost is below a fresh evaluation fee and your remaining room is at least, say, seventy percent of the original budget, continue. If the breach consumed your room, the continuation is a worse product than a reset even when its sticker price is lower.

The reason traders get this wrong is that they compare sticker prices, not states. The fresh account is often the cheaper instrument precisely because it is the only one that arrives with a full drawdown budget.

What this means for the failure statistic

If you are trying to build a real model of challenge difficulty, a single binary "passed/failed" output is the wrong data model. The correct one has at least three states — PASSED, HARD_BREACH, SOFT_BREACH — plus a cost field, because a soft breach that costs $150 on an intact curve and one that costs $150 on a drained curve are different events with the same label.

The simulator trap is identical to the one that catches drawdown models: if your state machine can only express "the account ended", you will conclude that all failures are alike and that the only lever is the underlying edge. Once you separate the states, the levers multiply — you can act on the daily-loss margin, on the news calendar, on the hold rule, and on the room-left-before-continuing decision, and each of those is a bookkeeping choice rather than a trading skill.

A challenge is not a test with a pass mark. It is a system with several distinct ways to stop, and the cheapest failure to avoid is the one you did not have to take at all. The full side-by-side of how hard and soft rules are written — and which firms punish which — is in the soft breach versus hard breach breakdown.

Where the 87% failure rate actually comes from

Okeke Jenny — Tue, 13 Oct 2026 18:32:08 +0000

Almost every prop firm page quotes the same headline: most funded-account challenges fail. Depending on who you ask it is 80%, 87% or "nine in ten". The number is repeated far more often than it is explained, and the explanation matters, because the causes are not one thing. They are four or five mechanically different events that get averaged into a single figure — and only some of them are things a trader can actually control.

This is an attempt to take the number apart rather than cite it.

The four ways an account ends

Take every way a challenge can conclude and sort them:

The profit target is reached and the account passes. The only outcome the marketing counts.
A hard breach. Equity touches the floor — the max drawdown, or the daily loss limit measured intraday. The account is closed immediately.
A soft breach or a stalled account. Nothing was breached, the target was never reached, and the evaluation expires or the trader abandons it.
A pass that is not payable. The target was reached, but a consistency rule or a payout condition blocks the withdrawal.

Almost every published failure rate collapses groups 2, 3 and 4 into one bucket. But they have almost nothing in common:

Group 2 is a path event. It happens at a specific moment, at a specific price, and it is usually the direct result of position sizing.
Group 3 is a duration event. It is the absence of a result, and it is dominated by the trader's own pacing.
Group 4 is a distribution event. The account was traded well enough to pass and is still ineligible, because of the shape of the profit rather than its size.

A single "87% fail" number tells you nothing about which of these is happening, and therefore nothing about what to change.

Why the decomposition changes the answer

Here is the useful part. The groups respond to completely different interventions.

If failures were mostly group 3 — never reaching the target — the fix would be a better edge or more time. But that is not where the accounts die. On a typical rulebook, the profit target is a modest move: 6% to 10% of the account. The drawdown is often larger in percentage terms than the target. The trap is not that the target is hard to reach; it is that the floor acts on the path the whole way there.

Consider a $100,000 account, 10% profit target, 10% drawdown. That reads like a 1:1 risk-reward on the account level. But the drawdown is measured from a different reference than the target:

The target is measured from the starting balance: you need equity at $110,000.
A trailing floor is measured from the peak: at a starting balance of $100,000 with a $10,000 trail, the floor sits at $90,000 and rises with every new high.

So the moment you are up $5,000 — halfway to the target — the floor has risen to $95,000. Your remaining risk budget is not the original $10,000. It is $5,000, because the room that got you halfway is now behind a floor that moved. Give back $5,000 from that peak and the account is gone while it is still in profit.

That single mechanic is a large share of group 2. It is also invisible in the headline failure rate, because "the account was closed" is reported identically whether the trader was down 10% or up 5%.

Worked arithmetic: room left as a function of progress

Run the trailing floor forward on the same account:

Equity	Trailing floor (peak − $10,000)	Room left	Progress to target
$100,000	$90,000	$10,000	0%
$102,000	$92,000	$10,000	20%
$105,000	$95,000	$10,000	50%
$108,000	$98,000	$10,000	80%
$110,000	$100,000	$10,000	100% — but the floor is now at the starting balance

Read the room column. On a trailing floor it is constant at $10,000 no matter how far you have travelled — the gain bought you nothing in risk terms, it only moved the floor up behind you. Compare that with a static floor fixed at $90,000:

Equity	Static floor	Room left
$100,000	$90,000	$10,000
$105,000	$90,000	$15,000
$110,000	$90,000	$20,000

Same number on the marketing page, "10% drawdown", and a completely different instrument. On the static account, profit increases your buffer. On the trailing account it does not. A single failure statistic that lumps both rulebooks together is averaging two different games.

Where the statistic is measured, and where it is not

There is a second problem with the number, and it is a sampling one. The failure rate you see is usually measured on accounts sold, not on trades taken. That introduces selection at both ends:

Survivorship in the numerator. Traders who fail quietly, buy a reset, and fail again are counted once each; traders who pass once and trade for years are counted once. The denominator is challenges, not traders.
The reset multiplier. A firm with a cheap reset converts one struggling trader into several challenge records. If most resets also fail, the headline rate rises for structural reasons that have nothing to do with the underlying difficulty of a single attempt.

This is not a reason to distrust the direction of the statistic — most attempts genuinely fail — but it is a reason not to treat it as a probability. It is a rate over a population of purchases, and a purchase is not an attempt at a well-defined problem.

What actually moves the number, per group

If you want to improve your own odds, the decomposition tells you which lever to pull:

Group 2 (hard breach): position sizing and know-your-floor discipline. The failure is arithmetic — stop distance in account currency versus remaining room — not prediction. A trade whose adverse excursion exceeds your remaining budget cannot be rescued by being right about direction.
Group 3 (never reached): pacing. Break the target into daily increments and refuse to chase it. The account usually dies from a size that was calibrated to the exit rather than to the entry.
Group 4 (not payable): the consistency ratio. Track largest day / running total continuously, and if it is above the cap, plan the dilution deliberately instead of discovering it at withdrawal.

None of those three is "be a better trader". All three are bookkeeping, and all three are knowable before the fact.

The honest summary

The headline number is real in direction and useless in detail. What it hides is that the biggest single cause of failure is not a losing strategy — it is a floor that moves, a size that ignores the floor, and a missing number at the moment of entry. Those are all learnable, and none of them show up in an 87%.

I walk through how each of these failure modes is written across the major firms, and where two rulebooks look identical and are not, in the fuller breakdown of why prop firm challenges fail. If you would rather compute your own remaining room than estimate it, the prop firm profit calculator does the arithmetic for both a static and a trailing floor.

Size positions from a drawdown budget, not a percentage

Okeke Jenny — Tue, 13 Oct 2026 16:42:03 +0000

Most position-size advice is expressed as a percentage of equity. That is a fine convention and a poor specification, because it never says what the percentage is for. A drawdown rule gives you a much better handle: it hands you a budget, and the interesting question is how many consecutive losses that budget has to survive.

The arithmetic

Risk a fixed fraction r of equity per trade. After N consecutive losses:

equity = start * (1 - r)^N

Set that equal to the floor and solve for N:

N = ln(floor / start) / ln(1 - r)

For a $50,000 account with a $2,500 drawdown, the floor is $47,500 and floor/start = 0.95:

Risk per trade	After 5 losses	After 10 losses	After 15 losses	Consecutive losses before the floor
0.5%	$48,762	$47,556	$46,378	10.2
1.0%	$47,550	$45,219	$43,003	5.1
1.5%	$46,361	$42,987	$39,858	3.4
2.0%	$45,196	$40,854	$36,928	2.5
3.0%	$42,937	$36,871	$31,663	1.7

Read the last column as a specification, because that is what it is. At 2% risk you are betting that you will not lose three trades in a row. That is the entire risk statement, and it is much easier to argue with than "2% is a safe size."

The relationship is not linear either. Going from 1% to 2% does not halve your buffer — it cuts consecutive-loss tolerance from 5.1 to 2.5. The buffer is a logarithm of the risk fraction, so the second percent costs much more than the first.

Why the number is not 10

A buffer of 5.1 consecutive losses sounds comfortable. It is worth stating what it assumes, because the calculation above is deterministic and the world is not:

It assumes losses are independent and identical. Real losing runs are correlated. In a volatile regime, the correlation is exactly when it hurts.
It assumes you risk r of current equity, so each successive loss is slightly smaller. That is the more forgiving of the two conventions. If you size from a fixed notional instead, the arithmetic is linear and the buffer is shorter, not longer.
It counts consecutive losses only. A drawdown can also be produced by a sequence of smaller losses interleaved with wins, and a trailing floor rises while you do it — so the budget available late in an attempt is different from the budget available at the start.
It ignores the daily loss limit. If the rulebook has one, the binding constraint may be intraday and smaller than the overall drawdown. For a $50,000 account a common daily limit is $1,250, which at 1% risk is 2.5 losses in one day, not five in a row.

The code

Deterministic arithmetic, so the function is short enough to verify by hand:

const start = 50000, dd = 2500;
const floor = start - dd;                       // 47500

// equity multiplier after n consecutive losses at risk fraction r
const after = (r, n) => start * Math.pow(1 - r, n);

// how many consecutive losses until the floor is touched
const buffer = (r) => Math.log(floor / start) / Math.log(1 - r);

for (const r of [0.005, 0.01, 0.015, 0.02, 0.03]) {
  console.log(
    (r * 100).toFixed(1) + '%',
    'after 5:', after(r, 5).toFixed(0),
    'after 10:', after(r, 10).toFixed(0),
    'buffer:', buffer(r).toFixed(1)
  );
}

Two things to notice about the implementation:

It is a binary search you should not write. There is no need to simulate. buffer(r) is closed-form, so the answer is exact and the "simulation" would only add sampling error to a quantity you can compute. Reach for a Monte Carlo when the quantity depends on the ordinal path; not when it is a logarithm.

The floor is an input, not an output. Notice that floor is derived from the rulebook, not from the amount you would like to risk. If you start from "I want to risk 2%" and then ask whether the account survives, you have the causality backwards. The budget fixes the risk; the risk does not fix the budget.

Turning the buffer into a trade size

The calculation above gives a fraction, not a lot size. To get from one to the other you need the instrument's value per point and the distance to your stop, which is a separate problem:

r * equity  =  size (in points) * value per point per contract

For an index future with a known point value, size = (r * equity) / (stop_distance * point_value). The drawdown budget tells you the maximum r; the stop distance and point value tell you how to express that as contracts. If you find yourself choosing between two sizes that differ by more than the granularity of the contract, you are no longer sizing from the budget — you are rounding, and the rounding is the decision.

This is the part that most sizing calculators get wrong in practice: they accept an account size and a risk percentage, produce a lot size, and never mention that the drawdown rule is what should have set the percentage in the first place.

What I would actually do with this

Compute the buffer for your rulebook before your first trade. Three numbers — account size, drawdown, risk fraction — and one logarithm.
State the assumption out loud. "2% risk means I am betting against three consecutive losses" is a falsifiable claim. "2% is conservative" is not.
Check which constraint binds first. If the daily limit is $1,250 and your overall drawdown is $2,500, the daily rule may be the binding one, and sizing to the overall drawdown will overstate your real buffer by a factor of two.
Prefer the convention that makes the arithmetic conservative. Sizing from current equity is more forgiving than sizing from a fixed notional. If you are unsure which one a platform or tool uses, assume the stricter.

Where this model is wrong

It is deterministic by construction. This is not a criticism of the result — it is a warning against adding simulation to it and gaining only noise.
Independence of losses is assumed and is false. The buffer column is a necessary condition, not a sufficient one.
The floor is treated as fixed. Under a trailing rule the floor rises with the peak, so your buffer is not constant over the life of the account — it shrinks as you get closer to the target, which is the opposite of what most traders assume.
The daily limit is handled as an aside. It should be a separate budget with its own buffer, and the binding constraint is whichever is smaller.

The useful reframing is that a drawdown rule is not a limit you bump into. It is a budget you spend, and the risk per trade is the rate at which you spend it. Expressing size as "how many consecutive losses can this survive" turns an intuition into an assertion you can check against your actual loss distribution.

If the constraint that matters most in your rulebook is the daily one rather than the overall drawdown, how daily drawdown is enforced goes through the different measurement conventions — from balance or from equity, reset at midnight or at the first trade — which change the buffer by more than the risk fraction does.

A challenge fee is a geometric series, not a price

Okeke Jenny — Tue, 13 Oct 2026 16:41:25 +0000

The advertised price of a trading challenge is a fee. The real cost is a random variable, and its expectation is not the fee. It is the fee divided by your probability of passing — and that division is where the interesting arithmetic lives.

The model, stated before it is used

Assume you retry until you pass, then collect one payout. Then:

attempts needed until the first pass  ~  Geometric(p),   E[attempts] = 1/p
E[total fees]   =  fee * (1/p)  =  fee / p
E[net]          =  payout - fee / p
break-even p    =  fee / payout

Two things follow immediately, and both are easy to skip past:

The cost multiplier is exactly 1/p. If you pass one time in three, you will on average pay for three challenges. The multiplier is not a small correction — at p = 0.35 it is 2.8×.
There is a break-even pass rate that does not depend on your skill at all. With a $500 fee and a $3,000 first payout it is 500/3000 = 16.67%. Below that, the arithmetic is negative no matter how good the strategy is; above it, positive. It is a property of the price list.

Point 2 is the useful one, because it inverts the usual question. Traders ask "can I pass?" The arithmetic asks "what is the cheapest rulebook whose pass rate clears the break-even by the widest margin?"

The measurement

Four rulebooks, one generator, 50,000 accounts each, $50,000 account, $2,500 drawdown, $6,000 target. Fee $500, first payout $3,000.

Rulebook	p(pass)	E[attempts]	E[fees paid]	Cost vs fee	E[net] after fees
static drawdown	78.31%	1.28	$638	1.28×	$2,362
trails to breakeven	70.33%	1.42	$711	1.42×	$2,289
trails, above breakeven	60.46%	1.65	$827	1.65×	$2,173
trails intraday	35.66%	2.80	$1,402	2.80×	$1,598

Everything clears the 16.67% break-even. That is worth being suspicious of, and the suspicion is correct — I will come back to it, because it is the most important limitation in this article.

The defensible finding is the spread: the same trader on the same strategy pays an expected $638 under one rulebook and $1,402 under another. That is a 2.2× difference in expected cost, driven entirely by the floor of the drawdown — not by the strategy, not by the trader, and not by the advertised fee, which is identical across all four columns.

The mechanism, in one function

The whole difference between the columns is a single expression for the floor:

const floor = () => {
  if (mode === 'static') return cfg.start - cfg.dd;          // never moves
  const f = peak - cfg.dd;                                    // follows the peak
  return mode === 'trailing_lock' ? Math.min(f, cfg.start)    // stops at breakeven
                                  : f;                        // keeps trailing
};

Three lines, and the pass rate moves from 78.31% to 35.66%. The rest of the simulator — the target, the trade generation, the iteration — is byte-identical. When a single expression moves an expected cost by 2.2×, that expression is the thing to understand, not the marketing copy around it.

There is a bug in this neighbourhood worth flagging because I shipped it and it produced a plausible-looking table. I first wrote the lock as:

return Math.max(f, cfg.start - cfg.dd);   // WRONG - does nothing

peak >= start always, so peak - dd >= start - dd always, so the max always returns f. The clamp was a no-op and "trails to breakeven" came out identical to the unclamped trailing rule — 35.66% on both rows. Two rulebooks, one number, and nothing in the output to suggest a problem. A rule that clamps the floor at breakeven is a minimum:

return Math.min(f, cfg.start);            // correct

Same character count. Opposite direction. One row in the table above.

Why the naive model is too generous

The table says all four rulebooks are profitable. That follows from the assumptions, and the assumptions are doing more work than the measurements:

Unlimited retries. E[attempts] = 1/p requires that attempts are independent draws. If a blown account teaches you something, the attempts are not independent and the geometric model is wrong about the variance — usually optimistically.
No time cost. Each attempt consumes weeks of calendar time. The model prices the fee and ignores the opportunity cost entirely.
The payout is collected once and never lost. Real funded accounts can be breached after passing, which ends the sequence with fees paid and no payout. Adding a funded-account failure probability is the single change most likely to invert the ordering in the table, because it interacts with the drawdown mode.
The fee is constant. Many firms scale the fee with account size and discount on repeat purchases, so fee/p is a weighted average, not a simple division.
p is treated as known. It is estimated from a model. At the bottom of the table, a plausible error bar on 35.66% spans a large multiple of 1/p, and the cost is a reciprocal function, so estimation error in p is amplified non-linearly into cost.

The honest summary: the spread across rulebooks is a robust finding, because all four share the same assumptions. The absolute profits are an artifact of assuming unlimited retries of an unbreached, fee-only challenge.

The code for the cost side

const FEE = 500, PAYOUT = 3000;

const cost = (p) => ({
  attempts: 1 / p,
  fees: FEE / p,
  multiplier: 1 / p,
  net: PAYOUT - FEE / p,
  clearsBreakEven: p > FEE / PAYOUT,
});

Five lines, and every number in the table is a call to it with a p that came from a simulation rather than an estimate. That separation is the discipline worth keeping: the simulation produces p; the cost model consumes it. They are different models with different assumptions, and merging them into one script is how a modelling assumption in the price logic gets attributed to the strategy.

Where this model is wrong

Single seed per rulebook. Reproducible, not an ensemble; unquantified sampling error on every p.
One trade per day, 80 days maximum. A real challenge spans longer, and the tail of the attempt-length distribution — the traders who take six attempts — is exactly the tail the geometric model is being used to price.
p measured in isolation. The pass rates come from four separate runs with the same generator, not from a paired comparison, so part of the spread could be seed noise rather than the floor rule. The ordering is monotone and large enough to be convincing; the individual values are not precise.
The payout is $3,000 for everyone. Firms tie the first payout to account size and profit share, so the break-even pass rate is rulebook-specific in reality and not the single 16.67% used here.

The practical takeaway is not "pick the static drawdown" — that ignores every other difference between firms. It is that cost is a function of 1/p, so the cheapest rulebook is the one you are most likely to pass, and the difference is multiplicative, not additive. A 20-point swing in pass rate is a 2.2× swing in expected spend on an identical fee.

I broke down what a prop firm challenge actually costs end to end — fee tiers, reset pricing and the payout schedule that sets the break-even — for anyone who wants the price-list side of this rather than the simulation.

Why an i.i.d. bootstrap lies about drawdown

Okeke Jenny — Tue, 13 Oct 2026 16:40:49 +0000

Resampling is the cheapest way to answer "how much of my backtest is luck?" It is also, in the specific case of drawdown survival, biased in a direction that flatters the result — and the fix is not more samples. It is fewer, longer ones.

The claim being tested

Suppose you have a strategy's daily P&L. You want a distribution of outcomes, so you resample: draw days independently, with replacement, and simulate the rulebook on each synthetic sequence. This is the bootstrap, and it is a good tool for a lot of questions.

It assumes the days are exchangeable — that shuffling them changes nothing that matters. Under that assumption, a shuffled series is a valid draw from the same process.

For a drawdown rule, that assumption is false in a way that matters, because the order of the days is the mechanism. A floor is breached by a run. Shuffle the days and you do not preserve the runs; you shred them.

The measurement

One generator, one rulebook, three resampling schemes. The generator is a two-state regime process — a chop state with a 40% win rate and a trend state with a 62% win rate, switching with 4% probability per day. The rulebook is a trailing drawdown that locks at breakeven, on a $50,000 account with a $2,500 drawdown and a $6,000 target. 50,000 simulated accounts per row.

Resampling scheme	Pass rate	vs true path
true path (ground truth)	82.23%	—
i.i.d. days from the same pool	92.52%	+10.29 pp
contiguous blocks, B = 5	89.90%	+7.67 pp
contiguous blocks, B = 10	87.68%	+5.45 pp
contiguous blocks, B = 20	85.85%	+3.62 pp

Every scheme draws from the same 20,000-day pool. They differ only in how they pick from it. And the i.i.d. row is wrong by more than ten percentage points — in the direction of "your strategy is safe."

That number is a statement about the rulebook, not about the market: for a rule that can be breached by a losing streak, destroying the streaks is the error. It is not a minor statistical infelicity. It is modelling a different rule.

Why blocks help, and why block size is the actual decision

A block bootstrap draws contiguous stretches of days rather than single days, so within a block the temporal structure survives. The table shows the error falling monotonically as the block grows:

B = 5   +7.67 pp
B = 10  +5.45 pp
B = 20  +3.62 pp

The reason to stop is not that larger is bad. It is that a block cannot meaningfully exceed the length of the history you are drawing from. With a 20,000-day pool, a 20-day block is already reusing the same stretches across draws, so increasing it further starts to convert sampling error into mere repetition. The honest statement of the rule is: use the longest block your pool supports, and if that is still too short to contain the runs you care about, your pool is the problem.

The code

The whole difference between the correct and incorrect version is the inner loop.

// i.i.d. bootstrap — shreds streaks. Biased for any rule breached by a run.
function iidSample(pool, nDays, rnd) {
  const out = [];
  for (let k = 0; k < nDays; k++) out.push(pool[Math.floor(rnd() * pool.length)]);
  return out;
}

// block bootstrap — keeps runs together.
function blockSample(pool, nDays, block, rnd) {
  const out = [];
  while (out.length < nDays) {
    const start = Math.floor(rnd() * (pool.length - block));
    out.push(...pool.slice(start, start + block));
  }
  return out.slice(0, nDays);
}

And the comparison, with the true path as the reference rather than as an afterthought:

const pool = makeDays(20000, mulberry32(SEED + 55), { switchP: 0.04, bigP: 0.06 });

let truth = 0;
for (let i = 0; i < N; i++) {
  const days = makeDays(80, mulberry32(SEED + 1 + i), { switchP: 0.04, bigP: 0.06 });
  if (simulate(days, 'trailing_lock', CFG).out === 'PASSED') truth++;
}

let iid = 0;
for (let i = 0; i < N; i++) {
  if (simulate(iidSample(pool, 80, rnd), 'trailing_lock', CFG).out === 'PASSED') iid++;
}

// truth = 82.23%   iid = 92.52%

Worth stating plainly: the "ground truth" here is ground truth relative to the generator. It is not a claim about real markets. The experiment measures whether a resampling scheme recovers the process it was given, and i.i.d. does not — it cannot, because the process has persistence and the scheme deletes it.

The part that generalises

This is a member of a family of mistakes that all share a shape: applying a resampling scheme whose null hypothesis contradicts the mechanism you are testing.

Resampling individual trades to test a drawdown rule assumes the losing run is not the thing that kills you. It is.
Resampling to test a consistency rule assumes the concentration of profit is not the thing that disqualifies you. It is — and, incidentally, i.i.d. resampling understates concentration risk by averaging the fat days out.
Resampling with the wrong block length in the presence of volatility clustering reproduces the same error with extra steps, because the thing that clusters is the variance, not the mean.

The cheap check before trusting any bootstrap: ask what property of the ordering your resampling scheme destroys, and whether the rule you are testing depends on it. If yes, single-day resampling cannot be used, and the block length has become a real modelling parameter that deserves to be chosen rather than defaulted.

Where this model is wrong

The regime process is invented. Two states with symmetric switch probabilities is a caricature of trend/chop. Real persistence is asymmetric — trends decay faster than they build — and that asymmetry would push the numbers further apart, not closer.
One trade per day, up to 80 days, so "runs" are at most 80 long and the pool is 20,000 days. Both are small enough that the block estimates carry their own sampling error, which I have not quantified.
Survivorship in the pool. The pool is generated once from the process; it is not refreshed, so all block draws are conditional on that one realisation.
Symmetric win/loss magnitudes. Every day is drawn from the same payoff family regardless of regime, so the regime affects only the win probability, not the size distribution. Real trend regimes change both.

If you just want the practical version: for a rule that fails on a streak, resample contiguous blocks, report the block length, and sanity-check the estimate against a simulation of the actual process when you have one. A bootstrap that cannot represent your worst run is not a risk estimate.

I keep a prop firm profit calculator that runs the cost side of this arithmetic — expected attempts, expected fees and the break-even pass rate for a given payout — for anyone who wants the numbers rather than the method.

Look-ahead bias hides in the bars you did not load

Okeke Jenny — Tue, 13 Oct 2026 16:40:12 +0000

There is a class of backtest bug that leaves no stack trace, produces plausible numbers, and is invisible in a code review. It happens when your simulator uses a price it could not have known at the time it needed to act — and the most common instance in trading code is subtler than the usual "using tomorrow's close to decide today's trade."

This one is about the open, the high, the low and the close being four different facts, and what happens when you keep only one of them.

The setup

Take a trailing drawdown. The floor follows your peak profit upward, and if equity touches the floor you fail. Then note something about which price drives each half of that sentence:

The peak is set by the high — the best the account ever looked.
The floor is touched by the low — the worst the account looked while open.

A daily bar gives you both. A daily close gives you neither. It gives you one point, and the two quantities the rule depends on are the extremes on either side of it.

If you simulate a trailing drawdown using closes only, you are asking "what would have happened if the only price that existed was the settlement" — which is not a model of your account. It is a model of a different account.

How big is the error?

I generated 50,000 accounts with identical closing P&L, then varied only one thing: how far below the close the price travelled at its worst point during the day. The closes are byte-identical across every row. Nothing about the outcome series changes. Only the unseen part of each bar changes.

Intraday range (unseen)	Pass rate, close-only rule	Pass rate, true path	Overstatement
0.2×	60.46%	43.75%	16.7 pp
0.5×	60.46%	41.08%	19.4 pp
1.0×	60.46%	35.66%	24.8 pp
2.0×	60.46%	11.32%	49.1 pp
4.0×	60.46%	0.48%	60.0 pp

The close-only column is 60.46% on every row. That is not a coincidence — it is the definition. A close-only simulator cannot respond to a variable it cannot see, so its estimate is a constant while the truth falls away from it.

At the reference range, the overstatement is 24.8 percentage points: 60.46% claimed against 35.66% real. That is the difference between "this rulebook is comfortably passable" and "this rulebook kills roughly two out of three accounts."

And here is the part that should worry you more than the size of the error: the error grows with the range, and the range is exactly what your data doesn't contain. You cannot compute a confidence interval on a quantity you did not sample. A close-only backtest has no way to tell you that it is off by 16 points or 60.

Minimal reproduction

The whole effect is in what the simulator is allowed to read. Both modes below run the same day objects; the only difference is two if conditions.

function simulate(days, mode, cfg) {
  // 'trailing_closed' never reads high or low. That is the entire bug.
  const closedOnly = mode === 'trailing_closed';
  let eq = cfg.start, peak = cfg.start;

  const floor = () => peak - cfg.dd;   // trailing floor

  for (const d of days) {
    if (!closedOnly) {
      const high = eq + d.high;
      peak = Math.max(peak, high);              // peak is set by the HIGH
      if (high <= floor()) return 'BREACHED';
      const low = eq + d.low;
      if (low <= floor()) return 'BREACHED';    // the LOW touches the floor
    }

    eq += d.close;                              // the close moves equity
    peak = Math.max(peak, eq);
    if (eq <= floor()) return 'BREACHED';
    if (eq - cfg.start >= cfg.target) return 'PASSED';
  }
  return 'OPEN';
}

Note where peak is updated in the closed-only branch: only on the close. Note that the low is never consulted. Both are necessary simplifications if you only have a daily close — and both bias the result upward, because the high that raises your floor and the low that breaches it are systematically discarded.

The generator that isolates the effect:

function day(kind, rnd) {
  if (kind === 'win') {
    const close = 300 + rnd() * 500;
    return { high: close + 200 + rnd() * 700, close,
             low: close - close * (0.05 + rnd() * 0.45) };
  }
  const close = -(200 + rnd() * 400);
  return { high: 60 + rnd() * 260, close,
           low: close - (50 + rnd() * 450) };
}

The invariant worth enforcing is high >= close >= low. My first version of this broke it: a strongly winning day could be given a low far below its own open, which meant a big up day both raised the floor enormously and breached it on the same bar. Every trailing account in the run died instantly, and the output was nonsense in a way that looked like a finding. An inconsistent bar is worse than a missing one, because you will believe it.

The general rule this is an instance of

Look-ahead bias is usually taught as "don't use information from the future." The durable version is broader:

Any quantity your strategy reacts to must be computed from data at or finer than the resolution at which the decision is made.

A trailing drawdown is a decision made intraday — it is enforced the moment the low touches the floor, not at settlement. Therefore it must be simulated with intraday extremes. A close-only model is not a lower-resolution approximation of that rule. It is a different rule, and a strictly more permissive one.

The same test applies to other common cases:

The daily loss limit is enforced intraday, so it needs the low. Daily closes will always under-count breaches.
A time limit counted in trading days can be modelled on daily bars, because the decision is made at day resolution. Not every rule needs ticks.
A trailing floor that locks at breakeven stops depending on the high once it locks, so the error shrinks after the lock — the bias is not uniform over the life of the account.

What to do instead

If you have intraday data, use it. The gap above is 24.8 points at the reference range; there is no correction factor that recovers it from closes alone.
If you only have daily bars, report the limitation as a bound, not a point estimate. A close-only result is an upper bound on the pass rate for any intraday-enforced rule. Say so.
Reconstruct at least the extremes. A daily OHLC series is usually easier to obtain than intraday ticks, and it is enough to get the high and the low. That removes most of this error class for a fraction of the data cost.
Assert your bar invariants. high >= max(open, close), low <= min(open, close). A one-line assertion at generation time would have caught the bug in my first version before it produced a single number.

Where this model is wrong

Scaling the intraday range uniformly is a modelling choice. Real ranges are heteroskedastic; they widen with volatility and are not proportional across accounts. The monotone trend in the table is robust to that, but the specific percentage points are not.
The other rulebooks in the run are not varied. Static drawdowns are largely insensitive to this bias — the floor doesn't move — so the 24.8pp figure is a statement about trailing rules.
One trade per day again. A day object with one high and one low understates how many times the low can touch the floor.
Single seed. The runs are reproducible but not an ensemble, so the point estimates carry unquantified sampling error.

The uncomfortable property of this bias is that it never announces itself. A close-only backtest of an intraday-enforced rule produces a clean, confident, wrong number, and the wrongness scales with the volatility of the instrument — so it will look most trustworthy exactly where it is most wrong.

I wrote up the underlying mechanics of trailing vs static drawdown separately, including how each mode's floor is defined across different firms, if you want the rulebook side rather than the simulation side.

The consistency rule is a constraint, not a number

Okeke Jenny — Tue, 13 Oct 2026 16:40:07 +0000

A trader passes the evaluation. Target hit, drawdown never breached, every rule respected. Then the payout request comes back refused, because one day carried 46% of the total profit and the firm's consistency rule allows 40%.

That is not a bug in their paperwork. It is two rules measuring unrelated things, and one of them is silently a filter.

The rule, stated precisely

Most prop firms express the consistency rule as a ratio:

largest single day's profit / total profit <= cap        (cap is typically 0.25 - 0.6)

The subtlety is what this expression is a function of.

The pass decision is a function of the equity path: did you reach the target before the floor?
The consistency cap is a function of the shape of the profit, not its size.

You can reach the target and still be ineligible. You can be wildly profitable over six weeks and still be ineligible, if the profit arrived in one afternoon. Nothing about the way you reached the target protects you from the second check, because the second check never looks at the path — only at the concentration.

Measuring how often that actually happens

I ran 50,000 simulated $50,000 accounts against a static $2,500 drawdown and a $6,000 target, one trade per day, up to 80 days. The generator produces normal days for the most part, with 6% of days outsized — a fat right tail, because real trading profit is not gaussian.

Result: 39,155 of 50,000 accounts passed (78.31%).

Then I applied the consistency cap to the accounts that had already passed:

Consistency cap	Passes that violate it	Effective pass rate	Extra profit needed (median)
25%	38,400 of 39,155 (98.1%)	1.51%	$6,343
30%	37,416 of 39,155 (95.6%)	3.48%	$4,162
40%	30,475 of 39,155 (77.8%)	17.36%	$1,727
50%	15,448 of 39,155 (39.5%)	47.41%	$737
60%	3,130 of 39,155 (8.0%)	72.05%	$213

Read the 40% row again. Nearly four fifths of the accounts that passed are ineligible to be paid under a cap of 40%.

And the control run matters just as much: with the same drawdown, the same target and the same 50,000 accounts, but no outsized days, violations at a 40% cap = 0.

That contrast is the whole insight. The rule does not bite on ordinary trading. It bites exactly when a trader has one very good session — which is the thing a discretionary trader most wants to happen.

Why the naive simulation misses this

If you backtest a challenge by asking "did equity reach the target before the floor", your model returns a single bit. The consistency rule needs a second, orthogonal output: the distribution of the daily contributions to the total.

That distinction is easy to get wrong, and I got it wrong the first time I built this. My first version produced zero violations at every cap from 25% to 60%, which I read as "the rule is harmless." The real cause was a generator bug: my winning days were small relative to the target, so the largest day was never more than 13% of the total. The rule looked harmless because the data could not possibly violate it.

If you are testing whether a rule hurts, you have to make sure your generator can violate it. Otherwise you have measured nothing.

The code

The pass decision and the eligibility check are separate functions. Only the second one needs the daily series.

// PASS DECISION: only needs the equity path.
function simulate(days, mode, cfg) {
  const closedOnly = mode === 'trailing_closed' || mode === 'trailing_lock';
  let eq = cfg.start, peak = cfg.start;

  const floor = () => {
    if (mode === 'static') return cfg.start - cfg.dd;
    const f = peak - cfg.dd;
    return mode === 'trailing_lock' ? Math.min(f, cfg.start) : f;
  };

  for (let i = 0; i < days.length; i++) {
    const d = days[i];

    if (!closedOnly) {
      const up = eq + d.high;
      peak = Math.max(peak, up);
      if (up <= floor()) return { out: 'BREACHED', at: 'high', day: i + 1 };
      const dn = eq + d.low;
      if (dn <= floor()) return { out: 'BREACHED', at: 'low', day: i + 1 };
    }

    eq += d.close;
    peak = Math.max(peak, eq);
    if (eq <= floor()) return { out: 'BREACHED', at: 'close', day: i + 1 };
    if (eq - cfg.start >= cfg.target) {
      return { out: 'PASSED', day: i + 1, days: days.slice(0, i + 1) };
    }
  }
  return { out: 'OPEN' };
}

// ELIGIBILITY: a pure function of the daily P&L series. No path, no equity.
function consistencyViolation(dayPnl, cap) {
  const total = dayPnl.reduce((a, b) => a + b, 0);
  const worst = Math.max(...dayPnl);
  return worst / total > cap;                 // true = cannot be paid
}

function extraProfitNeeded(dayPnl, cap) {
  const total = dayPnl.reduce((a, b) => a + b, 0);
  const worst = Math.max(...dayPnl);
  // solve worst / (total + x) = cap  ->  x = worst/cap - total
  return Math.max(0, Math.ceil(worst / cap - total));
}

Then the measurement is a filter over the accounts that already passed:

const base = run('static', 50000, { seed: 20261013, bigP: 0.06 });
const passRate = base.passed.length / 50000;                 // 78.31%

for (const cap of [0.25, 0.3, 0.4, 0.5, 0.6]) {
  const violators = base.passed.filter((r) =>
    consistencyViolation(r.days.map((d) => d.close), cap)
  );
  const effective = (base.passed.length - violators.length) / 50000;
  console.log(cap, violators.length, effective.toFixed(4));
}

effective is the number that matters and it is not the pass rate. It is the probability that an account both reaches the target and remains payable.

Diluting the violation, and what it costs

The standard remedy is not to stop trading. It is to keep trading until the offending day is a smaller share of a larger total. The arithmetic is one line:

largest_day / (total + x) = cap        =>        x = largest_day / cap - total

For the violating accounts in the 40% bucket, the median extra profit required is $1,727 — on a $50,000 account with a $6,000 target, that is roughly another 29% of the target in profit, produced under the same drawdown constraint that just tried to kill the account.

That is the real cost of the consistency rule: not a rejection, but a forced extension. You are still trading, your floor is still rising if the drawdown trails, and you now need to manufacture additional profit specifically to dilute a number, with no risk budget set aside for it.

What I would actually do with this

Track the ratio continuously, not at payout. If largest_day / running_total is above the cap, you know before you submit. Most platforms show the daily breakdown; the calculation is a division.
Decide the dilution trade size deliberately. If you need $1,727 more to clear a 40% cap, that is a target, not a vibe. Size it as you would any other target, against the room you have left.
Do not confuse the two failure modes. A drawdown breach is a path failure. A consistency violation is a distribution failure. Different causes, different fixes. Software that models only one of them will tell you that you are fine when you are not.
Check the cap on your specific firm, because 25% and 60% are different sports. The 25% row above — 98.1% of passes ineligible — is a genuinely different experience from the 60% row at 8.0%.

Where this model is wrong

One trade is not one day. I collapsed a day into a single trade for tractability. A real day contains many trades, and the intraday peak matters for trailing drawdowns in a way a daily aggregate cannot represent.
Profit is not the only input. Several firms apply consistency to lots, trade count or session, not just dollars. The shape of the constraint changes; the independence from the pass decision does not.
The generator's fat tail is a choice. 6% of days outsized is a modelled assumption, not a measurement of your trading. The control row (zero violations with no outsized days) exists precisely to show how much the answer depends on that assumption.
Deterministic seed. Every figure above comes from one fixed seed, so runs are reproducible but not an ensemble. The point estimates carry unquantified sampling error.

The consistency rule is usually described as a rule about consistency. In the model it is better described as a filter applied after the challenge has already been cleared, on a property — profit concentration — that the challenge never tested.

If you want to run these numbers against your own rulebook rather than the one I modelled, the prop firm consistency rule guide covers how the caps are written across the major firms and where the definitions quietly differ.

Trailing vs static drawdown: simulating why the same trades pass one prop firm account and fail another

Okeke Jenny — Tue, 13 Oct 2026 12:59:45 +0000

Two traders take the same trades on a $50,000 evaluation with a $6,000 target and a $2,500 drawdown. One account ends the week down $400 and is still alive. Another is dead — while up $2,700.

Nobody made a different decision. The rulebooks were different shapes.

I keep seeing this described as "risk management," which is not quite it. Risk management is a discipline you apply to a position. This is arithmetic applied to an account, and it is fully modellable. So rather than argue about it, let's simulate it — and then run the simulation 200,000 times instead of trusting the one walk that happened to be in front of us.

Every number below is real output from the script in this post, with a fixed random seed so you get byte-identical results when you run it. All code is at the end of the relevant section.

The three drawdown modes firms actually use

Static drawdown. The floor is fixed below the starting balance. A $50k account with a $2.5k limit has a floor at $47,500 that never moves. Profit is pure gain, because the reference point is fixed.

Trailing drawdown, measured on closed equity. The floor rises with the high-water mark of the closed balance. Close at $55,000 and the floor becomes $52,500 permanently.

Trailing drawdown, measured on unrealised equity. The floor rises with the highest equity touched during a trade. A position that prints +$2,200 of open profit ratchets the floor immediately — even if it later closes flat. Or at a loss.

There's a fourth variant worth knowing: trailing until break-even, where the floor trails your peak but is never allowed above your starting balance. It sounds like a minor detail. It turns out to be the most interesting result in this post.

The simulator

The whole thing is about 45 lines. Two modelling choices matter and I'll flag both:

Each trade visits its favourable extreme first, then its adverse extreme, then closes. That "gives back from the peak" shape is precisely what a trailing floor punishes, so this is the conservative assumption.
The trade can die at any of those three moments — on the spike, on the give-back, or at the close — which is what makes the intraday rule formally distinct from the on-close rule.

const CFG = { start: 50000, target: 6000, dd: 2500, fee: 500 };

function floorFor(mode, peak, cfg, lockProfit) {
  if (mode === 'static') return cfg.start - cfg.dd;

  // trails the peak, but the floor never rises above break-even
  if (mode === 'trailing_lock')
    return Math.min(Math.max(peak - cfg.dd, cfg.start - cfg.dd), cfg.start);

  // trails until the account reaches start + lockProfit, then locks
  if (mode === 'trailing_lock3k')
    return Math.max(Math.min(peak, cfg.start + lockProfit) - cfg.dd, cfg.start - cfg.dd);

  return peak - cfg.dd;   // trails indefinitely
}

function simulate(trades, mode, cfg = CFG, lockProfit = 3000) {
  let eq = cfg.start, peak = cfg.start, worstRoom = Infinity;

  for (let i = 0; i < trades.length; i++) {
    const t = trades[i];
    const upEq = eq + t.up, dnEq = eq + t.down;

    // 1. favourable excursion — only the intraday rule sees this
    if (mode === 'trailing_intraday') peak = Math.max(peak, upEq);
    let f = floorFor(mode, peak, cfg, lockProfit);
    worstRoom = Math.min(worstRoom, upEq - f);
    if (upEq <= f)
      return { out: 'BREACHED', at: 'intratrade-up', day: i + 1, eq: upEq, floor: f, pnl: upEq - cfg.start, worstRoom };

    // 2. the give-back — can breach the intraday rule on its own
    f = floorFor(mode, peak, cfg, lockProfit);
    worstRoom = Math.min(worstRoom, dnEq - f);
    if (dnEq <= f)
      return { out: 'BREACHED', at: 'give-back', day: i + 1, eq: dnEq, floor: f, pnl: dnEq - cfg.start, worstRoom };

    // 3. daily loss limit, measured from this day's starting equity
    if (cfg.daily && dnEq <= eq - cfg.daily)
      return { out: 'BREACHED', at: 'daily-limit', day: i + 1, eq: dnEq, floor: eq - cfg.daily, pnl: dnEq - cfg.start, worstRoom };

    // 4. close
    eq += t.close;
    peak = Math.max(peak, eq);
    f = floorFor(mode, peak, cfg, lockProfit);
    worstRoom = Math.min(worstRoom, eq - f);
    if (eq <= f)
      return { out: 'BREACHED', at: 'close', day: i + 1, eq, floor: f, pnl: eq - cfg.start, worstRoom };

    if (eq - cfg.start >= cfg.target)
      return { out: 'PASSED', day: i + 1, eq, floor: f, pnl: eq - cfg.start, worstRoom };
  }
  return { out: 'ALIVE', eq, floor: floorFor(mode, peak, cfg, lockProfit), pnl: eq - cfg.start, peak, worstRoom };
}

Now feed one fixed trade sequence through all four rulebooks. up is the favourable excursion, down the adverse one, close the settled result:

const TRADES = [
  { up: +1000, down: -300,  close: +900  },
  { up: +900,  down: -400,  close: +800  },
  { up: +1400, down: -400,  close: +1300 },
  { up: +2200, down: -300,  close: +1200 },  // spike, then give back 1000 of it
  { up: +1500, down: -300,  close: +1400 },
  { up: +300,  down: -600,  close: -600  },
  { up: +100,  down: -1000, close: -1000 },
  { up: +100,  down: -1100, close: -1100 },
  { up: +100,  down: -1200, close: -1200 },
  { up: +100,  down: -1200, close: -1200 },
  { up: +100,  down: -900,  close: -900  },
];

const label = {
  static: 'static',
  trailing_lock: 'trailing→breakeven',
  trailing_closed: 'trailing on close',
  trailing_intraday: 'trailing intraday',
};

for (const m of Object.keys(label)) {
  const r = simulate(TRADES, m);
  const pnl = (r.pnl >= 0 ? '+' : '-') + '$' + Math.abs(r.pnl);
  console.log(label[m].padEnd(20), r.out === 'BREACHED'
    ? `${r.out.padEnd(9)} day ${String(r.day).padStart(2)} (${r.at}) equity $${r.eq} vs floor $${r.floor} | P&L then: ${pnl}`
    : `${r.out.padEnd(9)} equity $${r.eq} | P&L ${pnl} | peak $${r.peak} | thinnest room $${r.worstRoom}`);
}

The output

start $50000 | target +$6000 | drawdown $2500 | 11 trades | fee $500

static               ALIVE     equity $49600 | P&L -$400 | peak $55600 | thinnest room $2100
trailing→breakeven   BREACHED  day 11 (give-back) equity $49600 vs floor $50000 | P&L then: -$400
trailing on close    BREACHED  day  8 (give-back) equity $52900 vs floor $53100 | P&L then: +$2900
trailing intraday    BREACHED  day  4 (give-back) equity $52700 vs floor $52700 | P&L then: +$2700

Read the last two lines twice. Both full-trail accounts were up thousands of dollars when they died. The trader was not losing. The trader was winning, and still lost the account — while the static account, on identical trades, ended down $400 and perfectly alive.

And note the break-even row: it survived to day 11, dying at break-even rather than at +$2,900. It lagged the full trail. Why it never dies in profit is the most interesting finding below.

Why the intraday account died on day 4

The mechanism isn't obvious, so here it is at position level:

Day	Entry equity	Peak touched	Floor after the peak	Result
1	$50,000	$51,000	$48,500	closed +$900, alive
2	$50,900	$51,800	$49,300	closed +$800, alive
3	$51,700	$53,100	$50,600	closed +$1,300, alive
4	$53,000	$55,200	$52,700	a pullback to $52,700 ended the account

Trade four printed $55,200 of open profit. That alone dragged the failure floor to $52,700. The position then pulled back to that level and the account was gone — on a trade that, measured from its entry, was never close to being a loser.

Note what's absent: no bad market call, no revenge trade, no broken stop. The trade worked. The failure was administrative — the reference point moved while the trader was still measuring risk from the entry.

Now the part that matters: 200,000 accounts

One walk proves a mechanism exists. It says nothing about how often it fires. So I ran each rulebook over 200,000 independent accounts, using the same seeded trade generator for all four — only the rule changes:

rulebook              passed   breached   still open   breach-while-ahead
static                57.01%    20.40%       22.58%                 0.0%
trailing→breakeven    47.77%    44.15%        8.08%                 0.0%
trailing on close     38.34%    60.12%        1.54%                40.9%
trailing intraday     22.02%    77.93%        0.05%                46.2%

Four findings, in order of how much they should change your behaviour:

1. The spread is enormous. Same trades, same target — pass rates from 22% to 57%. If you believe you have "a 50% pass rate," you don't. You have a pass rate against one rulebook, and it can more than double without you changing anything about how you trade.

2. About 4 in 10 full-trail breaches happen while the account is in profit (40.9%, 46.2%). The day-4 story is not an unlucky anecdote — it is the largest failure mode of the trailing rule, at population scale.

3. The two rulebooks whose floor cannot rise above break-even both show 0.0%. Not just static — also trailing→breakeven, which genuinely does trail your peak and is measurably harder than static (47.77% vs 57.01%).

That's the finding I didn't expect, and it isolates the mechanism exactly:

"Died while winning" is not a property of trailing drawdown. It happens if and only if the floor is allowed to rise above your starting balance.

If a firm says the floor stops at break-even, that one sentence deletes the entire failure category responsible for ~4 in 10 trailing breaches. Worth more than any comparison-table column.

4. The 0.0% is by construction, not by discipline. No skill is being measured in that column. It's a property of the rule.

What that spread costs

Feed the measured pass rates into E[attempts] = 1/p with the same $500 fee:

rulebook             pass rate p   E[attempts]   E[fee spend]   vs advertised fee
static                    0.5701          1.75          $877              1.75x
trailing→breakeven        0.4777          2.09        $1,047              2.09x
trailing on close         0.3834          2.61        $1,304              2.61x
trailing intraday         0.2202          4.54        $2,270              4.54x

Identical headline price. Expected bill differing by a factor of 2.5.

Choosing a static account over an intraday-trailing one is a bigger financial decision than choosing a $500 account over a $1,250 one — and nobody advertises it that way, because the fee is the number that fits on a button.

A pass rate isn't a number, it's a distribution

Twenty independent runs of the intraday rulebook, 5,000 accounts each:

min 20.82%   median 22.04%   max 23.32%
mean 22.05%   SD 0.68pp

Two things here, pointing in opposite directions.

Reassuring: the run-to-run spread is under a percentage point, so the 22%-vs-57% gap above is real signal, not sampling noise. The ordering is robust.

Uncomfortable: a pass rate isn't a fact about a firm you can look up. It's the output of a distribution that shifts when you shift. The only pass rate worth planning around is one you've measured on your own record against the specific rulebook you're about to trade.

The daily loss limit, which dominates everything else

Real evaluations usually carry a daily loss limit as well as a maximum drawdown. I modelled it separately, because the interaction is not obvious. Same $50,000 account, same $2,500 maximum drawdown. The worst single loss in the generator is $600 and the worst adverse excursion is $1,000.

daily limit                static   trailing on close   trailing intraday   binding-limit share of breaches
none                      57.01%              38.34%              22.02%   0.0% / 0.0% / 0.0%
$1250                     57.01%              38.34%              22.02%   0.0% / 0.0% / 0.0%
$1000                     57.01%              38.34%              22.02%   0.0% / 0.0% / 0.0%
$900                      27.75%              21.60%              14.44%   83.4% / 55.4% / 36.4%
$800                       5.60%               5.32%               4.60%   97.0% / 91.5% / 79.8%
$700                       1.04%               1.04%               1.02%   99.7% / 99.3% / 96.8%
$600                       0.24%               0.24%               0.24%   100.0% / 100.0% / 99.8%

There's a phase change here, and it happens inside a very narrow band.

At $1,000 and above the limit is completely inert — pass rates identical to the no-limit run, 0.0% of breaches. A limit that far from your normal loss size is decoration.

Between $900 and $800 it becomes the dominant failure mode. At $900 it explains 83% of static breaches and halving pass rates. By $800 it explains 79–97% of all breaches and the static pass rate collapses from 57% to 5.6%.

By $600 the drawdown rule stops mattering at all. All three rulebooks converge on 0.24% — within rounding error — and 100% of breaches are the daily limit. Static, trailing-on-close and intraday become the same product.

The reading is uncomfortable and useful in equal measure:

A daily loss limit set anywhere near the size of your worst single loss doesn't add a constraint to the drawdown rule; it replaces it.

Everything on the comparison table becomes irrelevant, and you've spent real effort choosing between rulebooks while the rule that actually ends your account sat underneath all of them.

Where the trail stops: the highest-value fact on your dashboard

I ran the two trailing rulebooks with the trail stopping at a +$3,000 profit lock, against trailing indefinitely:

trailing on close      full trail  38.34%  →  locked at +$3,000  45.99%   (+7.66pp)
   E[fee spend]  $1,304  →  $1,087
trailing intraday      full trail  22.02%  →  locked at +$3,000  45.99%   (+23.97pp)
   E[fee spend]  $2,270  →  $1,087

Locking at +$3,000 takes the intraday pass rate from 22% to 46% and cuts expected fee spend from $2,270 to $1,087 — more than halving the cost of the same account at the same price.

Note the two rows converge on exactly 45.99%. Once the floor is locked, the intraday/on-close distinction stops existing: a floor that can't move can't be breached by an intratrade excursion. Reaching the lock is not a milestone on the way to the target — it is the objective, and treating it that way is a different trading plan to "hit $6,000."

Does skill help equally under every rulebook?

This decides whether rulebook-shopping substitutes for getting better. Same rulebooks, five win rates, identical trade sizes so the only variable is decision quality:

win rate   static   trailing on close   trailing intraday   static minus intraday
    40%      8.02%                4.98%                2.63%                  5.4pp
    45%     27.10%               16.94%                9.01%                 18.1pp
    50%     57.01%               38.34%               22.02%                 35.0pp
    55%     82.67%               62.51%               40.46%                 42.2pp
    60%     95.03%               81.01%               60.10%                 34.9pp

Skill is worth more than the rulebook — on the easy rulebooks. Going 50% → 55% takes the static pass rate from 57% to 83%, a 26-point swing, larger than the entire 35-point static-vs-intraday gap at 50%. If you can improve, improving is the higher-return activity. Nothing here argues for settling for a bad rulebook instead of trading better.

But harder rulebooks convert skill into pass rate less efficiently. At 55% the gap is the widest in the table: 82.67% static versus 40.46% intraday. A trader at that skill level gets less than half the benefit from their own improvement on a trailing-intraday account, because a large share of their good outcomes is being consumed by a floor that rises while they win.

The 40% row is worth reading separately: all three rulebooks are in the single digits, because the model is running at slightly negative expectancy there. Rulebook choice is a second-order question for a trader whose edge isn't yet positive. Get the edge first.

The buffer result that surprises people

Trailing $2,500 on a $50,000 account:

peak equity   floor    room from peak   room if 1,500 off the peak
        +$0   $47500      $2500                             $1000
     +$1000   $48500      $2500                             $1000
     +$2000   $49500      $2500                             $1000
     +$2500   $50000      $2500                             $1000
     +$3000   $50500      $2500                             $1000
     +$5000   $52500      $2500                             $1000
    +$10000   $57500      $2500                             $1000

Every row is identical. An account up $10,000 has exactly the same room as one at break-even, provided both sit $1,500 below their own peak.

That's the formal statement of the whole post. On a static account a buffer is defensive capital you can spend down. On a full trail it isn't, because the floor has already risen to match it. The only variable that helps is your distance from your own high-water mark — at every moment, including intratrade. Or, better, holding an account where the floor isn't allowed above break-even, which makes the whole category of failure arithmetically impossible.

Turning the threshold into a position size

The useful thing about a trailing threshold is that it converts into contract counts exactly, because futures ticks are fixed-dollar:

contracts = (risk fraction × threshold) ÷ (stop distance in ticks × value per tick)

On $50,000 with a $2,500 threshold, a 10% risk budget is $250. Ten-point stops:

contract   stop (pts)   $/contract   contracts allowed   verdict
MES                10        $50.00                   5        ok
ES                 10       $500.00                   0   not tradeable at this risk
MNQ                10        $20.00                  12        ok
NQ                 10       $200.00                   1        ok

This is why micros are not a beginner's concession on a trailing account — they're the only instruments where a $250 risk budget exists at all. On ES the permitted size is zero, and one contract is double your entire per-trade budget against a floor that's still moving.

The failure mode this model doesn't cover: the consistency rule

Everything above stops at the profit target, which is why it models the drawdown rules well and the consistency rule not at all. That's a real gap, because consistency is a separate failure mode with a different shape: it doesn't breach your account — it blocks your payout after the account is already passed.

The typical rule: no single day (or single trade, depending on the firm) may account for more than a set share of your total profit — commonly 30% to 50%. The arithmetic that follows is not obvious and it is brutal.

Take a $6,000 target with a 40% consistency cap:

target                 $6,000
consistency cap        40% of total profit
day one result         +$6,000  (target hit — and the payout is blocked)

to satisfy the cap:  best day ÷ total profit ≤ 0.40
                      6,000 ÷ total ≤ 0.40
                           total ≥ 15,000

profit still required:
  $15,000 − $6,000 = $9,000 more, after already hitting the target

Hitting the target in one good day doesn't just fail to finish the job — it raises the finish line by 150%. You finish that account at $15,000 instead of $6,000, and every one of those extra dollars is traded on a floor that has been ratcheting up the whole time.

The practical consequence is that the target and the finish line are different numbers, and they diverge most for the traders who are best at the thing the challenge measures. Someone who can put together one exceptional day is penalised by exactly that skill. This is why "paced to a payout-ready distribution" and "hit the target" are two different plans, and why an account that shows a pass can still be weeks away from paying.

A five-minute check on your own account

Before you apply any of the above, pull your actual rulebook and answer five things. Write the numbers down — a rule you can't quote from memory is one you'll misread at the moment it matters.

Daily loss limit — the figure, and whether it is measured from the day's starting equity or including open float. Compare it to your worst normal single loss. If it's within a stone's throw, it's your real failure line, and nothing else on this list matters as much.
Drawdown type — static, trailing on close, or trailing intraday. Look for "trailing," "high-water," "follows your highest balance." The wording is often indirect.
Where the trail stops — break-even, a stated lock level, or never. If the rulebook doesn't say it stops, assume it doesn't.
The lock level — because reaching it changes which rulebook you're effectively trading. Getting there is the first objective, not a milestone.
The consistency rule — the percentage and the measurement period. Multiply it out the way I did above to find your true finish line.

Five numbers, five minutes, and they determine your expected cost more than the account size or the fee ever will.

Where this model is wrong

A simulation you can't audit is just an opinion with numbers:

Trades are independent and identically distributed. Real trading clusters, and a rule that punishes give-back punishes clustering harder than independence predicts. This makes the trailing figures conservative.
The winner/loser mix is fixed at 50/50, winners $300–800, losers −$200 to −$600 — plausible but arbitrary. Low win rate with large winners will look worse on trailing rules, because big winners are exactly what ratchet the floor.
Favourable-then-adverse is an assumption. Real trades sometimes reverse first, which would flatter the intraday rule.
The lock is modelled at two specific values (break-even and +$3,000). Real firms pick their own; the measured gap between those two is large, which is the point.
The daily limit is a fixed dollar figure from the day's starting equity. Some real rules include the day's open float, which is stricter.

Most assumptions push the same way: the true spread between rulebooks is wider than shown. The percentages are illustrative. The ordering isn't.

What I'd actually do with this

Before comparing any two firms on price, check two rules, in this order:

The daily loss limit. If it's anywhere near your worst single loss, it is your failure line and everything else is colour. This is the highest-value line on the dashboard.
Can the drawdown floor rise above your starting balance? If no, you cannot be killed while in profit. If yes, ask where it stops — break-even, a profit lock, or never.

Then, and only then, compare fees. Get either of the first two wrong and you'll size a position correctly for a different account than the one you're trading — which is the failure this post describes, expressed in dollars instead of trades.

Two things worth doing before you commit to a rulebook. Run your own numbers through the drawdown and challenge-cost calculator — it turns a measured pass rate into an expected fee across all four rulebooks above. And if you would rather not put your own evaluation through a rising floor at all, the done-for-you evaluation passing service trades the account for a flat $220.

Every figure in this post is the actual stdout of the simulator above, at a fixed seed. Paste the two code blocks into a file and run it: set CFG.dd to a static-account value and watch every trailing breach in the single walk vanish, or set CFG.daily = 600 and watch all three rulebooks collapse to the same number.

The expected value of a prop firm challenge, in Python

Okeke Jenny — Mon, 28 Sep 2026 09:34:39 +0000

Most "is this challenge worth it" comparisons stop at fee vs account size. That comparison is missing the two numbers that actually decide it: how many attempts you will need, and what the whole exercise averages out to. Both are easy to compute, and computing them changes the answer more often than any firm comparison does.

The model

Four inputs:

Symbol	Meaning
`F`	challenge fee — per attempt
`T`	profit target in dollars (account size x target %)
`s`	your profit split (the share you keep)
`p`	your probability of passing a single attempt

Everything else is derived:

net payout N = T * s
expected attempts E = 1 / p
expected fee outlay C = F * E
expected value of the venture V = N - C
expected value per attempt v = p * N - F (which is V * p)

Setting V = 0 gives a result worth memorising: the break-even pass rate is p* = F / N.

A script

def challenge_ev(account, target_pct, fee, split, pass_rate):
    """Expected value of buying a prop firm challenge until you pass."""
    target = account * target_pct
    net = target * split
    e_attempts = 1 / pass_rate
    expected_fees = fee * e_attempts
    return {
        "net_payout": net,
        "expected_attempts": e_attempts,
        "expected_fee_outlay": expected_fees,
        "ev_venture": net - expected_fees,
        "ev_per_attempt": pass_rate * net - fee,
        "break_even_pass_rate": fee / net,
    }

for p in (0.20, 0.35, 0.50, 0.70):
    r = challenge_ev(100_000, 0.08, 550, 0.80, p)
    print(p, round(r["expected_attempts"], 2), round(r["expected_fee_outlay"]), round(r["ev_venture"]))

A $100k account, an 8% target ($8,000 gross), an 80% split, a $550 fee:

20%  E=5.00  fees=$2,750  EV=$3,650
35%  E=2.86  fees=$1,571  EV=$4,829
50%  E=2.00  fees=$1,100  EV=$5,300
70%  E=1.43  fees=$786    EV=$5,614

What the numbers say

1. The break-even pass rate is much lower than people assume. With a $6,400 net payout and a $550 fee, p* = 8.6%. You do not need to be good, you need to be better than one attempt in twelve. That is the useful way to read a challenge: not "is this hard", but "am I above 8.6%".

2. The fee is per attempt, and the expected outlay is a multiple of it. At a 35% pass rate you will buy 2.86 challenges on average, not one — so a "$550 challenge" is a ~$1,571 decision. Firms advertise the per-attempt price because it is the smaller number.

3. Improving the pass rate is worth more than shopping for a cheaper firm. Moving 35% to 50% adds roughly $470 of expected value; cutting the fee from $550 to $450 adds roughly $130. Optimising the input you actually control dominates optimising the marketing.

4. The split compounds, the fee does not. The fee is paid once per attempt; the split applies to every payout, forever. Two firms with the same target and a 10-point split difference are not close, and a single-challenge EV view hides that completely.

The two inputs people get wrong

p is the hard one, and it is hard because of memory, not dishonesty: traders benchmark against the attempt they remember passing, not the ones they quietly failed. If you are unsure, start at 30-40% for a self-traded challenge and see whether the number still works. If it does not survive a conservative pass rate, it was never a good bet — it was a good feeling.

Split is the other. Enter the share you keep, applied to net profit, not the target. Reading an 80% split as though the payout equals the target is the single most common arithmetic error in this category.

Two things this model deliberately does not include: consistency rules (they change when you can withdraw, not the total — but a blocked payout is worth less than an available one) and taxes, platform fees and transfer costs (small individually, not always small together).

A note on what I do

I run a flat-fee prop firm passing service, so read this with that in mind. The math above is the argument for it, and it is also the argument against it: a service makes sense exactly when it raises p toward 1 and replaces a cost that scales with your failures with one that does not. Run your own numbers twice — once at your honest self-traded pass rate, once at a near-certain one — and compare the gap to the fee. If the gap is smaller than the fee, trade it yourself.

If you just want the numbers without writing the script, I put the same model in a free browser calculator, no signup: prop firm profit calculator. It returns expected attempts, expected fee outlay, expected value per attempt and the break-even pass rate. If you write about this, it is also embeddable with one line of HTML.

The formula is four lines of Python either way. The value is in running it before you buy, rather than after the third retry.