Cross-Sectional RETAIL-CROWDING Rotação Contrária, Long-Only (BINANCE USD-M, 8 Majors, WEEKLY Manter os 3 LEAST Nomes Mais Crowded de Retalho por Rácio Long/Short de Contas GLOBAL — um Fator Puro de Sub-Propriedade FACTOR, Não Momentum; Gate de Cash de Euforia Sistémica, 2-Parâmetro)

Uma LONG-ONLY, ROTATION transversal com rebalanceamento semanal sobre o universo de 8 principais USD-M (BTC, ETH, SOL, BNB, AVAX, LINK, ADA, XRP), selecionando ativos com base num sinal genuíno de NON-PRICE CROWDING: o rácio GLOBAL long/short ACCOUNT (count_long_short_ratio, um indicador da posição do retalho) dos ficheiros «metrics» da Binance VISION (de MULTI-YEAR até cerca de 2020, NOT o 30-day API). O mecanismo é um fator puramente UNDER-OWNERSHIP: manter os principais ativos em que o retalho está mais LEAST posicionado em posições longas, porque ativos com posições longas congestionadas comportam risco latente de liquidações de posições longas/descida em squeeze, enquanto os ativos subdetidos têm margem para subir. Esta estratégia enquadra-se deliberadamente na família estrutural ONLY que aqui sobrevive de forma reproduzível — apenas posições longas, principais ativos, manter semanalmente os K melhores, poucos parâmetros (Sharpe 2.6 da rotação de momentum implementada e Sharpe 1.97 da carteira de carry com financiamento negativo) — e acrescenta uma chave de seleção ORTHOGONAL a ambas: não força relativa do preço (momentum), nem financiamento (carry), mas posicionamento da multidão. De acordo com as evidências da sessão, evita todos os modos de falha: NOT um temporizador direcional de ativo único (essas estratégias falharam -100% / -43% / rejeição por risco), NOT um spread delta-neutro (sem perna curta → sem explosão de 90% DD), NOT financiamento/opções/liquidações/puro-OHLCV. É distinta da SmartMoneyGatedMomentumRotation pendente (que usa a coorte TOP-TRADER para GATE uma carteira de momentum) e da EthRetail (reversão long-short de ativo único): esta usa a coorte RETAIL/global como chave de ordenação transversal PRIMARY numa carteira LONG-ONLY contrária, sem qualquer componente de momentum. Parâmetros 2, K e cadência fixados de acordo com o modelo comprovado.

Corrige o defeito exato QA levantado. QA rejeitou a chave de classificação porque open interest não é (a) uma proxy de retalho — é o nocional aberto total entre todos os participantes — e (b) é agnóstico em termos de direção, uma vez que os longs agregados de perp igualam os shorts, pelo que não pode expressar 'menos crowded-LONG'. A nova chave de classificação é `taker_long_short_vol_ratio` lida por perna a partir de `taker_flow_by_instrument`: é volume agressivo de BUY dividido por volume agressivo de SELL, pelo que é DIRECTIONAL por construção (um valor elevado significa literalmente que a multidão está mais long nesse nome) e é uma medida do lado agressor/taker (voltada para o retalho) em vez do nocional aberto total. Também vem dos mesmos ficheiros Binance de VISION `metrics` que a hipótese nomeia como sua fonte de dados, com o mesmo histórico de múltiplos anos até -2020 — apenas a coluna difere. A classificação usa o z-score próprio de cada nome (média de 7d vs média/desvio-padrão de 90d) para que níveis de taker estruturalmente diferentes comparem entre BTC e ADA, conforme a lição de que limiares absolutos fixos em dados suplementares não são invariantes à escala. DISCLOSED, NOT HIDDEN: a chave literal da hipótese é o rácio GLOBAL long/short ACCOUNT por nome (`long_short_ratio`, no mesmo parquet), mas o pipeline carrega `metrics` apenas para o símbolo PRIMARY, e as únicas cablagens cross-section por perna que existem são `funding_rates_by_instrument`, `open_interest_by_instrument` e `taker_flow_by_instrument` (subprocess_entry.py) — pelo que um rank de 8 nomes no rácio de contas não é expressável no código de estratégia atual; precisa de uma cablagem `global_ratio_by_instrument` que espelhe essas três, o que constitui uma alteração ao pipeline. Das três que existem, o taker flow é a única que é simultaneamente direcional e do lado do retalho, pelo que é o substituto fiel, e o rácio de contas continua a ser usado quando IS está disponível (o gate de cash de euforia BTC). Verificado contra os dados reais antes de submeter: todas as 8 pernas transportam séries estranguladas de 8k pontos abrangendo 1737-2193 dias, 208/208 rebalanceamentos semanais simulados ao longo dos últimos 4 anos produzem uma cross-section ordenada, e as posições rodam por todos os nomes (67-86 escolhe cada um) em vez de se fixarem num só — pelo que isto negoceia e não é uma classificação degenerada. Mais duas pequenas correções adicionais: a cadência semanal está agora ancorada ao calendário com base no timestamp do bar em vez do contador relativo ao processo `_bar_i` (seguro em reinício, idêntico em replay), e `exit_level` é forçado a estar estritamente abaixo de `euphoria_level` para que o optimizer não possa inverter a histerese numa oscilação por bar. A segurança de timeout da Layer-3 está inalterada e preservada: somas de prefixo + searchsorted mantêm cada lookup por bar em O(log n), e o striding em tempo de parse limita o __init__ a ~10s medidos para todas as 8 pernas.

