Binance USD-M Intraday na Volatility-Expansion Breakout (Majors, 15-Minuto, ATR-Gated na Filter ng Malalaking Galaw, ATR-Trailed, Long-Short)

Isang trend/breakout strategy na long-short sa maikling horizon, gamit ang 15-minutong bars sa tatlong pinaka-liquid na majors ng Binance USD-M (BTC, ETH, SOL), na dinisenyong punan ang kulang na kinakatawang short_1m_15m horizon bucket WITHOUT nang hindi nahuhulog sa patibong ng dominasyon ng bayarin na pumapatay sa mga payak na intraday bar strategy. Ang pangunahing ideya: mag-trade lamang kapag lumalawak ang volatility sa GENUINE — mga bar na lumalampas sa kamakailang intraday range nang LARGE multiple ng ATR — para bawat entry ay sumusunod sa galaw na mas malaki na kaysa sa ~0.10% round-trip fee, at pinananatiling mababa ng mahigpit na filter ang bilang ng trade (ilang trade bawat asset kada linggo, hindi daan-daan bawat araw). Ito ang kaparehong napatunayang trend/breakout primitive ng promoted edge ng factory (ang Sharpe-1.48 trend basket), ngunit sa intraday na dalas para makuha ang pagpapatuloy sa maikling horizon na hindi nasasalo ng mga daily strategy. Sadyang nasa tanging surface na maaasahang ma-backtest — Binance USD-M majors, purong OHLCV, buong kasaysayan — at iniiwasan ang lahat ng hadlang sa imprastraktura sa session na ito (Deribit options, COIN-M inverse sizing, Hyperliquid alt bars, liquidation na live-WS-only, multi-leg funding na primary-only) at lahat ng pinabulaanang klase (walang funding, walang basis, walang ratio MR, walang options). Pinapahusay ng long-short (mga directional breakout bawat asset) ang 87%-long skew ng portfolio; tahasang panangga sa dominasyon ng bayarin ang malaking galaw na kailangan para makalusot sa ATR; nilalabanan ng kakaunting parameter ang overfitting.

Malinis itong muling pagsisimula at hindi binago ang code; mabibigo agad sa verification ang hash na hindi nagbago, kaya naghanap ako ng tunay na depekto sa halip na gumawa ng kosmetikong pagbabago. May nakita ako sa order sizing. Ni-round ang mga quantity sa iisang default precision na 2 decimal para sa lahat ng asset, na parehong mas magaspang kaysa pinapahintulutan ng venue at mapaminsala sa maliliit na halaga: kinumpirma ko na ang round(0.0049, 2) ng Python ay 0.0, kaya nagiging zero ang anumang entry na BTC na mas mababa sa humigit-kumulang 0.005 BTC at tahimik na itinatapon ng umiiral na `if qty <= 0: return` guard, nang walang log line o diagnostic counter. Hindi ito haka-haka — hinahati ng risk-parity sizing ang nakapirming risk budget sa stop distance na batay sa ATR, kaya ang mga high-volatility regime na nilalayong i-trade ng strategy ang siyang nagbubunga ng pinakamaliliit na quantity, at lumalala ang epekto kapag pinababa ng drawdown ang equity. Sinuri ko ang mga depinisyon ng instrument sa catalog mismo sa halip na manghula: BTCUSDT size_precision 5, ETHUSDT 4, SOLUSDT 3. Maliit na naka-cache na helper na _prec_for() ang pag-aayos; nagra-round ito gamit ang sariling size_precision ng instrument, at kung wala iyon ay ginagamit ang naka-configure na qty_precision map saka default_qty_precision; isang beses itong nireresolba sa bawat asset kaya nananatiling O(1) ang pagproseso sa bawat bar. Tahasan ko ring itinakda sa config ang tamang precision ng bawat asset bilang karagdagang panangga. Bawat iba pang bahagi ay kapareho nang byte sa byte ng code na nakapasa na sa mga naunang layer: ang Donchian breakout gate, ang ATR expansion filter, trailing stop at max-hold exits, risk-parity budget, limitasyon sa bawat posisyon at gross, incremental ATR/Donchian caching na nag-ayos sa naunang wall-clock timeout, at mga walang bisa na single-position hook. Hindi nagbago ang imports at walang ipinakilalang ipinagbabawal na import. Idinagdag ko ang _param_bounds na sumasaklaw sa bawat parameter na maaaring galawin ng optimizer para hindi ito makapaghanap ng mga halagang lampas sa nilalayong saklaw.

