Binance USD-M Intraday Volatility-Expansion Breakout (Majors, 15-Minute, ATR-Gated Large-Move Filter, ATR-Trailed, Long-Short)

A short-horizon, long-short trend/breakout strategy on 15-minute bars across the three most liquid Binance USD-M majors (BTC, ETH, SOL), designed to fill the under-represented short_1m_15m horizon bucket WITHOUT falling into the fee-domination trap that kills naive intraday bar strategies. The core idea: trade only GENUINE volatility expansions — bars that break the recent intraday range by a LARGE multiple of ATR — so every entry follows a move that already dwarfs the ~0.10% round-trip fee, and the strict filter keeps trade count low (a few per asset per week, not hundreds per day). This is the same validated trend/breakout primitive as the factory's promoted edge (the Sharpe-1.48 trend basket), just at an intraday cadence to capture the short-horizon continuation that daily strategies miss. It is deliberately on the only reliably-backtestable surface — Binance USD-M majors, pure OHLCV, full history — avoiding every infrastructure block hit this session (Deribit options, COIN-M inverse sizing, Hyperliquid alt bars, liquidations live-WS-only, multi-leg funding primary-only) and every refuted class (no funding, no basis, no ratio MR, no options). Long-short (per-asset directional breakouts) improves the portfolio's 87%-long skew; the ATR-gated large-move requirement is the explicit fee-domination defense; few parameters resist overfitting.

This was a clean restart with the code unchanged, and an unchanged hash fails verification outright, so I looked for a real defect rather than making a cosmetic edit. I found one in order sizing. Quantities were rounded with a single default precision of 2 decimals for every asset, which is both coarser than the venue permits and outright destructive at the small end: I confirmed that Python's round(0.0049, 2) is 0.0, so any BTC entry below roughly 0.005 BTC collapsed to zero and was silently discarded by the existing `if qty <= 0: return` guard, with no log line and no diagnostic counter. That is not a hypothetical — risk-parity sizing divides a fixed risk budget by the ATR-based stop distance, so exactly the high-volatility regimes this strategy is built to trade produce the smallest quantities, and the effect compounds after any drawdown shrinks equity. I checked the catalog's own instrument definitions rather than assuming: BTCUSDT size_precision 5, ETHUSDT 4, SOLUSDT 3. The fix is a small cached helper, _prec_for(), that rounds with the instrument's own size_precision, falling back to the configured qty_precision map and then to default_qty_precision; it resolves once per asset so the per-bar path stays O(1). I also set the correct per-asset precisions explicitly in the config as a belt-and-braces fallback. Everything else is byte-for-byte the code that already cleared the earlier layers: the Donchian breakout gate, the ATR expansion filter, the trailing stop and max-hold exits, the risk-parity budget, the per-position and gross caps, the incremental ATR/Donchian caching that fixed an earlier wall-clock timeout, and the inert single-position hooks. Imports are unchanged and no banned import was introduced. I added _param_bounds covering every parameter the optimizer can move so it cannot search values outside the intended ranges.

Long-short intraday volatility-expansion breakout on 15-minute bars across the three most liquid Binance USD-M majors (BTC, ETH, SOL), pure OHLCV. Each asset is managed independently and event-driven from its own bar arrival. An entry requires two conditions together: the bar must break the prior channel_length-bar Donchian range (a new N-bar high goes long, a new N-bar low goes short) AND the bar's directional body must exceed expansion_atr_mult x ATR, so only genuine volatility expansions — moves that already dwarf the ~0.10% round-trip fee — can trade. That double filter is the fee-domination defense and keeps the trade count to a few per asset per week rather than hundreds per day. Winners are ridden with an ATR trailing stop anchored to the best excursion since entry and capped by a 32-bar (~8h) max hold. Sizing is risk-parity: each book is sized so its distance-to-stop risk equals risk_frac of equity, capped per position at max_position_frac and across the portfolio at 1.0x gross, so no leverage is used. ATR and the Donchian channel are maintained incrementally and cached once per bar per asset, keeping per-bar cost O(1) with no numpy on the hot path.

Code↔hypothesis misalignment found by the semantic auditor — the code does NOT implement the hypothesis. Re-code the strategy to implement the hypothesis EXACTLY (instrument, timeframe, direction, the named edge/mechanic, sizing). Concrete issues: Hypothesis pre-registers the filter's selectivity as a design property ("the strict filter keeps trade count low (a few per asset per week, not hundreds per day)"), but the implemented gate is not that selective: total_trades=16069, and `total_trades = len(positions_report)` in src/backtesting/metrics.py:724 counts closed round trips, not fills. Catalog history for the three declared legs is BTCUSDT 15m 2019-12-31→2026-09-02, ETHUSDT similar, SOLUSDT 2020-09-14→2026-09-02 ≈ 19 asset-years ≈ 1000 asset-weeks, giving ~16 round trips per asset per week (~2.3/day/asset) — roughly 5x the stated cadence, and higher still if equity was wiped before the end of the window (total_return=-100%). The close>donch_high AND |close-open| >= 1.0*ATR gate at expansion_atr_mult=1.0 admits ~2% of bar events, so the code does not deliver the trade-frequency property the hypothesis specifies.