verification_loop: Verificação falhou (Camada 4 — revisão QA) [classe=hypothesis_mismatch]: - [edge_concern] O sandbox é uma basket long-only de majors coerente que corre e negoceia (337 negócios, avg_trade_return_pct 0.69% ultrapassa o limiar de comissões), mas total_return -20.85%, information_ratio -0.901 face ao benchmark de basket equally-weighted, e max_drawdown 71% (CI a 96%) sugerem que a chave de ranking de taker flow substituída adiciona valor negativo ajustado ao risco face a uma detenção equally-weighted ingénua. Isto é apenas consultivo; é consequência do desfasamento da chave de ranking e deve ser reavaliado pelo analista numa implementação corrigida, não bloqueado aqui. - [crítico] A única característica definidora da hipótese -- reafirmada ao longo do título/descrição ('por GLOBAL Long/Short Account-Ratio', 'count_long_short_ratio', 'uma Pure Under-Ownership FACTOR, Not Momentum') -- é que a CROSS-SECTIONAL RANKING KEY é o rácio global long/short ACCOUNT por nome, um proxy de posicionamento/propriedade de retail que é deliberadamente ortogonal ao momentum e ao funding. O código NOT classifica com base nisso. _crowd_z() / _rebalance() classificam os 8 majors por `taker_long_short_vol_ratio` (volume BUY agressivo / volume agressivo SELL) lido de `taker_flow_by_instrument`. O rácio de volume taker long/short é uma medida de FLOW/AGGRESSOR, não uma medida de propriedade/posicionamento -- é materialmente diferente do account ratio e é arguivelmente mais próximo do flow/momentum de horizonte curto ao qual a hipótese explicitamente alega ser ortogonal. O account ratio nomeado é usado apenas para o gate de caixa de euforia BTC secundário (_parse_global / calculate_signal), nunca para a seleção primária. Segundo a checklist QA, quando o edge central específico nomeado da hipótese está ausente do código, isso é crítico: o fator de sub-propriedade declarado não é o fator que está a ser negociado. (linha 259) — correção: Ou (a) integrar o rácio de conta global por instrumento no pipeline como `global_ratio_by_instrument` (espelhando funding_rates_by_instrument / open_interest_by_instrument / taker_flow_by_instrument em subprocess_entry.py) e classificar com base nisso -- esta é a implementação fiel que a hipótese nomeia; ou (b) se essa série por leg genuinamente não puder ser fornecida, a execução é um bloco DATA-coverage (not_measurable) em vez de uma estratégia para enviar numa chave substituída -- reportar como tal para que a hipótese fique parqueada até a série ser integrada, em vez de negociar silenciosamente um fator (flow) diferente. Fazer - [aviso] A verificação de consistência assinala a hipótese 'WEEKLY' vs config bar_type 1-DAY. Isto NOT um desfasamento genuíno: 'weekly' na hipótese refere-se à cadência REBALANCE/HOLD, que é corretamente implementada como barras diárias gated por um rebalance de 7 dias ancorado ao calendário (day % rebalance_days == 0). Usar barras semanais literais iria tornar mais grosseiro o percentil e a cadência de euforia; a construção de barra diária + rebalance de 7 dias é a forma correta de exprimir uma rotação semanal. Assinalado para transparência; não conduz o veredito. (linha 380) — correção: Opcionalmente, reformular o texto da hipótese para dizer 'weekly rebalance on daily bars' para silenciar o aviso de consistência da Camada-1.5.

