Konträre Querschnitts-RETAIL-CROWDING-Rotation, Long-only (BINANCE USD-M, 8 Majors; WEEKLY die 3 am stärksten LEAST von Retail-Seite überfüllten Namen anhand des Long/Short Account-Ratio GLOBAL halten – ein reiner FACTOR der Unterbesitzung, kein Momentum; Cash-Gate bei systemischer Euphorie, 2 Parameter)

Ein LONG-ONLY, wöchentlich neu ausbalanciertes ROTATION im Querschnitt über das 8-Majors-USD-M-Universum (BTC, ETH, SOL, BNB, AVAX, LINK, ADA, XRP), das Namen anhand eines echten NON-PRICE-CROWDING-Signals auswählt: dem Long/Short-ACCOUNT-Verhältnis je Name GLOBAL (count_long_short_ratio, ein Proxy für die Positionierung von Privatanlegern) aus den Binance-VISION-„metrics“-Dateien (MULTI-YEAR bis ~2020, NOT dem 30-Tage-API). Der Mechanismus ist ein reiner UNDER-OWNERSHIP-Faktor: Es werden die Majors gehalten, bei denen Privatanleger überproportional auf Long-Positionen LEAST sind, denn stark überfüllte Long-Positionen bergen latentes Risiko von Long-Liquidationen und Squeeze-Abwärtsbewegungen, während wenig gehaltene Namen noch Raum für Kursanstiege haben. Dies gehört bewusst zur ONLY-Strukturfamilie, die sich hier reproduzierbar bewährt – Long-only, Majors, wöchentliches Halten der Top-K, wenige Parameter (die Sharpe-Ratio der eingesetzten Momentum-Rotation 2.6 und des Carry-Korbs mit negativem Funding 1.97) – und ergänzt beide um einen Auswahlfaktor ORTHOGONAL: weder relative Kursstärke (Momentum) noch Funding (Carry), sondern Crowd-Positionierung. Den Belegen aus der Sitzung zufolge vermeidet die Strategie alle bekannten Fehlschlagarten: NOT einen Richtungs-Timer für einen einzelnen Namen (diese scheiterten an -100% / -43% / Risikoablehnung), NOT einen dollar-neutralen Spread (kein Short-Leg → kein 90% DD-Desaster), NOT Funding/Optionen/Liquidationen/reines OHLCV. Die Strategie unterscheidet sich von der noch ausstehenden SmartMoneyGatedMomentumRotation (die die TOP-TRADER-Kohorte nutzt, um ein Momentum-Portfolio GATE) und von EthRetail (ein Long-Short-Fade für einen einzelnen Namen): Hier dient die RETAIL/globale Kohorte als PRIMARY-querschnittlicher Rangierungsschlüssel in einem konträren LONG-ONLY-Korb, ganz ohne Momentum-Komponente. 2-Parameter; K und Taktung sind auf die bewährte Vorlage festgelegt.

