ETH/BTC Ratio Mean Reversion + Funding Filter

Companion variant to the ETH/BTC z-score mean reversion strategy, adding a funding-rate regime filter to skip entries during crowded directional markets. Same base logic: 4h bars on Binance USD-M Futures, ratio = ETHUSDT_close / BTCUSDT_close, 20-period rolling z-score, entry at |z| > 2.0, exit at |z| < 0.5 or |z| > 3.5 (stop) or 7-day time stop. NEW: requires funding_rates supplementary data for both ETHUSDT and BTCUSDT. Compute funding_spread = funding_ETH - funding_BTC (annualized, in basis points). SKIP entries when |funding_spread| > 10 bps annualized OR when |funding_ETH| > 50 bps annualized OR |funding_BTC| > 50 bps annualized — these conditions indicate crowded directional positioning where mean reversion often fails (alt-season melt-ups, BTC capitulation, etc.). Also skip when the trade direction would be paying funding on BOTH legs (e.g., long ETH + short BTC when ETH funding positive AND BTC funding negative). Position sizing equal USD notional per leg, 1-2x leverage, capital-relative. Edge: avoid the ~20-30% of trades that are mean-reversion-against-the-tape and capture the cleaner reversion signals. Hypothesis: funding filter lifts Sharpe by 0.2-0.4 and reduces max DD by 25%+ vs base strategy. Risks: filter may be too restrictive in trending crypto markets (reduces sample size), funding data lookups must handle the 8h funding interval mapping correctly, parquet timestamp format is datetime64 not int ms.

Iteration-2 minimal fix for the leverage_set_but_unused gate. Root cause: the sizing path read leverage only indirectly via getattr(self.config, 'leverage', ...) inside the _leg_notional() helper, so the static gate that inspects position_size() for a direct self.config.leverage reference saw no usage and judged leverage=2.0 inert. The fix makes position_size() read self.config.leverage directly and compute notional = equity * leg_notional_frac * leverage / price inline, and switches _leg_notional() (used for the BTC leg) to the same direct attribute form. Leverage now visibly scales both legs' notional, so leverage=2.0 produces a genuinely 2x-larger position than 1x. Nothing else changed: imports are unchanged (Layer 1 stays green), and the z-score signal, funding filter, entry/exit gates, and multi-leg submission that passed earlier layers are byte-identical. The funding filter remains permissive when data is missing so the core reversion edge is still tested, and the ratio buffer stays a single synced series. Venue is BINANCE USD-M futures (shorts one leg, funding-rate-based filter); leverage=2.0 is within the 20x futures cap.

This is the funding-filter companion to the already-abandoned ETH/BTC z-score mean-reversion pairs strategy, and it reproduces the same catastrophic failure: Sharpe -0.91 (CI -1.79 to -0.05, entirely negative), profit_factor 0.81, total_return -91.3%, expectancy -$99.5/trade, max_drawdown 93.9%, and negative in ALL 7 years (2020 -63%, 2021 -32%, 2022 -17%, 2023 -31%, 2024 -20%, 2025 -15%, 2026 -5%). The premise is dead: the ETH/BTC ratio trends rather than mean-reverts, so z-score reversion continuously fades the trend and loses across every regime -- the exact behavior that killed the sibling (Sharpe -1.97/-1.23). The supposed new feature does nothing: the funding-filter thresholds are left at funding_spread_max_bps=1000 and funding_leg_max_bps=5000 (annualized bps), levels real ETH/BTC funding spreads almost never reach, so the filter rarely blocks and all 912 trades run effectively unfiltered -- the hypothesized 'skip ~20-30% of crowded entries' never occurs, making this not a meaningful variant of the base strategy. Compounding it, avg_position_pct is 138% (leg_notional_frac 0.5 x two legs x leverage), turning a losing signal into a -91% return / 94% drawdown blowup. benchmark_meaningful is false (market-neutral pair), so this is judged on absolute metrics, which are catastrophic. Not optimize: no parameter set rescues a signal that loses in all 7 years; the sibling already established ETH/BTC reversion has no edge. Not iterate: tightening the funding filter to actually fire would only filter entries of a base signal that is itself negative in every regime -- filtering a losing strategy more selectively still loses; the premise, not the filter, is the flaw. This is NOT a funding-creditability issue (the engine now credits funding) -- it is a dead mean-reversion premise plus an inert filter. FAILURE PATTERN: ETH/BTC (and large-cap crypto) ratio z-score mean-reversion has no edge -- the ratio trends rather than mean-reverts, so |z|>2 reversion entries fade persistent moves and lose in every year (PF <0.85, negative Sharpe, deep drawdowns); bolting on a regime/funding filter does not help when (a) the filter thresholds are set so loose they never fire and (b) the underlying signal is negative across all regimes. A 'new variant' that leaves the losing core untouched and adds an inert feature is the same abandoned strategy.