Verificação falhou (Camada 4 — revisão QA) [classe=hypothesis_mismatch]: - [edge_concern] O sandbox é uma basket long-only de majors coerente que corre e negoceia (337 negócios, avg_trade_return_pct 0.69% ultrapassa o limiar de comissões), mas total_return -20.85%, information_ratio -0.901 face ao benchmark de basket equally-weighted, e max_drawdown 71% (CI a 96%) sugerem que a chave de ranking de taker flow substituída adiciona valor negativo ajustado ao risco face a uma detenção equally-weighted ingénua. Isto é apenas consultivo; é consequência do desfasamento da chave de ranking e deve ser reavaliado pelo analista numa implementação corrigida, não bloqueado aqui. - [crítico] A única característica definidora da hipótese -- reafirmada ao longo do título/descrição ('por GLOBAL Long/Short Account-Ratio', 'count_long_short_ratio', 'uma Pure Under-Ownership FACTOR, Not Momentum') -- é que a CROSS-SECTIONAL RANKING KEY é o rácio global long/short ACCOUNT por nome, um proxy de posicionamento/propriedade de retail que é deliberadamente ortogonal ao momentum e ao funding. O código NOT classifica com base nisso. _crowd_z() / _rebalance() classificam os 8 majors por `taker_long_short_vol_ratio` (volume BUY agressivo / volume agressivo SELL) lido de `taker_flow_by_instrument`. O rácio de volume taker long/short é uma medida de FLOW/AGGRESSOR, não uma medida de propriedade/posicionamento -- é materialmente diferente do account ratio e é arguivelmente mais próximo do flow/momentum de horizonte curto ao qual a hipótese explicitamente alega ser ortogonal. O account ratio nomeado é usado apenas para o gate de caixa de euforia BTC secundário (_parse_global / calculate_signal), nunca para a seleção primária. Segundo a checklist QA, quando o edge central específico nomeado da hipótese está ausente do código, isso é crítico: o fator de sub-propriedade declarado não é o fator que está a ser negociado. (linha 259) — correção: Ou (a) integrar o rácio de conta global por instrumento no pipeline como `global_ratio_by_instrument` (espelhando funding_rates_by_instrument / open_interest_by_instrument / taker_flow_by_instrument em subprocess_entry.py) e classificar com base nisso -- esta é a implementação fiel que a hipótese nomeia; ou (b) se essa série por leg genuinamente não puder ser fornecida, a execução é um bloco DATA-coverage (not_measurable) em vez de uma estratégia para enviar numa chave substituída -- reportar como tal para que a hipótese fique parqueada até a série ser integrada, em vez de negociar silenciosamente um fator (flow) diferente. Fazer - [aviso] A verificação de consistência assinala a hipótese 'WEEKLY' vs config bar_type 1-DAY. Isto NOT um desfasamento genuíno: 'weekly' na hipótese refere-se à cadência REBALANCE/HOLD, que é corretamente implementada como barras diárias gated por um rebalance de 7 dias ancorado ao calendário (day % rebalance_days == 0). Usar barras semanais literais iria tornar mais grosseiro o percentil e a cadência de euforia; a construção de barra diária + rebalance de 7 dias é a forma correta de exprimir uma rotação semanal. Assinalado para transparência; não conduz o veredito. (linha 380) — correção: Opcionalmente, reformular o texto da hipótese para dizer 'weekly rebalance on daily bars' para silenciar o aviso de consistência da Camada-1.5.