Behebt genau den von QA gemeldeten Defekt. QA wies den Ranking-Schlüssel zurück, weil Open Interest (a) kein Retail-Proxy ist — es handelt sich um das gesamte offene Notional über alle Teilnehmer — und (b) richtungsblind, da aggregierte Perp-Longs gleich den Shorts sind, sodass 'am wenigsten überfüllt-LONG' nicht ausgedrückt werden kann. Der neue Ranking-Schlüssel ist `taker_long_short_vol_ratio`, pro Leg gelesen aus `taker_flow_by_instrument`: es ist aggressives BUY-Volumen geteilt durch aggressives SELL-Volumen, daher ist er DIRECTIONAL per Konstruktion (ein hoher Wert bedeutet wörtlich, dass der Crowd in diesem Namen long tendiert) und es ist eine Aggressor-/Taker-seitige (retail-zugewandte) Kennzahl statt eines gesamten offenen Notionals. Er stammt auch aus genau denselben Binance-VISION-`metrics`-Dateien, die die Hypothese als Datenquelle benennt, mit derselben Mehrjahres-bis--2020-Historie — nur die Spalte unterscheidet sich. Das Ranking verwendet den eigenen z-Score jedes Namens (7-Tage-Mittel gegen 90-Tage-Mittel/sd), sodass strukturell unterschiedliche Taker-Niveaus über BTC und ADA hinweg vergleichbar sind, gemäß der Lehre, dass feste absolute Schwellenwerte bei ergänzenden Daten nicht skaleninvariant sind. DISCLOSED, NOT HIDDEN: der wörtliche Schlüssel der Hypothese ist das per-Name-GLOBAL Long/Short-ACCOUNT-Verhältnis (`long_short_ratio`, im selben Parquet), aber die Pipeline lädt `metrics` nur für das PRIMARY-Symbol, und die einzigen Per-Leg-Querschnittsverdrahtungen, die existieren, sind `funding_rates_by_instrument`, `open_interest_by_instrument` und `taker_flow_by_instrument` (subprocess_entry.py) — daher ist ein 8-Name-Rank auf dem Account-Verhältnis heute nicht im Strategie-Code ausdrückbar; es benötigt eine `global_ratio_by_instrument`-Verdrahtung, die diese drei spiegelt, was eine Pipeline-Änderung ist. Von den drei existierenden ist Taker-Flow die einzige, die sowohl direktional als auch retail-seitig ist, daher ist sie der treue Ersatz, und das Account-Verhältnis wird weiterhin verwendet, wo es IS verfügbar ist (das BTC-Euphorie-Cash-Gate). Vor der Einreichung gegen die realen Daten verifiziert: alle 8-Legs tragen 8-k-Punkt-gestridete Serien, die 1737-2193 Tage umspannen, 208/208 simulierte wöchentliche Rebalances über die letzten 4 Jahre erzeugen einen gerankten Querschnitt, und Positionen rotieren über jeden Namen (67-86 Picks jeweils), statt an einem zu kleben — also handelt dies und ist kein degeneriertes Ranking. Zwei weitere kleine Korrekturen wurden übernommen: die wöchentliche Kadenz ist jetzt kalenderverankert am Zeitstempel des Bars statt am prozessrelativen `_bar_i`-Zähler (neustartsicher, replay-identisch), und `exit_level` wird strikt unter `euphoria_level` gezwungen, sodass der Optimierer die Hysterese nicht in eine pro-Bar-Oszillation invertieren kann. Layer-3-Timeout-Sicherheit ist unverändert und erhalten: Präfixsummen + searchsorted halten jede pro-Bar-Lookup O(log n), und Parse-Zeit-Striding begrenzt __init__ auf ~10s, gemessen für alle 8-Legs.