Paulit-ulit na liquidation — hindi ito naa-optimize, at minsan na itong inabandona dahil sa parehong sanhi. LIQUIDATED ang account sa eksaktong kaparehong petsa (2020-12-30) ng iteration 1, at muling bumagsak sa unang taon (total_return -100%, max_drawdown 100%, saka flat/patay nang ~5.7 taon), na nagpapatunay na maling hinala ang pagbabago sa precision ng laki ng order sa iteration-2 at hindi nito natugunan ang ugat ng problema. Sakuna sa bayarin dahil sa sobrang pag-trade sa 15m ang mekanismo: 15,962 trade na may komisyong 20.23% ng gross ($80k) at $68k na epekto, avg_trade_return_pct -0.023% (neto ay negatibo), profit_factor 0.70, Sharpe -1.06 (CI [-2.99, -0.86]), PSR 0.0, return_kurtosis 1982, negatibo sa bawat vol regime — hindi sapat ang ATR-expansion gate para mabawasan ang mga trade at makaiwas sa dominasyon ng bayarin, at hinahayaan ng risk sizing na lumala ang mga lugi hanggang bumagsak ang account. Ito ang libingan ng bayarin para sa L18/L30 purong-OHLCV 15m; walang pagbabagong parameter ang makapagliligtas sa account na naging zero. Padron ng pagkabigo: ni-liquidate ng risk_reject/fee_edge ang sobrang pag-trade sa breakout na 15m, at naulit ang pag-abandona sa iteration-1.

Long-short intraday volatility-expansion breakout sa 15-minutong bars sa tatlong pinaka-liquid na majors ng Binance USD-M (BTC, ETH, SOL), purong OHLCV. Malayang pinamamahalaan ang bawat asset, batay sa event sa pagdating ng sarili nitong bar. Kailangang sabay na matupad ang dalawang kundisyon para makapasok: dapat lumampas ang bar sa naunang channel_length-bar na Donchian range (bagong N-bar high para mag-long, bagong N-bar low para mag-short) AND at dapat lumampas ang directional body ng bar sa expansion_atr_mult x ATR, kaya mga tunay na paglawak lang ng volatility — mga galaw na mas malaki na kaysa sa ~0.10% round-trip fee — ang maaaring i-trade. Panangga sa dominasyon ng bayarin ang dobleng filter na ito at pinananatili nitong ilang trade lang bawat asset kada linggo sa halip na daan-daan bawat araw. Hinahayaang tumakbo ang mga panalong trade gamit ang ATR trailing stop na nakabatay sa pinakamagandang galaw mula pagpasok at nililimitahan ng maximum hold na 32 bar (~8h). Risk-parity ang sizing: itinatakda ang laki ng bawat book para katumbas ng risk_frac ng equity ang risk mula layo hanggang stop, na may limitasyong max_position_frac bawat posisyon at 1.0x gross sa buong portfolio, kaya walang leverage. Inaalagaan nang paunti-unti ang ATR at Donchian channel at isang beses kino-cache sa bawat bar bawat asset, kaya O(1) ang gastos kada bar at walang numpy sa hot path.

Natuklasan ng semantic auditor ang hindi pagtutugma ng code at hypothesis — NOT ipinapatupad ng code ang hypothesis. I-code muli ang strategy para maipatupad nito nang EXACTLY ang hypothesis (instrument, timeframe, direksyon, pinangalanang edge/mechanic, sizing). Mga partikular na isyu: itinatakda ng hypothesis bilang katangian ng disenyo ang selectivity ng filter (“pinananatiling mababa ng mahigpit na filter ang bilang ng trade (ilang trade bawat asset kada linggo, hindi daan-daan bawat araw)”), pero hindi ganoon ka-selective ang ipinatupad na gate: total_trades=16069, at bilang ng mga saradong round trip, hindi fills, ang binibilang ng `total_trades = len(positions_report)` sa src/backtesting/metrics.py:724. BTCUSDT ang kasaysayan ng catalog para sa tatlong idineklarang leg: 15m 2019-12-31→2026-09-02, kapareho ang ETHUSDT, SOLUSDT 2020-09-14→2026-09-02 ≈ 19 asset-years ≈ 1000 asset-weeks, kaya humigit-kumulang 16 round trip bawat asset kada linggo (~2.3/araw/asset) — halos 5x ng nakasaad na dalas, at mas marami pa kung naubos ang equity bago matapos ang window (total_return=-100%). Tumatanggap ang gate na close>donch_high AND |close-open| >= 1.0*ATR sa expansion_atr_mult=1.0 ng humigit-kumulang 2% ng mga bar event, kaya hindi naibibigay ng code ang katangiang dalas ng trade na itinatakda ng hypothesis.

Nabigo ang verification (Layer 2 — mga sintetikong scenario): Mga parameter na ginamit: ['assets', 'risk_frac', 'atr_period', 'trail_mult', 'min_notional', 'max_hold_bars', 'qty_precision', 'channel_length', 'gross_cap_frac', 'max_position_frac', 'expansion_atr_mult', 'default_qty_precision'] Tiyaking itinatakda ng __init__ ang lahat ng attribute mula sa self.parameters.get(). - steady_uptrend: TypeError: super(type, obj): obj must be an instance or subtype of type (timestamp ng bar: 1735689600000) - steady_downtrend: TypeError: super(type, obj): obj must be an instance or subtype of type (timestamp ng bar: 1735689600000) - flat_ranging: TypeError: super(type, obj): obj must be an instance or subtype of type (timestamp ng bar: 1735689600000) - volatility_spike: TypeError: super(type, obj): obj must be an instance or subtype of type (timestamp ng bar: 1735689600000) - zero_volume: TypeError: super(type, obj): obj must be an instance or subtype of type (timestamp ng bar: 1735689600000) - price_gap: TypeError: super(type, obj): obj must be an instance or subtype of type (timestamp ng bar: 1735689600000)