Récolte de l’écart de financement entre plateformes — SOL neutre en delta : vendre à découvert le perpétuel au financement le plus élevé / acheter le perpétuel au financement le plus bas sur BINANCE contre HYPERLIQUID, percevoir le SPREAD de financement (pas le portage directionnel), arrêt sur la base, détention sur plusieurs jours (2 jambes, neutre au marché, 3 paramètres)

Une stratégie de valeur relative CROSS-VENUE, MARKET-NEUTRAL qui récolte l’écart de FUNDING-RATE SPREAD entre les perpétuels de l’actif SAME sur deux plateformes différentes — BINANCE USD-M SOLUSDT contre HYPERLIQUID SOLUSD. Les deux jambes sont des perpétuels sur le même sous-jacent, la position est donc neutre en delta par construction : vous ne NOT prenez pas de pari directionnel sur le prix et vous ne NOT faites pas de portage de financement sur une seule jambe (le mécanisme qui a fait perdre de l’argent dans le « SOL swing contrariant à financement persistant » abandonné). La source de PnL ONLY est le différentiel de financement — vous SHORT vendez à découvert sur la plateforme qui verse le financement le plus positif (les positions courtes y reçoivent le financement) et prenez simultanément une position longue de notionnel égal LONG sur la plateforme où le financement est plus bas ou négatif (les positions longues reçoivent le financement ou en paient moins). Comme les deux jambes suivent le même sous-jacent, le PnL directionnel des prix net est d’environ 0 ; la variance résiduelle n’est que la petite BASIS à retour à la moyenne (écart de prix entre les deux plateformes), plafonnée par un stop ferme sur la base. Il s’agit d’un arbitrage du financement entre plateformes (modèle interplateformes n° 3, hybride avec le n° 2), un avantage structurellement peu exploré et tolérant aux frais — il capture un flux de trésorerie payé mécaniquement plutôt que de lutter contre les frictions. Cette stratégie a été choisie car le portefeuille manque d’exposition interplateformes (7.4% contre la cible 15%) et longue-courte/neutre au marché (14.2%), et parce que les données de financement pour BOTH Binance et Hyperliquid SOL figurent dans le catalogue avec un historique pluriannuel à résolution quotidienne/4 h (HL quotidienne/4 h ne limite pas l’historique). SOL a été choisi pour la dispersion significative de son financement entre plateformes (altcoin à bêta plus élevé), tout en restant très liquide sur les deux plateformes. Seulement 3 paramètres libres (seuil d’écart à l’entrée, seuil d’écart à la sortie, stop sur la base) pour limiter le surajustement, risque principal du n° 1 ici.

L’itération 2 corrige le QA hypothesis_mismatch (intervalle de temps) : l’horloge d’échantillonnage est désormais fixée à 4-HOUR bougies sur les jambes BOTH, conformément à la « résolution quotidienne/4h » indiquée dans l’hypothèse et aux positions conservées pendant plusieurs jours, au nom même de cette classe et à l’intervalle dans lequel chaque paramètre exprimé en bougies est calibré (spread_smooth_bars 24 x 4H = 4 jours) ; 4H est également un diviseur exact du règlement du financement toutes les 8h de Binance, de sorte qu’aucun règlement n’est chevauché. Aucun rééchantillonnage unilatéral vers un autre intervalle. Vérification faite : les deux jambes existent dans le catalogue en 4H (SOLUSDT.BINANCE-4-HOUR et SOLUSD.HYPERLIQUID-4-HOUR, historique de HL depuis 2024-01), de sorte que le contrôle des données multi-jambes ne peut pas interrompre l’exécution. La logique de signal, d’entrée et de sortie, les imports et la structure sont inchangés par rapport à previous_code (les couches précédentes sont restées validées) ; la seule autre modification déclare le bornage spread_smooth_bars [6, 48] dans _param_bounds, afin que l’optimiseur ne recherche jamais des valeurs que le code réécrit silencieusement. Note pour mémoire : le texte de retour QA citait un cas hebdomadaire contre quotidien ETHUSDT qui ne correspond pas à cette paire SOL inter-plateformes ; j’ai donc appliqué la règle générale d’alignement des intervalles de temps plutôt que les détails littéraux ETH. Un notionnel USD égal sur les deux jambes maintient le delta net à ~0, conformément à la leçon L59 ; l’effet de levier reste 1.0 et n’est pas pris en compte dans le dimensionnement.

Sandbox est essentiellement à l'équilibre : total_return +0.167% sur 2181 jours, avg_trade_return_pct 0.1135% (en dessous du plancher de 0.15% pour les futures), profit_factor 1.013, win_rate 0.50 sur seulement 22 trades. Il s'agit d'un smoke test non optimisé donc il ne bloque pas, mais deux points que l'analyste devrait vérifier avec les chiffres de l'historique complet : (1) que le backtest NautilusTrader crédite réellement les flux de trésorerie de FUNDING perp sur les deux jambes — le funding est la source de PnL ENTIRE de cette stratégie, et si le funding n'est pas appliqué, le rendement mesuré n'est que du bruit de base moins les frais ; (2) la viabilité frais/carry aux seuils réels — le différentiel (~8.6% APR ≈ 0.024%/jour) nécessite ~8 jours correctement positionnés pour couvrir l'aller-retour à deux jambes de 0.19%, donc l'edge par trade est mince et dépend de la durée de détention (durée moyenne observée ~29j). Noter également impact_cost_pct 44.9% / capacité ~$495K à per_leg_pct 0.50 (150% d'exposition brute) — un véritable plafond de capacité, bien que ponctuel sur l'entrée/sortie à faible turnover d'un book d'environ 22 trades.