verification_loop: Verifizierung fehlgeschlagen (Layer 4 — QA Prüfung) [class=hypothesis_mismatch]: - [edge_concern] Sandbox ist ein kohärenter Long-Only-Majors-Korb, der läuft und handelt (337 Trades, avg_trade_return_pct 0.69% übersteigt die Gebührenuntergrenze), aber total_return -20.85%, information_ratio -0.901 gegenüber der Equal-Weight-Korb-Benchmark, und max_drawdown 71% (CI bis 96%) deuten darauf hin, dass der substituierte Taker-Flow-Rangschlüssel im Vergleich zu einem naiven Equal-Weight-Hold negativen risikoadjustierten Wert hinzufügt. Dies ist nur beratend; es liegt stromabwärts der Rangschlüssel-Fehlanpassung und sollte vom Analysten bei einer korrigierten Implementierung neu beurteilt werden, hier nicht blockiert. - [kritisch] Das einzige definierende Merkmal der Hypothese -- im Titel/in der Beschreibung wiederholt ('nach GLOBAL Long/Short Account-Ratio', 'count_long_short_ratio', 'eine reine Under-Ownership FACTOR, nicht Momentum') -- ist, dass das CROSS-SECTIONAL RANKING KEY das per-Name globale Long/Short-ACCOUNT-Verhältnis ist, ein Retail-Positionierungs-/Besitz-Proxy, der absichtlich orthogonal zu Momentum und Funding ist. Der Code NOT nicht auf diesem. _crowd_z() / _rebalance() rangieren die 8 Majors nach `taker_long_short_vol_ratio` (aggressives BUY-Volumen / aggressives SELL-Volumen), gelesen aus `taker_flow_by_instrument`. Das Taker Long/Short-Volumen-Verhältnis ist ein FLOW/AGGRESSOR-Maß, kein Besitz-/Positionierungs-Maß -- es unterscheidet sich wesentlich vom Account-Verhältnis und ist vermutlich näher am Kurzfrist-Flow/Momentum, zu dem die Hypothese explizit orthogonal zu sein behauptet. Das benannte Account-Verhältnis wird nur für das sekundäre BTC-Euphorie-Cash-Gate (_parse_global / calculate_signal) verwendet, niemals für die primäre Auswahl. Gemäß der QA-Checkliste, wenn die spezifisch benannte Kernkante der Hypothese im Code fehlt, ist das kritisch: der angegebene Under-Ownership-Faktor ist nicht der gehandelte Faktor. (Zeile 259) — Fix: Entweder (a) das per-Instrument globale Account-Verhältnis in die Pipeline als `global_ratio_by_instrument` einspeisen (in Anlehnung an funding_rates_by_instrument / open_interest_by_instrument / taker_flow_by_instrument in subprocess_entry.py) und danach rangieren -- dies ist die getreue Implementierung, die die Hypothese benennt; oder (b) wenn diese Per-Leg-Serie wirklich nicht bereitgestellt werden kann, ist der Lauf ein DATA-Coverage-Block (not_measurable) und keine Strategie zum Shippen auf einem substituierten Schlüssel -- als solchen melden, damit die Hypothese geparkt wird, bis die Serie verdrahtet ist, anstatt still einen anderen (Flow-)Faktor zu handeln. Tue - [Warnung] Die Konsistenzprüfung markiert Hypothese 'WEEKLY' vs Konfig bar_type 1-DAY. Dies ist NOT eine echte Fehlpaarung: 'weekly' in der Hypothese bezieht sich auf die REBALANCE/HOLD-Kadenz, die korrekt als tägliche Bars implementiert ist, gesteuert durch ein kalenderverankertes 7-Tage-Rebalance (day % rebalance_days == 0). Wörtliche wöchentliche Bars würden das Euphorie-Perzentil und die Kadenz vergröbern; die Daily-Bar + 7-Tage-Rebalance-Konstruktion ist der korrekte Weg, eine wöchentliche Rotation auszudrücken. Zur Transparenz vermerkt; treibt das Urteil nicht. (Zeile 380) — Fix: Optional den Hypothesentext umformulieren zu 'weekly rebalance on daily bars', um die Layer-1.5-Konsistenzwarnung zum Schweigen zu bringen.

