BTC Hyperliquid Adaptive Volatility-Channel Trend-Ride, Long-Short (Single-Instrument BTCUSD.HYPERLIQUID Perp, 4H Bars — Ride Breaks of an EMA±ATR Envelope, Exit/Flip on EMA Reclaim, Pure OHLCV, 3-Parameter)

A LONG-SHORT, single-instrument, pure-OHLCV mid-frequency trend-ride on BTCUSD.HYPERLIQUID 4H bars. It defines an adaptive volatility channel — an EMA center band with ATR-scaled envelope edges — and rides directional breaks of that envelope: go long when price closes above the upper band, short when below the lower band, and exit (or flip) when price reclaims the EMA center, which lets winners run the trend leg while cutting losers quickly. It is engineered to satisfy every hard-won constraint from the failure record. (1) It lands in the ONLY zone that both CLEARS FEES and yields a MEASURABLE sample: 4H swing holds of ~1-3 days capture BTC trend legs of ~2-5% (well above the ~0.09% HL round-trip fee), while ~100-200 signals over Hyperliquid's ~2.3-year 4H history give the analyst a statistically robust trade count — avoiding both the fee_edge death that just killed the 15m continuation idea (avg trade −0.046%) and the 'unmeasurable <100-trade' death that killed my strangle/funding ideas. (2) It is SIMPLE pure-OHLCV, single-instrument, standard incremental indicators (EMA, ATR) — the only construction the developer reliably ships. (3) It fills the two biggest reliable gaps: HYPERLIQUID venue (6.6% vs a ≥20% quota, shifting off Binance's 71%) and LONG-SHORT direction (13.5% vs an 86%-long-only book). (4) It is a DISTINCT family from my pending queue — the mechanical OPPOSITE of my BTC-HL flat-regime mean-reversion (this rides breaks, that fades them), and a different construction and asset from my SOL-HL Donchian breakout (EMA±ATR envelope with an EMA-reclaim trailing exit, not a raw N-day high/low channel). Only 3 parameters; 4H bars keep it well inside HL's ~5000-candle history cap.

Straight answer first: QA is right that iteration 2 failed, and I can tell them exactly WHY it failed rather than guess again — the slope gate was mechanically redundant with the entry it was supposed to filter. If the close is 1.5 ATRs above an EMA, that same move has already dragged the EMA up over the prior day, so sign(slope) is positive at essentially every long trigger; removing exactly one trade out of 69 is the signature of a filter that is a tautology, not a screen. That diagnosis rules out re-tuning the same axis (adding a slope magnitude threshold would just be a fresh magic number on a dimension QA has already shown does not separate winners from losers), so I left the gate untouched and spent the iteration on the one lever nobody has pulled yet. The arithmetic points at it unambiguously: at win_rate 0.382 break-even needs RR 1.62 and realized is ~1.5, so the gap is on the WINNERS, and the EMA-reclaim exit is a lagging exit — with ema_period 30 (five days of 4H bars) a leg that extends 4-5 ATRs leaves the center 2-3 ATRs below the high, so every good trade must hand back a large slice of the leg before the exit fires. The give-back ratchet caps that hand-back at 1.5 ATRs from the best close since entry, lifting average win without touching the loss leg — QA explicitly warned that widening the loss side at a sub-40% win rate moves RR the wrong way, so the reclaim level is unchanged and no buffer was added to it. It is an addition, not a replacement: on trades that never extend, the reclaim still fires first and behavior is identical, so trade count and the measurable 68-trade sample are preserved; it reuses the envelope's own 1.5 ATR scale, so it adds no tunable and the surface stays at 3 parameters; and it is stateless, re-derived from position.ts_opened and the bar buffer, so it cannot drift or diverge on restart. Everything that already passed is untouched — same imports, same class, same continuous (close - EMA)/ATR signal in natural units, same risk-anchored sizing, and iteration 2's 0.5x notional cap is retained since QA confirmed it did what it claimed (avg_position_pct 85% -> 50%) as risk hygiene rather than an edge fix. On the >100% max_drawdown/var_95 flag I agree with QA's read that it is the session-wide metrics-normalization artifact and deliberately made no sizing change, since the sizing path is correct. Falsifiable caveat, stated plainly so this cannot be spun next round: if capping give-back does not lift avg_trade_return_pct clear of the 0.15% floor, then the winners simply are not large enough relative to a 38% hit rate no matter how they are harvested, the pure-OHLCV trend/breakout family verdict stands on its fifth data point, and I recommend abandonment over a fourth code iteration.