Vérification échouée (Couche 2 — scénarios synthétiques) : Paramètres utilisés : ['per_leg_pct', 'min_notional', '_param_bounds', 'max_hold_days', 'min_hold_hours', 'exit_spread_apr', 'enter_spread_apr', 'max_basis_stop_pct', 'spread_smooth_bars'] Vérifier que __init__ définit tous les attributs à partir de self.parameters.get(). - steady_uptrend : TypeError : SolCrossVenueFundingSpreadNeutral4H._lookup() prend 4 arguments positionnels, mais 5 ont été fournis (horodatage de la bougie : 1735690740000) - steady_downtrend : TypeError : SolCrossVenueFundingSpreadNeutral4H._lookup() prend 4 arguments positionnels, mais 5 ont été fournis (horodatage de la bougie : 1735690740000) - flat_ranging : TypeError : SolCrossVenueFundingSpreadNeutral4H._lookup() prend 4 arguments positionnels, mais 5 ont été fournis (horodatage de la bougie : 1735690740000) - volatility_spike : TypeError : SolCrossVenueFundingSpreadNeutral4H._lookup() prend 4 arguments positionnels, mais 5 ont été fournis (horodatage de la bougie : 1735690740000) - zero_volume : TypeError : SolCrossVenueFundingSpreadNeutral4H._lookup() prend 4 arguments positionnels, mais 5 ont été fournis (horodatage de la bougie : 1735690740000) - price_gap : TypeError : SolCrossVenueFundingSpreadNeutral4H._lookup() prend 4 arguments positionnels, mais 5 ont été fournis (horodatage de la bougie : 1735690740000)

Vérification échouée (Couche 4 — examen QA) : - La viabilité des frais et de l’avantage échoue de manière décisive selon le résultat du moteur ACTUAL (point de la liste de contrôle n° 7, L6/L26). Le bac à sable est un portefeuille perdant : total_return -2.17%, profit_factor 0.957 (<1.0), Sharpe -0.35, espérance -$45/transaction, et avg_trade_return_pct -0.0033% — NEGATIVE et environ 45x sous le plancher des contrats à terme 0.15%. L’échantillon est mesurable (82 transactions, metrics_reliable: true), il s’agit donc d’un véritable résultat sans avantage. Le financement WAS est crédité (2580 événements) ; ainsi, même avec le différentiel intégralement versé, la stratégie ne couvre pas le coût aller-retour d’environ 0.19%. - L’hypothèse centrale — « le PnL directionnel des prix net est d’environ 0 ; la variance résiduelle n’est que la petite base à retour à la moyenne » — n’est NOT ce que le moteur a produit. Le PnL par transaction est dominé par d’énormes fluctuations symétriques : avg_win $2,009 ~= avg_loss $2,099, plus grande variation ±$9,600-9,959, win_rate 0.50. Une stratégie véritablement neutre en delta de récolte de l’écart de financement devrait afficher un PnL d’un ordre de grandeur inférieur et une asymétrie positive due au portage ; au lieu de cela, le différentiel (net -$45/transaction) est éclipsé d’environ 45:1 par le bruit de base et de prix. Signature identique à celle d’EthCrossVenueCashAndCarry abandonnée et des variantes antérieures de capture du financement entre plateformes.

Vérification échouée (Couche 4 — examen QA) [classe=hypothesis_mismatch]: - [edge_concern] Ce n’est pas la raison du verdict ; consigné pour l’analyste si l’hypothèse est réenregistrée : sur l’horloge quotidienne, le bac à sable est honnête et sain (metrics_reliable=TRUE, 92 transactions, Sharpe 0.79 CI [0.10,1.51], avg_trade_return_pct 3.61%, PF 1.48), mais regime_performance montre ALL du rendement positif concentré dans le tercile de volatilité « normal » (+489%, Sharpe 2.64), tandis que les terciles « calme » (-18.8%) et « sous tension » (-21.8%, 56.7% DD) sont tous deux négatifs, et only_one_regime=true. Perte maximale 36% avec une durée sous l’eau de 1038 jours. L’avantage est réel, mais concentré selon le régime et associé à de forts drawdowns ; la taille et la robustesse méritent d’être examinées sur le backtest complet. - TIMEFRAME MISMATCH par rapport à l’hypothèse préenregistrée. L’hypothèse de référence (titre et description dans ce brief) spécifie sans ambiguïté et à plusieurs reprises des bougies WEEKLY (« sur des bougies WEEKLY, avec des positions détenues pendant des semaines à des mois »), mais config.bar_type vaut ETHUSDT.BINANCE-1-DAY-LAST-EXTERNAL. Il ne s’agit pas d’un rééchantillonnage cosmétique : cela modifie le nombre de transactions (28 hebdomadaires -> 92 quotidiennes), la durée moyenne de détention (10.4 semaines -> 3 semaines) et l’ensemble du test statistique. La docstring du module du développeur reconnaît elle-même que l’itération 3 a effectué ce même basculement quotidien et que QA « avait raison de le rejeter : il s’agissait d’une reformulation de l’hypothèse effectuée unilatéralement dans le code ». La situation n’a pas matériellement changé : l’hypothèse consignée indique toujours une fréquence hebdomadaire, il s’agit donc à nouveau d’une reformulation unilatérale de la fréquence dans le code. La couche 1.5 ne valide que l’instrument et la place de négociation, pas la fréquence ; ce contrôle relève donc de QA, et une fréquence spécifiée dans l’hypothèse qui diffère de config.bar_type constitue une divergence critique. C’est précisément le degré de liberté du chercheur que le système de préenregistrement de la fabrique vise à empêcher : la forme hebdomadaire s’est révélée impossible à mesurer, puis l’horloge d’échantillonnage a été modifiée pour fabriquer une mesurabilité.