Verifizierung fehlgeschlagen (Layer 4 — QA Prüfung) [class=hypothesis_mismatch]: - [edge_concern] Sandbox ist ein kohärenter Long-Only-Majors-Korb, der läuft und handelt (337 Trades, avg_trade_return_pct 0.69% übersteigt die Gebührenuntergrenze), aber total_return -20.85%, information_ratio -0.901 gegenüber der Equal-Weight-Korb-Benchmark, und max_drawdown 71% (CI bis 96%) deuten darauf hin, dass der substituierte Taker-Flow-Rangschlüssel im Vergleich zu einem naiven Equal-Weight-Hold negativen risikoadjustierten Wert hinzufügt. Dies ist nur beratend; es liegt stromabwärts der Rangschlüssel-Fehlanpassung und sollte vom Analysten bei einer korrigierten Implementierung neu beurteilt werden, hier nicht blockiert. - [kritisch] Das einzige definierende Merkmal der Hypothese -- im Titel/in der Beschreibung wiederholt ('nach GLOBAL Long/Short Account-Ratio', 'count_long_short_ratio', 'eine reine Under-Ownership FACTOR, nicht Momentum') -- ist, dass das CROSS-SECTIONAL RANKING KEY das per-Name globale Long/Short-ACCOUNT-Verhältnis ist, ein Retail-Positionierungs-/Besitz-Proxy, der absichtlich orthogonal zu Momentum und Funding ist. Der Code NOT nicht auf diesem. _crowd_z() / _rebalance() rangieren die 8 Majors nach `taker_long_short_vol_ratio` (aggressives BUY-Volumen / aggressives SELL-Volumen), gelesen aus `taker_flow_by_instrument`. Das Taker Long/Short-Volumen-Verhältnis ist ein FLOW/AGGRESSOR-Maß, kein Besitz-/Positionierungs-Maß -- es unterscheidet sich wesentlich vom Account-Verhältnis und ist vermutlich näher am Kurzfrist-Flow/Momentum, zu dem die Hypothese explizit orthogonal zu sein behauptet. Das benannte Account-Verhältnis wird nur für das sekundäre BTC-Euphorie-Cash-Gate (_parse_global / calculate_signal) verwendet, niemals für die primäre Auswahl. Gemäß der QA-Checkliste, wenn die spezifisch benannte Kernkante der Hypothese im Code fehlt, ist das kritisch: der angegebene Under-Ownership-Faktor ist nicht der gehandelte Faktor. (Zeile 259) — Fix: Entweder (a) das per-Instrument globale Account-Verhältnis in die Pipeline als `global_ratio_by_instrument` einspeisen (in Anlehnung an funding_rates_by_instrument / open_interest_by_instrument / taker_flow_by_instrument in subprocess_entry.py) und danach rangieren -- dies ist die getreue Implementierung, die die Hypothese benennt; oder (b) wenn diese Per-Leg-Serie wirklich nicht bereitgestellt werden kann, ist der Lauf ein DATA-Coverage-Block (not_measurable) und keine Strategie zum Shippen auf einem substituierten Schlüssel -- als solchen melden, damit die Hypothese geparkt wird, bis die Serie verdrahtet ist, anstatt still einen anderen (Flow-)Faktor zu handeln. Tue - [Warnung] Die Konsistenzprüfung markiert Hypothese 'WEEKLY' vs Konfig bar_type 1-DAY. Dies ist NOT eine echte Fehlpaarung: 'weekly' in der Hypothese bezieht sich auf die REBALANCE/HOLD-Kadenz, die korrekt als tägliche Bars implementiert ist, gesteuert durch ein kalenderverankertes 7-Tage-Rebalance (day % rebalance_days == 0). Wörtliche wöchentliche Bars würden das Euphorie-Perzentil und die Kadenz vergröbern; die Daily-Bar + 7-Tage-Rebalance-Konstruktion ist der korrekte Weg, eine wöchentliche Rotation auszudrücken. Zur Transparenz vermerkt; treibt das Urteil nicht. (Zeile 380) — Fix: Optional den Hypothesentext umformulieren zu 'weekly rebalance on daily bars', um die Layer-1.5-Konsistenzwarnung zum Schweigen zu bringen.

Verifizierung fehlgeschlagen (Layer 2 – synthetische Szenarien): Verwendete Parameter: ['top_k', 'exit_level', 'min_notional', 'per_name_frac', 'euphoria_level', 'rebalance_days', 'euphoria_window'] Prüfen, ob __init__ alle Attribute über self.parameters.get() setzt. - steady_uptrend: TypeError: RetailCrowdingContrarianRotationLong._asof() akzeptiert 3 Positionsargumente, aber es wurden 4 übergeben (Balkenzeitstempel: 1735691940000) - steady_downtrend: TypeError: RetailCrowdingContrarianRotationLong._asof() akzeptiert 3 Positionsargumente, aber es wurden 4 übergeben (Balkenzeitstempel: 1735691940000) - flat_ranging: TypeError: RetailCrowdingContrarianRotationLong._asof() akzeptiert 3 Positionsargumente, aber es wurden 4 übergeben (Balkenzeitstempel: 1735691940000) - volatility_spike: TypeError: RetailCrowdingContrarianRotationLong._asof() akzeptiert 3 Positionsargumente, aber es wurden 4 übergeben (Balkenzeitstempel: 1735691940000) - zero_volume: TypeError: RetailCrowdingContrarianRotationLong._asof() akzeptiert 3 Positionsargumente, aber es wurden 4 übergeben (Balkenzeitstempel: 1735691940000) - price_gap: TypeError: RetailCrowdingContrarianRotationLong._asof() akzeptiert 3 Positionsargumente, aber es wurden 4 übergeben (Balkenzeitstempel: 1735691940000)