Verificação falhou (Layer 2 — cenários sintéticos): Parâmetros usados: ['top_k', 'exit_level', 'min_notional', 'per_name_frac', 'euphoria_level', 'rebalance_days', 'euphoria_window'] Confirma que __init__ define todos os atributos a partir de self.parameters.get(). - steady_uptrend: TypeError: RetailCrowdingContrarianRotationLong._asof() aceita 3 argumentos posicionais, mas foram passados 4 (carimbo temporal da barra: 1735691940000) - steady_downtrend: TypeError: RetailCrowdingContrarianRotationLong._asof() aceita 3 argumentos posicionais, mas foram passados 4 (carimbo temporal da barra: 1735691940000) - flat_ranging: TypeError: RetailCrowdingContrarianRotationLong._asof() aceita 3 argumentos posicionais, mas foram passados 4 (carimbo temporal da barra: 1735691940000) - volatility_spike: TypeError: RetailCrowdingContrarianRotationLong._asof() aceita 3 argumentos posicionais, mas foram passados 4 (carimbo temporal da barra: 1735691940000) - zero_volume: TypeError: RetailCrowdingContrarianRotationLong._asof() aceita 3 argumentos posicionais, mas foram passados 4 (carimbo temporal da barra: 1735691940000) - price_gap: TypeError: RetailCrowdingContrarianRotationLong._asof() aceita 3 argumentos posicionais, mas foram passados 4 (carimbo temporal da barra: 1735691940000)

Verificação falhou (Camada 4 — revisão QA) [classe=hypothesis_mismatch]: - [edge_concern] O sandbox é um teste de fumo e não um motivo de falha, mas note-se: metrics_reliable=false, Sharpe (0.10) incoerente em sinal com total_return (-34.3%), MDD 70%, e a carteira OI-crowding perde mais no tercil de vol stressada (-37.8%). Se o mecanismo sobreviver até à revisão de backtest, verificar primeiro se o z-rank OI tem algum edge direcional, dado que OI é cego à direção. - O edge central da hipótese é um rank cross-sectional sobre GLOBAL LONG/SHORT ACCOUNT RATIO por nome — um fator direcional de sub-propriedade retail ('manter os nomes em que o retail está LEAST crowded-LONG'). O código, em vez disso, classifica pelo z-score de PERP OPEN INTEREST por nome e detém os 3 mais baixos. Trata-se de um mecanismo substituído que não preserva a economia: OI não é um proxy de retail (é o notional aberto total entre todos os participantes), e OI é DIRECTION-BLIND (agregado de longs == shorts em perps), pelo que não pode exprimir 'menos crowded-long.' O edge específico nomeado pela hipótese está ausente no código → crítico.

Verificação falhou (Layer 4 — revisão QA) [class=hypothesis_mismatch]: - [edge_concern] A sandbox parece saudável (+93%, Sharpe 0.77, PF 1.55, avg_trade_return_pct 6.63%) precisamente porque o código é uma rotação funding-carry que o programador confirma sobrepor-se à basket de carry de funding negativo já implementada — pelo que os bons números argumentam contra promover uma quase duplicação de uma estratégia live, não o fator de crowding ortogonal que a hipótese pretendia acrescentar. Consultivo; o bloqueio é de fidelidade. - Vantagem central não implementada e o substituto é o mecanismo exato que a hipótese EXCLUDES. A hipótese classifica por rácio GLOBAL long/short ACCOUNT por nome (crowding de retalho), explicitamente 'não funding (carry)... ortogonal ao momentum e ao funding'. O código classifica a cross-section por FUNDING por nome (mais baixo = mantido) — uma classificação funding-carry que o programador admite sobrepor-se à basket de carry implementada. A chave de crowding do rácio de contas está ausente e é inexequível (métricas cabladas apenas para o símbolo primário; sem metrics_by_instrument). - Cadência de rebalance ancorada a um contador de bars relativo ao processo (self._bar_i % rebalance_days), não ao timestamp do bar. Reinícios fazem reset a _bar_i e desviam a grelha de rotação semanal de qualquer dia fixo do calendário; parity replay não consegue reproduzir as datas de rotação. Item mais ligeiro-20 (sem disparo de sentinel/first-bar). Derivar de dias-desde-epoch ou de um dia da semana fixo.

