The motivating question
"If I have a 30% win rate but winners are a much bigger % move than losers, can that be profitable? What about the reverse — high win rate, small moves?"
Both can be true or false — it depends on the win/loss/cost relationship, not on win rate or move size alone. The determining factor is whether expected edge clears a roughly fixed per-trade cost floor. Small average moves are the more fragile case, not the safer one, because a fixed-%-per-trade cost eats a larger relative bite out of a small move than a large one.
See the for a full worked example of this exact flip.
What's here
Sweep p_min(H) and W_min(H) across hold
duration, fee mix, and funding scenario — interactively.
Win rate × move size × profitability, for every (hold, fee-mix, funding) combination.
Cross-checked against SD1H4H's real BTCUSD backtest cost figures — all 4 engine/strategy combos pass.
The closed-form formulas, derived from first principles, with hand-worked numeric examples and unit tests.
BTCUSDT funding, at a glance
Interactive calculator
Pick a scenario. Cost C(H) = round-trip fee + expected
funding for that hold/fee-mix/funding combination.
Minimum win rate, by W/L ratio (L fixed at 1%)
| W / L | W% | L% | p_min |
|---|
Minimum average win size, by win rate (L fixed at 1%)
| win rate | L% | W_min % |
|---|
Try your own numbers
Equity curves: what "breakeven" actually looks like
The win-size table says "you need at least this much average win size to break even." That number alone is easy to misread as a target. These curves compound a sequence of simulated trades at a given win rate and reward:risk ratio R (avg win as a multiple of avg loss, fixed at 1% here — scalp: taker-only fees, funding off) so you can see what sitting exactly ON the breakeven R actually does to an account — and how a bit more or less R changes everything, because it compounds.
Build your own equity curve
Pick a calculator scenario (for C(H)) and your own win
rate/move sizes/position sizing, and simulate it directly. The dashed line is the
theoretical expected-growth curve (every trade delivers exactly its expected R); the solid
lines are individual simulated random sequences at that win rate — real trading
doesn't walk the dashed line, it walks something like one of the solid ones.
Pre-trade screening: minimum ATR% / move size, by trading style
Before checking win rate at all: does a symbol even move enough, at your
intended hold duration, to clear fees + funding + realistic slippage? Solves for the
minimum average loss / ATR / stop width L such that
cost_in_R = C(H) / L stays under a target ceiling — the same
cost_in_R quantity SD1H4H's own real BTCUSD backtests report. A screen to run
before investing any time building or backtesting on a symbol. Full writeup:
methodology & calibration.
| Style | Hold range | ATR proxy | C(H) | Comfortable (cost≤10% R) |
Workable (cost≤15% R) |
Danger line (cost≤25% R) |
|---|
ATR proxy is a rough chart-timeframe suggestion for sanity-checking a symbol's ATR indicator against each style's hold duration — treat it as an upper bound, not an exact substitute: ATR (per-bar true range) tends to overstate net directional move over a hold window, since price chops within its range rather than moving in a straight line. See the full writeup for why, and for what to use instead once you have real trade data.
Calibration: SD1H4H's original engine (~1% stops)
measured cost_in_R ≈ 17% and its edge did NOT survive costs; its variant
engine (~2.3% stops) measured cost_in_R ≈ 8-10% and DID survive. These
thresholds are set relative to that real outcome, not an arbitrary round number.
Win rate × move size × profitability
Each row of panels fixes a reward:risk ratio R = avg win / avg loss. Green = profitable, red = not, black line = exact breakeven.
Empirical validation vs. SD1H4H
This model's C(H) is cross-checked against SD1H4H's own
committed BTCUSD backtest results (real historical funding, real trade-level stop widths
and hold times). Per the spec's acceptance test: if the predicted cost range didn't contain
the actual figures, something in the model would be wrong.
loading…