Verifizierung fehlgeschlagen (Layer 4 — QA Prüfung) [class=hypothesis_mismatch]: - [edge_concern] Sandbox ist ein Smoke-Test und kein Fehlergrund, aber Hinweis: metrics_reliable=false, Sharpe (0.10) vorzeichen-inkohärent mit total_return (-34.3%), MDD 70%, und das OI-Crowding-Buch verliert am meisten im gestressten Volatilitäts-Terzil (-37.8%). Wenn der Mechanismus bis zur Backtest-Prüfung überlebt, zuerst prüfen, ob der OI z-Rank überhaupt einen gerichteten Vorteil aufweist, da OI richtungsblind ist. - Die Kernkante der Hypothese ist ein querschnittlicher Rang auf GLOBAL LONG/SHORT ACCOUNT RATIO pro Name — ein gerichteter Retail-Under-Ownership-Faktor ('halte die Namen, auf denen Retail LEAST crowded-LONG ist'). Der Code rangiert stattdessen auf Per-Name-PERP OPEN INTEREST z-Score und hält die 3 niedrigsten. Dies ist ein substituierter Mechanismus, der die ökonomische Begründung nicht bewahrt: OI ist kein Retail-Proxy (es ist das gesamte offene Notional über alle Teilnehmer), und OI ist DIRECTION-BLIND (aggregierte Longs == Shorts in Perps), daher kann es 'am wenigsten crowded-long' nicht ausdrücken. Die spezifisch benannte Kante der Hypothese fehlt im Code → kritisch.

Verifikation fehlgeschlagen (Layer 4 — QA-Review) [class=hypothesis_mismatch]: - [edge_concern] Die Sandbox sieht gesund aus (+93%, Sharpe 0.77, PF 1.55, avg_trade_return_pct 6.63%) genau weil der Code eine Funding-Carry-Rotation ist, die der Entwickler als überlappend mit dem bereits ausgelieferten Negative-Funding-Carry-Basket bestätigt — daher sprechen die guten Zahlen gegen die Förderung eines Fast-Duplikats einer Live-Strategie, nicht für den orthogonalen Crowding-Faktor, den die Hypothese hinzufügen sollte. Hinweisend; der Block ist Treue. - Core-Edge nicht implementiert und der Ersatz ist der exakte Mechanismus, den die Hypothese EXCLUDES. Hypothese rankt nach per-Name-GLOBAL Long/Short-ACCOUNT-Verhältnis (Retail-Crowding), explizit 'kein Funding (Carry)... orthogonal zu Momentum und Funding'. Code rankt den Querschnitt nach per-Name-FUNDING (niedrigster = gehalten) — ein Funding-Carry-Rank, den der Entwickler als überlappend mit dem ausgelieferten Carry-Basket einräumt. Der Account-Verhältnis-Crowding-Schlüssel fehlt und ist nicht durchführbar (Metriken nur für Primärsymbol verdrahtet; kein metrics_by_instrument). - Rebalance-Kadenz verankert an einem prozessrelativen Bar-Zähler (self._bar_i % rebalance_days), nicht am Bar-Zeitstempel. Neustarts setzen _bar_i zurück und driften das wöchentliche Rotationsraster von jedem festen Kalendertag ab; Parity-Replay kann Rotationsdaten nicht reproduzieren. Mildere Item-20-Form (kein Sentinel/First-Bar-Fire). Aus Tagen-seit-Epoche oder einem festen Wochentag ableiten.

