BtcSignalSolLeadLagMomentumTransferLS

BTC-Signal-Driven SOL Lead-Lag Momentum Transfer, Long-Short (Signal: BTCUSDT.BINANCE Momentum Confluence → Execute SOLUSDT.BINANCE in BTC's Direction, Highest-Beta Amplification for Fee Cushion, Pure OHLCV, 3-Parameter)

A LONG-SHORT, TWO-INSTRUMENT, pure-OHLCV strategy that uses the ONLY signal empirically shown to carry edge in this factory — BTC's dual-timeframe momentum confluence (the paper-stage survivor) — as an exogenous driver to trade SOLUSDT.BINANCE, the HIGHEST-beta liquid major, in BTC's confirmed direction. It is grounded in the session's complete evidence: the survivor's edge is BTC-driven directional market-beta TIMING (it profits by being long when crypto trends up and short when it trends down, using BTC's clean signal), while alts' OWN signals are noise (XRP/LINK/SOL/ETH all died 'no edge') and every supplementary confirm fails on coverage/edge. So this does not rely on SOL's own signal — only on BTC's proven timing, which SOL follows with the HIGHEST beta of the liquid majors. The choice of SOL over ETH (my pending lead-lag instrument) is deliberate: SOL's higher beta means each BTC-timed leg is ~1.5-2× BTC's move (~4-8% per 4H trend leg), giving the largest per-trade cushion over the ~0.10% fee — directly maximizing the edge-to-fee ratio that has killed so many strategies. Versus the diversified 3-alt basket (also pending), this is a concentrated single-name expression: it accepts SOL idiosyncratic risk in exchange for the cleanest, largest amplification. It stays entirely in PURE OHLCV (the only reliably measurable, coverage-complete data), is developer-safe (BTC signal + single SOL execution, standard incremental indicators), and measurable (~120-200 signal changes at the BTC-confluence cadence over multi-year history). It fills the under-target LONG-SHORT (13.3%) and multi-instrument scope (19.2%) buckets. Only 3 parameters.

I removed the two O(n log n) per-bar patterns the feedback named — _confluence rebuilt and sorted a period list twice per bar, and _exit_decision sorted the whole BTC store on every bar while in a position. The BTC store is now incrementally sorted parallel arrays with a period-to-index map, so lookups are a bisect plus a bounded slice of ~74 entries; measured 1.4s -> 0.08s over 40,000 calls. But I am not going to claim that fixes the timeout, because I measured and it does not. Two facts. First, the removed pattern cost only 1.4s across 40,000 calls, because the BTC store is capped at 800 entries and never grew with history. Second, and decisively, I ran an EMPTY do-nothing FactoryStrategy on this exact 2-leg config (SOLUSDT 4-HOUR primary + BTCUSDT 4-HOUR extra, 2400-day window) and it exceeded 420 SECONDS and had to be killed, with zero strategy logic. The binding cost is the harness: BacktestRunner issues one catalog.bars() per bar type and NautilusTrader fsspec-globs the entire bar tree on each call. I profiled this earlier on another two-leg strategy — roughly 200s of a 215s run inside fsspec walk/ls/info with 2.9M info() and 2.6M stat() calls, about 95s per bars() query plus 25s for instruments(), and flat in bar count (61 bars 125.8s, 2,401 bars 137.9s, 6,999 bars 140.4s). Cost scales with the number of bar types, not with history or per-bar work, so no two-leg strategy fits inside the 300s cap on this catalog regardless of how it is written, and this one is irreducibly two-leg because the entire hypothesis is BTC-signal-drives-SOL-execution. The platform fix is to cache the globbed file list across bars() calls within a run, or query each leg's own directory instead of the whole data/bar tree. I also added _param_bounds mirroring the clamps; the residual-lag band, exits, sizing and no-look-ahead period keying are unchanged.

Overfit / no-generalization death (NOT fee-edge — per-trade return 8.4% clears the floor). Four unwaivable HARD gates fail: (1) walk-forward is_overfitted=true, IS avg 1.468 -> OOS avg -0.879 with inconsistent windows (-1.86, -2.76, +1.98); (2) out-of-sample Sharpe -0.879 <= 0; (3) PBO 0.7606 > 0.5; (4) holdout Sharpe -1.141 <= 0 on 14 unseen trades. Robustness confirms noise: deflated_sharpe 0.813 << 0.95, is_significant=false, fails programme FDR (keeps 3 of 233). Sensitivity shows 3 cliff params with no stable high-Sharpe region, so there is no robust parameter region for a second iteration to tune toward. Per the overfit-vs-dead-premise rule this is ABANDON not revise_hypothesis: the identical BTC-signal-drives-alt-execution lead-lag mechanism has now failed the same overfit signature across every sibling (BTC->ETH lead-lag overfit, BTC->SOL 15m fee_edge/-95%, SOL-HL BTC-gated overfit, BTC triple-TF overfit, BTC faster-horizon overfit), so re-pointing the same mechanism at another instrument would simply overfit again. The only surviving instance of this family is the original single-instrument BTC dual-TF confluence; amplifying it through SOL beta does not add generalizable edge. Failure pattern: overfit / no-generalization.

Long-short two-instrument momentum transfer on 4-hour bars: BTCUSDT.BINANCE supplies the only timing signal and SOLUSDT.BINANCE takes all the risk. The signal is BTC's dual-horizon momentum confluence in BTC-ATR units — a fast mom_lookback-bar move and a slow 6x-horizon confirm, combined as the signed minimum when they agree and clipped below the entry threshold when they disagree. Entries require a fresh cross of the confluence through the threshold AND a residual-lag band showing SOL has transferred some but not all of BTC's risk-adjusted move: lag_frac <= (btc_fast - sol_move)/btc_fast <= 1.0, where the upper bound algebraically excludes SOL moving against BTC (a decoupling rather than a lag). Exits are confluence loss with hysteresis, a BTC-ATR trailing stop measured on the driver, and a SOL catastrophe stop matched to the trail in the traded instrument's own volatility. Sizing risks 2% of equity across the SOL-ATR stop distance, floor-rounded to SOL's whole-unit step, leverage 1.0. BTC bars are stored as incrementally sorted parallel arrays with bisect lookups, so signal evaluation is O(log n) plus a bounded window.

sandbox_timeout: Verification failed (Layer 3 — sandbox backtest): smoke test exceeded the 300s wall-clock limit on a ~20000-bar window (2400 days of SOLUSDT.BINANCE-4-HOUR-LAST-EXTERNAL). This almost always means per-bar work that scales with history — e.g. rescanning the full funding/supplementary series, or rebuilding a list and calling min()/sorted() inside calculate_signal()/on_bar() on every bar. Precompute sorted timestamp arrays ONCE in __init__ and use bisect, or cache lookups keyed by timestamp, so per-bar cost is O(log n) not O(n).

avg_trade_return_pct = 1.19% is well above the 0.15% Binance USD-M fee floor and plausible for SOL 4H swings held ~4.7 days (not a compounding/leverage artifact; end_unrealized_pct only 8.8%, no liquidation).

Numerically viable base backtest: PF 1.199, positive expectancy (+$198/trade), Sharpe 0.44 (positive), max_drawdown 18.3%, 151 trades over 6 years, commission only 2.57% of gross.

Trades implement the stated hypothesis: 94 long / 57 short, BTC dual-TF confluence signal driving SOLUSDT execution long-short — no mechanism mismatch.

This is the dual-timeframe momentum-confluence family on Binance USD-M — the one OHLCV class that has produced a promotion (L82). Only 3 tunable parameters, so overfitting surface is small.

Positive in the stressed vol regime (Sharpe 0.91, +25.6%), i.e. the edge concentrates when it should.

Sharpe is weak (0.44) and its 95% CI [-0.30, 1.25] straddles zero — significance is not yet established.

Performance is decaying: 2021-2024 carried the return, but 2025 (-5.6%) and 2026 (-9.8%) are losing years and rolling Sharpe has gone deeply negative (~-4) recently. The holdout (last ~15 months) will be the decisive test and may fail.

36% win rate with a long left-tail (kurtosis 7.4) — return depends on a few large trend legs (Aug-2021, Nov-2023) rather than a steady edge.

benchmark_meaningful=false, so no alpha/IR available to confirm it beats holding the majors.

Per-trade economics are fine, so this is NOT a fee/edge-below-cost death: optimized avg_trade_return_pct 8.42% (base 1.19%), both far above the 0.15% Binance USD-M fee floor; commission only 1.08% of gross.

Optimized in-sample point metrics look attractive (Sharpe 1.46, PF 3.07, max_dd 9.6%, win_rate 0.46) and the mechanism is correctly implemented (BTC-signal-only, single SOL execution, balanced 57 long / 43 short).

Classic overfit / no-generalization: walk-forward is_overfitted=true with IS avg 1.468 collapsing to OOS avg -0.879, and the three OOS windows are wildly inconsistent (-1.86, -2.76, +1.98) — the edge is fit to specific windows, not a stable mechanism.

HARD gate: out-of-sample Sharpe -0.879 <= 0 (unwaivable).

HARD gate: PBO 0.7606 > 0.5 — parameter selection is more likely than not overfitting.

HARD gate: holdout FAILED, Sharpe -1.141 <= 0 on the unseen last window (14 trades) — the edge is negative out-of-sample.

Robustness confirms noise: deflated_sharpe 0.813 (<0.95, is_significant=false), does not survive programme-level FDR (keeps 3 of 233, candidate_p 0.187), deflated_sharpe_programme 0.64.

Sensitivity flags 3 cliff parameters (bar_hours, slow_mult, trail_atr_mult); the optimizer jumped to bar_hours=6 / slow_mult=9 / trail_atr_mult=7.5, far from base, and the grid is flat ~0.34 everywhere with only sporadic cliff jumps to 0.65-0.70 — there is no stable high-Sharpe region to tune toward.

Recent live-period decay: rolling Sharpe turns and stays negative through 2025H2-2026 (optimized annual_returns 2025 -4.7%, 2026 +0.48%); the strategy is losing on the most recent unseen data.

Benjamini-Hochberg at q=0.10 over 233 programme candidates keeps 3. A candidate that does not survive here is not distinguishable from the programme's own noise, however good its individual statistics look.

Verification failed (Layer 4 — QA review): - DECISIVELY NET-NEGATIVE -- it omits the residual-lag filter that is the entire edge, and SOL's beta amplifies the losses. On a measurable 46-trade / 363-day sample (metrics_reliable=true): avg_trade_return_pct -1.18%, profit_factor 0.632, Sharpe -0.847 (CI [-2.42, 0.79]), total_return -16.7%, win_rate 0.304, expectancy -$363/trade. This is now the THIRD demonstration of the same failure: taking an alt in BTC's confluence direction WITHOUT checking that the alt still has an open lead-lag residual has no edge. The single-ETH BTC->ETH lead-lag transfer only became profitable (PF 1.55, avg_trade +0.675% -- which PASSED) when iteration 2 added the RESIDUAL-LAG requirement (enter only when the alt has >=25% of BTC's risk-adjusted move UN-transferred); its iteration 1 without that gate was net-negative (PF 0.90), the 3-alt basket without that gate was net-negative (PF 0.847), and this single-SOL version without that gate is net-negative and WORSE (PF 0.632). The win_rate of 0.304 -- directionally wrong ~70% of the time -- is the tell: taking SOL whenever BTC confluence fires buys the already-transferred/completed move, and because SOL is the HIGHEST-beta alt it has usually moved MORE than BTC by entry, so there is even less lag left to harvest and the amplified reversion is a larger loss (avg_loss $1417, largest_loss -$4785). The 'beta amplification for fee cushion' thesis is falsified: amplifying a signal with no edge amplifies the losses, not a cushion -- the developer's own caveat asked 'whether beta amplification adds enough cushion to outrun the extra idiosyncratic variance', and the answer is no. - IMPLAUSIBLE RISK-METRIC UNITS -- verify (unchanged, engine-side). max_drawdown 20.87 (2087%, CI [10.62, 42.03]), var_95 1.61, cvar_95 1.98 are >100% despite leverage 1.0, risk_pct 0.02, a 1.0x notional cap (avg_position_pct 34.9%), and liquidated=false -- the session-wide metrics-normalization convention, not a sizing bug (the SOL whole-unit sizing and independent notional cap are correct). Flag for engine-side confirmation only.

Verification failed (Layer 4 — QA review): - THE RESIDUAL-LAG GATE DID NOT TRANSFER TO SOL -- and the developer pre-committed to abandoning this instrument in exactly this outcome. The gate is the same mechanism that turned the single-ETH transfer from PF 0.90 (no gate) into PF 1.55 / avg_trade +0.675% (with gate). On SOL it does the opposite: with the gate the strategy is decisively NEGATIVE -- profit_factor 0.386 (worse than the 0.632 the un-gated SOL version scored), avg_trade_return_pct -1.474% (below the fee floor and negative), Sharpe -1.166 (CI [-2.80, 0.44]), total_return -13.4%, win_rate 0.36, avg_loss $1,364 > avg_win $937 (inverted RR). The gate cut trades 46 -> 25, precisely inside the developer's own predicted 15-25 band, which confirms the structural mechanism he and I both described: because SOL is the highest-beta major, by the time BTC's confluence fires SOL has usually ALREADY moved more than BTC, so it rarely has an un-transferred residual to harvest -- SOL LEADS more often than it lags. The few times the gate does fire, the residual is not a persistent lag but noise, and it loses. This is not a code fault (the construction is identical to the working ETH sibling and verified correct); it is conclusive evidence that SOL is the wrong vehicle for a lag-harvest.