Net-negative, capacity-dead HL single-perp trend-ride — no edge to optimize. Over 242 measured trades: profit_factor 0.983 (<1), expectancy -$11.6/trade, total_return +3.0% over 2.6 years (CAGR -1.1%), Sharpe 0.041 with bootstrap CI [-1.19, 1.19] straddling zero and PSR 0.524 — indistinguishable from no-skill and slightly negative net of costs. It is capacity-dead: impact_cost_pct 192% (modeled market impact ~2x gross PnL) with capacity_usd only $27k, so the thin edge exists only at toy scale and is underwater at any deployable size. avg_trade_return_pct 0.169% sits just above the ~0.15% HL floor on a gross basis but the realized per-trade expectancy is negative. This is the L82 Hyperliquid single-perp OHLCV momentum/trend family (0/128, zero survivors), and iteration 3's give-back ratchet did not flip the negative sign (iteration 2 was avg_trade 0.0355%, PF 0.914). The recent regime is losing (2025 -14.9%, 2026 -1.5%, stressed -10%), so the last-20% holdout is negative. No parameter tuning flips a negative-expectancy trend-ride whose modeled impact already exceeds its gross PnL in a zero-survivor venue/mechanism class. Failure pattern: no_edge/fee_edge HL single-perp trend, capacity-dead (L82).