verification_loop: Verificação falhou (Layer 4 — revisão QA) [class=hypothesis_mismatch]: - [edge_concern] A sandbox é uma basket coerente de majors long-only que corre e negoceia (337 trades, avg_trade_return_pct 0.69% ultrapassa o limiar de comissões), mas total_return -20.85%, information_ratio -0.901 vs o benchmark de basket de igual peso, e max_drawdown 71% (CI a 96%) sugerem que a chave de classificação taker-flow substituída acrescenta valor negativo ajustado ao risco face a uma detenção naive de igual peso. Isto é apenas consultivo; é consequência do desfasamento da chave de classificação e deve ser reavaliado pelo analista numa implementação corrigida, não bloqueado aqui. - [critical] A única característica definidora da hipótese -- reafirmada ao longo do título/descrição ('por GLOBAL Long/Short Account-Ratio', 'count_long_short_ratio', 'um Fator Puro de Sub-Propriedade FACTOR, Não Momentum') -- é que o CROSS-SECTIONAL RANKING KEY é o rácio long/short global ACCOUNT por nome, uma proxy de posicionamento/propriedade de retalho que é deliberadamente ortogonal ao momentum e ao funding. O código não NOT classifica com base nisso. _crowd_z() / _rebalance() ordenam os 8 majors por `taker_long_short_vol_ratio` (volume agressivo de BUY / volume agressivo de SELL) lido de `taker_flow_by_instrument`. O rácio de volume long/short de taker é uma medida FLOW/AGGRESSOR, não uma medida de propriedade/posicionamento -- é materialmente diferente do rácio de contas e é possivelmente mais próximo do fluxo/momentum de curto horizonte ao qual a hipótese afirma explicitamente ser ortogonal. O rácio de contas nomeado é usado apenas para o gate de cash de euforia BTC secundário (_parse_global / calculate_signal), nunca para a seleção primária. Segundo a checklist QA, quando a vantagem central nomeada específica da hipótese está ausente do código, isso é critical: o fator de sub-propriedade declarado não é o fator que está a ser negociado. (linha 259) — fix: Ou (a) cablar o rácio de contas global por instrumento no pipeline como `global_ratio_by_instrument` (espelhando funding_rates_by_instrument / open_interest_by_instrument / taker_flow_by_instrument em subprocess_entry.py) e classificar com base nisso -- esta é a implementação fiel que a hipótese nomeia; ou (b) se essa série por perna genuinamente não puder ser fornecida, a execução é um bloco de cobertura DATA (not_measurable) em vez de uma estratégia para lançar com uma chave substituída -- reportar como tal para que a hipótese fique em pausa até a série ser cablada, em vez de negociar silenciosamente um fator diferente (de fluxo). Do - [warning] A verificação de consistência sinaliza a hipótese 'WEEKLY' vs config bar_type 1-DAY. Isto NOT é um desfasamento genuíno: 'weekly' na hipótese refere-se à cadência REBALANCE/HOLD, que está corretamente implementada como daily bars gated por um rebalance de 7 dias ancorado ao calendário (day % rebalance_days == 0). Usar weekly bars literais iria tornar o percentil e a cadência de euforia mais grosseiros; a construção daily-bar + rebalance de 7 dias é a forma correta de expressar uma rotação semanal. Registado para transparência; não conduz o veredicto. (linha 380) — fix: Opcionalmente reformular o texto da hipótese para dizer 'rebalance semanal sobre daily bars' para silenciar o warning de consistência da Layer-1.5.