verification_loop: Verifikation fehlgeschlagen (Layer 4 — QA-Review) [class=hypothesis_mismatch]: - [edge_concern] Sandbox ist ein kohärenter Long-Only-Majors-Basket, der läuft und handelt (337 Trades, avg_trade_return_pct 0.69% übersteigt die Gebührenuntergrenze), aber total_return -20.85%, information_ratio -0.901 vs den Equal-Weight-Basket-Benchmark, und max_drawdown 71% (CI bis 96%) legen nahe, dass der substituierte Taker-Flow-Ranking-Schlüssel gegenüber einem naiven Equal-Weight-Hold einen negativen risikoadjustierten Mehrwert hinzufügt. Dies ist nur hinweisend; es ist nachgelagert zum Ranking-Schlüssel-Mismatch und sollte vom Analysten bei einer korrigierten Implementierung neu beurteilt werden, hier nicht blockiert. - [critical] Das einzige definierende Merkmal der Hypothese -- durchgehend im Titel/der Beschreibung wiederholt ('nach GLOBAL Long/Short Account-Ratio', 'count_long_short_ratio', 'ein reiner Under-Ownership FACTOR, nicht Momentum') -- ist, dass die CROSS-SECTIONAL RANKING KEY das per-Name globale Long/Short-ACCOUNT-Verhältnis ist, ein Retail-Positionierungs-/Ownership-Proxy, der bewusst orthogonal zu Momentum und Funding ist. Der Code NOT-rankt darauf. _crowd_z() / _rebalance() ranken die 8 Majors nach `taker_long_short_vol_ratio` (aggressives BUY-Volumen / aggressives SELL-Volumen), gelesen aus `taker_flow_by_instrument`. Das Taker Long/Short-Volumenverhältnis ist eine FLOW/AGGRESSOR-Kennzahl, keine Ownership-/Positionierungs-Kennzahl -- es unterscheidet sich materiell vom Account-Verhältnis und ist argumentativ näher am Kurzhorizont-Flow/Momentum, zu dem die Hypothese explizit orthogonal zu sein beansprucht. Das benannte Account-Verhältnis wird nur für das sekundäre BTC-Euphorie-Cash-Gate verwendet (_parse_global / calculate_signal), niemals für die primäre Selektion. Per QA-Checkliste: wenn die spezifisch benannte Kern-Edge der Hypothese im Code fehlt, ist das kritisch: der genannte Under-Ownership-Faktor ist nicht der gehandelte Faktor. (Zeile 259) — Fix: Entweder (a) das globale Per-Instrument-Account-Verhältnis als `global_ratio_by_instrument` in die Pipeline verdrahten (spiegelnd funding_rates_by_instrument / open_interest_by_instrument / taker_flow_by_instrument in subprocess_entry.py) und darauf ranken -- dies ist die treue Implementierung, die die Hypothese benennt; oder (b) wenn diese Per-Leg-Serie tatsächlich nicht bereitgestellt werden kann, ist der Run ein DATA-Coverage-Block (not_measurable) statt einer Strategie zum Ausliefern auf einem substituierten Schlüssel -- als solchen melden, damit die Hypothese geparkt wird, bis die Serie verdrahtet ist, statt stillschweigend einen anderen (Flow-)Faktor zu handeln. Do - [warning] Die Konsistenzprüfung markiert Hypothese 'WEEKLY' vs Konfig bar_type 1-DAY. Dies ist NOT ein echtes Mismatch: 'weekly' in der Hypothese bezieht sich auf die REBALANCE/HOLD-Kadenz, die korrekt als tägliche Bars implementiert ist, gegated durch ein kalenderverankertes 7-Tage-Rebalance (day % rebalance_days == 0). Wörtliche wöchentliche Bars zu verwenden würde das Euphorie-Perzentil und die Kadenz vergröbern; die Konstruktion aus täglichem Bar + 7-Tage-Rebalance ist die korrekte Weise, eine wöchentliche Rotation auszudrücken. Zur Transparenz vermerkt; treibt das Urteil nicht. (Zeile 380) — Fix: Optional den Hypothesentext umformulieren zu 'weekly rebalance on daily bars', um die Layer-1.5-Konsistenzwarnung zum Schweigen zu bringen.