Verification failed (Layer 4 — QA review): - REALIZED PER-TRADE EDGE IS BELOW THE FEE FLOOR AND THE STRATEGY IS A NET LOSER -- the exact fee_edge death the hypothesis claimed to have engineered around. On a measurable 69-trade / 364-day sample (metrics_reliable=true) avg_trade_return_pct is 0.0457% -- roughly a THIRD of the 0.15% futures viability floor and barely above the ~0.09% HL round-trip -- with profit_factor 0.964 (<1), Sharpe -0.067, negative total P&L, and per-trade dollar expectancy -$41.61. The hypothesis explicitly promised 'more than an order of magnitude of headroom' over fees from multi-percent (2-5%) trend legs and pointed to the 15m continuation idea's death at avg trade -0.046% as the mistake being avoided -- but the realized 0.0457%/trade is essentially the SAME near-zero, below-fee edge, just at 4H instead of 15m. Per L6, the arithmetic check the hypothesis relied on (per-trade gross move >> round-trip cost) fails in practice: the EMA-envelope breaks do not extend far enough beyond the ~band_atr_mult ATR entry distance to clear costs. Per L7, this is the pure-OHLCV trend/breakout family with zero survivors this session (the sibling SOL-HL Donchian and ETH weekly-ORB both just failed the same way), and the developer's own caveat concedes 'if 4H breaks mean-revert more often than they extend, no parameter setting will save it' -- which the win_rate of 0.377 and PF 0.964 confirm is what happens. There is no positive edge to carry into optimization. - IMPLAUSIBLE RISK-METRIC UNITS + LARGE REALIZED EXPOSURE -- verify. max_drawdown is reported as 19.05 (1905%, CI [15.14, 54.46]), var_95 2.71 and cvar_95 3.63 -- all >100%, impossible as equity fractions with liquidated=false, and consistent with the recurring metrics-normalization convention seen across every HL/Binance sandbox run this session (this strategy's own sizing is capped at 1.0x equity notional). SEPARATELY note that avg_position_pct here is 85% (vs 15-25% on the other single-instrument strategies this session): risk_pct 0.015 / (band_atr_mult 1.5 * ATR) with a 1.0x notional cap lands positions near full equity notional, so realized per-trade swings are large (largest_loss -$5605, largest_win $14871) -- which, combined with the below-fee edge, is what drives the deep drawdown. The sizing code itself is correct (risk-anchored, capped, min-notional guard), but the analyst should note this runs materially hotter than the 0.5x-cap siblings.

Verification failed (Layer 4 — QA review): - THE ITERATION-2 FIX DID NOT WORK -- the strategy remains a net loser with a per-trade edge below the fee floor, and is if anything slightly WORSE. After adding the trend-alignment (EMA-slope) gate: avg_trade_return_pct 0.0355% (down from iter1's 0.0457%, still below the 0.15% floor and barely above the ~0.09% HL round trip), profit_factor 0.914 (down from 0.964), Sharpe -0.208, win_rate 0.382, net-negative total return, on a measurable 68-trade / 364-day sample (metrics_reliable=true). Crucially, the substantive fix barely bound: the developer projected the slope gate would cut entries to ~45-55, but the sandbox still shows 68 trades (vs 69 in iter1 -- ONE fewer). So the 'counter-trend spike inside an opposing trend' population the gate targeted was NOT the source of the loss; the trend-ALIGNED breaks lose too. This directly confirms the developer's own falsifiable caveat: 'if 4H BTC envelope breaks mean-revert more often than they extend even when trend-aligned, the slope gate will not save this and the family verdict stands.' It does, and it doesn't. This is the pure-OHLCV trend/breakout family (L7 zero-survivor) and the FOURTH such strategy to fail on a below-fee-floor, net-negative edge this session (ETH weekly-ORB iter1, SOL-HL Donchian, and this idea's own iter1). - The notional-cap change worked as intended and is good risk hygiene: max_notional_frac 1.0 -> 0.5 halved realized exposure (avg_position_pct 85% -> 50%), so the strategy no longer runs at double its siblings' size. This does not change the edge (avg_trade_return_pct is percent-of-notional) and was not presented as an edge fix. The reported max_drawdown 14.96 (1496%, CI [10.03, 39.42]) and var_95 1.53 remain >100% -- the same metrics-normalization artifact seen across every HL/Binance sandbox run this session, not a sizing bug (the sizing code is correct). Flag for engine-side confirmation only.

Verification failed (Layer 4 — QA review): - THE ITERATION-3 GIVE-BACK RATCHET FAILED AND MADE THE RESULT WORSE ON EVERY AXIS -- and the developer's own pre-committed abandon criterion is now met. Across the three iterations the edge has monotonically DEGRADED: avg_trade_return_pct 0.0457% (iter1) -> 0.0355% (iter2) -> 0.0112% (iter3, still far below the 0.15% floor); profit_factor 0.964 -> 0.914 -> 0.882; Sharpe -0.067 -> -0.208 -> -0.331; total return more negative each time (-6.59 now). The ratchet was meant to LIFT average win, but it did the opposite: it cut extended winners short (realized RR fell to avg_win $1231 / avg_loss $979 = 1.26, BELOW the ~1.5 it started from and further from the ~1.62 break-even needed at this win rate) while nearly doubling turnover (68 -> 97 trades) and therefore fee drag, because earlier exits flip and re-enter more often. The measurable 97-trade sample (metrics_reliable=true, Sharpe CI [-2.04, 1.24]) is now large and decisively net-negative. The developer stated the falsifiable test up front: 'if capping give-back does not lift avg_trade_return_pct clear of the 0.15% floor, then the winners simply are not large enough relative to a 38% hit rate no matter how they are harvested... I recommend abandonment over a fourth code iteration.' It did not; the winners are not there. Per L7 this is the pure-OHLCV trend/breakout zero-survivor family, and this is its third failed iteration on top of the sibling SOL-HL Donchian and BNB Turtle and ETH weekly-ORB failures. - IMPLAUSIBLE RISK-METRIC UNITS -- verify (unchanged, engine-side). max_drawdown 16.09 (1609%, CI [10.35, 38.82]), var_95 1.72, cvar_95 2.23 are all >100% despite leverage 1.0, risk_pct 0.015, a 0.5x notional cap (avg_position_pct 50.3%, confirming the iter2 cap holds), and liquidated=false -- the same session-wide metrics-normalization convention, not a sizing bug (sizing is correct: risk-anchored, independent cap, floor + min-notional). Flag for engine-side confirmation only.