Возврат соотношения ETH/BTC к среднему + фильтр ставки финансирования

Дополнение к стратегии возврата к среднему по z-оценке ETH/BTC: добавлен фильтр режима ставки финансирования, чтобы пропускать входы на перегруженных направленных рынках. Та же базовая логика: бары по 4 ч на Binance USD-M Futures, соотношение = ETHUSDT_close / BTCUSDT_close, скользящая z-оценка за 20 периодов, вход при |z| > 2.0, выход при |z| < 0.5, |z| > 3.5 (стоп) или по тайм-стопу через 7 дней. NEW: нужны дополнительные данные funding_rates для обоих инструментов — ETHUSDT и BTCUSDT. Рассчитывается funding_spread = funding_ETH - funding_BTC (в годовом выражении, в базисных пунктах). Пропускаются входы, когда |funding_spread| > 10 б. п. в годовом выражении SKIP, когда |funding_ETH| > 50 б. п. в годовом выражении OR или |funding_BTC| > 50 б. п. в годовом выражении OR: эти условия указывают на перегруженные направленные позиции, при которых возврат к среднему часто не срабатывает (резкий рост в альтсезон, капитуляция BTC и т. п.). Сделка также пропускается, если её направление означало бы уплату ставки финансирования по обеим ногам BOTH (например, лонг ETH + шорт BTC, когда ставка финансирования ETH положительная AND BTC отрицательная). Номинал на каждую ногу равен USD, плечо 1-2x, размер позиции зависит от капитала. Преимущество: избежать примерно 20-30% сделок, где возврат к среднему идёт против общего движения, и отобрать более чистые сигналы возврата. Гипотеза: фильтр ставки финансирования повысит коэффициент Шарпа на 0.2-0.4 и снизит максимальную просадку на 25%+ относительно базовой стратегии DD. Риски: фильтр может быть слишком строгим на трендовых крипторынках (сократит выборку); при запросе данных ставок финансирования нужно правильно сопоставлять интервал 8 ч, а формат временных меток parquet — datetime64, а не миллисекунды Unix.

Итерация -2: минимальное исправление для проверки leverage_set_but_unused. Причина: путь расчёта размера позиции косвенно считывал плечо через getattr(self.config, 'leverage', ...) внутри вспомогательной функции _leg_notional(), поэтому статическая проверка, которая просматривает position_size() на прямое обращение к self.config.leverage, не обнаруживала его и считала leverage=2.0 неработающим. Исправление заставляет position_size() напрямую считывать self.config.leverage и вычислять notional = equity * leg_notional_frac * leverage / price в строке; функция _leg_notional() (используемая для ноги BTC) тоже переведена на прямое обращение к атрибуту. Теперь плечо явно масштабирует номинал обеих ног, поэтому leverage=2.0 создаёт действительно в 2x раза большую позицию, чем 1x. Больше ничего не изменилось: импорты прежние (слой 1 проходит), а сигнал z-оценки, фильтр ставки финансирования, условия входа и выхода и отправка заявок по нескольким ногам, прошедшие предыдущие слои, побайтно идентичны. При отсутствии данных фильтр ставки финансирования по-прежнему пропускает сделки, чтобы проверять базовое преимущество возврата к среднему; буфер соотношения остаётся единой синхронизированной серией. Площадка: фьючерсы BINANCE USD-M (одна нога в шорт, фильтр на основе ставки финансирования); leverage=2.0 не превышает лимит плеча для фьючерсов 20x.

Это дополнение с фильтром по ставке финансирования к уже заброшенной парной стратегии возврата к среднему по z-оценке ETH/BTC, и оно воспроизводит тот же катастрофический провал: коэффициент Шарпа -0.91 (CI -1.79 до -0.05, полностью отрицательный), profit_factor 0.81, total_return -91.3%, математическое ожидание -$99.5/сделку, max_drawdown 93.9%, отрицательный результат за ALL 7 лет (2020 -63%, 2021 -32%, 2022 -17%, 2023 -31%, 2024 -20%, 2025 -15%, 2026 -5%). Гипотеза несостоятельна: отношение ETH/BTC следует тренду, а не возвращается к среднему, поэтому возврат по z-оценке постоянно идет против тренда и приводит к убыткам при любом режиме — именно такое поведение погубило родственную стратегию (коэффициент Шарпа -1.97/-1.23). Предполагаемая новая функция ничего не меняет: пороговые значения фильтра по ставке финансирования оставлены на уровне funding_spread_max_bps=1000 и funding_leg_max_bps=5000 (в годовом выражении, б.п.) — уровни, которых реальные спреды финансирования ETH/BTC почти никогда не достигают. Поэтому фильтр редко блокирует входы, и все 912 сделок фактически совершаются без фильтрации — предполагаемого «пропуска ~20-30% переполненных входов» не происходит, так что это не содержательный вариант базовой стратегии. Ситуацию усугубляет то, что показатель avg_position_pct равен 138% (leg_notional_frac 0.5 x две позиции x плечо), превращая убыточный сигнал в обвал с доходностью -91% и просадкой 94%. Утверждение benchmark_meaningful неверно (пара рыночно-нейтральная), поэтому оценка основана на абсолютных метриках, которые катастрофичны. Не оптимизировать: никакой набор параметров не спасет сигнал, убыточный во все 7 лет; родственная стратегия уже показала, что у возврата ETH/BTC к среднему нет преимущества. Не дорабатывать: ужесточение фильтра по ставке финансирования, чтобы он действительно срабатывал, лишь отфильтрует входы базового сигнала, который сам отрицателен при любом режиме. Более избирательная фильтрация убыточной стратегии всё равно оставляет её убыточной; изъян в гипотезе, а не в фильтре. Это NOT проблема с зачислением выплат по ставке финансирования (движок теперь учитывает выплаты по ставке финансирования) — это несостоятельная гипотеза возврата к среднему в сочетании с бездействующим фильтром. FAILURE PATTERN: возврат к среднему по z-оценке отношения ETH/BTC (и криптовалют с большой капитализацией) не имеет преимущества — отношение следует тренду, а не возвращается к среднему, поэтому входы на возврат при |z|>2 идут против устойчивых движений и дают убыток каждый год (PF <0.85, отрицательный коэффициент Шарпа, глубокие просадки); добавление фильтра режима или ставки финансирования не помогает, когда (а) пороговые значения фильтра настолько мягкие, что он никогда не срабатывает, и (б) базовый сигнал отрицателен при любом режиме. «Новый вариант», который оставляет убыточное ядро без изменений и добавляет бездействующую функцию, — это та же заброшенная стратегия.