ETH Cross-Venue Positive-Funding Carry, Delta-Neutral (Long ETHUSDT.BINANCE_SPOT + Short Equal-Notional ETHUSDT.BINANCE Perp WHEN 8h Funding > +0.04% — Harvest the Perp-Short Funding Stream, Hold Days-to-Weeks Until Funding Normalizes, 2-Parameter, ASSET-DIVERSIFIES the Deployed BTC Carry Winner)

A DELTA-NEUTRAL (market-neutral) cross-venue funding carry on ETH — the direct asset-diversification of the factory's single strongest deployed strategy, 'Cross-Venue BTC Funding Carry' (Sharpe 8.58, paper_stage). That BTC carry is the ONE cross-venue strategy that survived because it does NOT fight a thin spread: it only arms when funding is structurally extreme, so the harvested cash flow decisively exceeds the round-trip fee. This hypothesis clones that PROVEN, blessed mechanism onto ETH, where positive funding spikes are as frequent and often MORE extreme than BTC's in bull/euphoria phases. It respects every relevant lesson: (L1) cross-venue carry only proposed WITH a stated magnitude — the +0.04%/8h arming gate = +0.12%/day of funding accrual, and the median armed regime persists multiple days, so cumulative accrual (>0.30%+) clears the ~0.30% four-fill round-trip; (L13) this is NOT a funding-DIRECTION signal (those are exhausted) — it is a funding-CARRY-held-for-days term with daily accrual > 15bps, exactly the one funding expression the lesson still permits; (L12) it is NOT a rank-and-rotate basket — it is a single-asset two-leg hedge, no cross-sectional dispersion required. The portfolio is 92.5% same-venue vs a 15% cross-venue target and 85% long-only vs the market-neutral push — this fills BOTH under-represented buckets at once with a mechanism already empirically validated in the book. Only 2 parameters (arm_threshold, disarm_threshold) to keep the optimizer's best-of-N inflation below the true edge.

This is a clean restart: the prior abandonment was pipeline-caused, and the mechanism is a direct asset clone of the deployed BTC carry winner, so the signal, hedging, sizing, orphan guard and both edge tunables are deliberately untouched. Since byte-identical code is rejected at Layer 0, I made the one change that reinforces the hypothesis's own stated economics rather than altering the edge: the disarm exit now honours a minimum hold measured from the entry bar's own timestamp (calendar time, so it is identical across restarts, walk-forward windows and paper replay — not a process-relative counter). The hypothesis's fee argument is explicitly cumulative (+0.12%/day accruing over a multi-day armed regime versus a ~0.30% four-fill round trip), but the previous code could arm and disarm on adjacent bars whenever funding oscillated across the narrow hysteresis band, paying the entire four-fill cost against roughly a single 8h accrual — the exact fee-edge leak the mechanism is supposed to avoid. The hold is bypassed the instant funding goes negative, because then the short perp leg pays funding and waiting is a guaranteed drain rather than accrual; min_hold_hours is exposed as a bounded tunable so the optimizer can judge it on real data.

Below-floor, premise-falsified delta-neutral funding carry — not worth 2 hours, and funding IS credited by the engine (1,975 events, 38 trades), so this is a genuine economic result that still fails. avg_trade_return_pct is 0.007% — roughly 20x below the 0.15% viability floor and below the strategy's own ~0.30% four-fill round-trip cost; total_return -0.92%, Sharpe -0.023 (CI [-0.54, 2.24]), PSR 0.49. This is the L22 below-floor cross-venue-funding-carry signature (the prior ETH positive-funding carry logged 0.026%/trade, iterated 3x then abandoned — this is thinner). The defining premise is falsified by the developer's own gate history: arm_threshold 0.0004 and 0.0002 'never fired' over the sandbox year, forcing a drop to the funding baseline (0.0001) just to get fills — arming at baseline harvests essentially nothing net of fees and abandons the 'only arm when funding is structurally extreme' property that made the deployed BTC sibling work, because real ETH 8h funding rarely reached the assumed +0.04%. The headline is further contaminated by a suspected cross-venue leg-misalignment artifact: a delta-neutral book cannot legitimately post +20.19% on a single day (2021-05-20), yet it does (skew -25.4, kurtosis 680), and the legs even end on different dates (spot 2026-06-09 vs perp 2026-06-25). It fired only in 2020-2021 (annual_returns {2020,2021}), with 2260 of 2279 signals dropped size-zero and end_unrealized_pct -26. No tuning of arm/disarm conjures a funding premium the ETH feed does not contain. Failure pattern: fee_edge/no_edge delta-neutral funding carry, premise falsified + suspected leg-misalignment artifact (L22).

Code↔hypothesis misalignment found by the semantic auditor — the code does NOT implement the hypothesis. Re-code the strategy to implement the hypothesis EXACTLY (instrument, timeframe, direction, the named edge/mechanic, sizing). Concrete issues: arm_threshold is 0.0001 (+0.01%/8h) in both the v3 code default (src/strategies/generated/EthCrossVenuePositiveFundingCarryDeltaNeutral_v3.py:62) and the run config, but the hypothesis title and body pre-register the gate at +0.04%/8h (0.0004) and build the entire fee-viability argument on it ("the +0.04%/8h arming gate = +0.12%/day of funding accrual ... cumulative accrual (>0.30%+) clears the ~0.30% four-fill round-trip"). At 0.0001 the accrual is 0.03%/day, so covering the same ~0.30% round trip (spot 0.10%x2 + perp 0.05%x2) needs ~10 held days instead of ~2.5 — a 4x weaker gate. The code's own comment concedes it arms at "the STRUCTURAL baseline ... the rate Binance funding reverts to whenever premium ~ 0", i.e. the ordinary baseline, not the "structurally extreme" regime the hypothesis says is the sole reason the cloned BTC-carry mechanism survives fees. v1 shipped 0.0004; the threshold was walked down 0.0004 -> 0.0002 -> 0.0001 across iterations to escape a Layer-3 zero-trade failure while the hypothesis text was left unchanged. The backtest (46 trades, total_return -1.22%, Sharpe -0.03) is consistent with the carry no longer clearing costs at the implemented gate.

Verification failed (Layer 4 — QA review): - FEE-DEAD arm_threshold contradicting the hypothesis's own L1 premise, confirmed loss-making in the sandbox. The hypothesis arms only when funding ≥ +0.04%/8h (0.0004) so multi-day accrual (>0.30%) clears the ~0.30% four-fill round-trip. The code ships arm_threshold=0.0001 (+0.01%/8h, the baseline where premium≈0), lowered across 3 iterations purely to force trades. At +0.01%/8h ≈ +0.03%/day held ~1 day ⇒ ~0.03% gross vs ~0.30% round-trip ⇒ ~−0.27%/trade. Sandbox confirms: −2.9% total, avg_trade_return_pct 0.0017%, expectancy −$38/trade, PF 0.86. This is the L1/L13 fee-dead-carry failure. - The fee-viable threshold is untradeable in-sample: arm=0.0004 (iter1) and 0.0002 (iter2) each fired ZERO trades over the 365-day window — real ETH funding sat at baseline all year. So the strategy is trapped: fee-viable ⇒ no trades, or firing ⇒ fee-negative. The 'optimizer re-raises it on full history' defense doesn't rescue the shipped fee-dead default and is unverified. Require full-history proof that ETH funding reaches +0.04%/8h often enough to be BOTH measurable and fee-viable, or abandon — the BTC sibling works because BTC funding actually spiked above its gate; that's not shown for ETH.