SolBtcRatioMeanReversionPairsHyperliquid

SOL/BTC Ratio Mean Reversion Pairs Trade on HYPERLIQUID Perps (Second-Pair Validation, Long-Short Market-Neutral, Daily, OHLCV-Only)

Second-pair validation of the pairs-ratio mean-reversion mechanism class on HYPERLIQUID — deliberately mirroring the EthBtcRatioMeanReversionPairsHyperliquid hypothesis (currently in pipeline) on a different asset pair to test mechanism-class generalization. The analyst's most recent refined heuristic explicitly states: 'True validation requires... (b) replicating positive expectancy on a SECOND instrument with the same implementation.' If ETH/BTC HL ratio MR produces positive Sharpe, validating on SOL/BTC HL (different participant mix, different volatility regime) establishes pairs-ratio mean reversion as a mechanism CLASS rather than instrument-specific edge — solving the exact failure mode that killed Bull Flag, Pullback-in-Trend, and cross-asset Donchian. SOL/BTC is the natural second pair because (a) both SOL and BTC are top-3 HL perps by liquidity, (b) SOL is a more volatile, more retail-driven L1 vs BTC's institutional macro-asset role — gives a structurally different residual driver than ETH/BTC's smart-contract-platform parity, (c) SOL/BTC ratio has well-documented mean-reverting tendencies over 30-90 day windows in academic crypto literature. This hypothesis SIMULTANEOUSLY FILLS three under-represented portfolio buckets: (a) HYPERLIQUID venue (4.4% → ≥20% target), (b) pairs scope (13.8% → reducing 79.4% single), (c) market-neutral direction (8.7% → reducing 91.3% long-only). CRITICAL: this is OHLCV-ONLY — NO funding rates, NO supplementary data — which avoids the entire class of Layer-3 supp-gap failures killing every funding-rate hypothesis (ETH cross-exchange just died on 'supp:fundingRate/ETHUSD: not in data_gaps').

Implements the hypothesis as a faithful second-pair validation of the pairs-ratio MR mechanism class, reusing the proven SyncedBuffer-based pairs scaffold so the implementation matches the ETH/BTC version exactly (only the asset pair changes) -- which is the precise condition the analyst's heuristic requires to test mechanism-class generalization. calculate_signal returns the discrete pair decision (+1/-1 at the z thresholds, a damped fractional value inside the band) and stashes the raw z and last prices on self for the exit logic; should_enter maps +1 to BUY-SOL/SHORT-BTC and -1 to the inverse, and should_exit reverts on z, an emergency ratio move, or time. Venue is HYPERLIQUID for both legs because the strategy is genuinely long-short (BTC leg is shorted) -- a futures/perp venue is mandatory for the short leg, and HL is specified by the hypothesis with both SOL and BTC among its most liquid perps. leverage stays at 1.0: dollar-neutral 0.5x-per-leg sizing keeps gross exposure at ~1x equity with ~0 net, so no margin amplification is needed and the leverage_set_but_unused gate is avoided (the _leg_notional helper still reads config.leverage, so raising it later would correctly scale both legs). It is strictly OHLCV-only -- no funding or supplementary-data references anywhere -- so Layer-2's synthetic supp generator fabricates nothing and the Layer-3 supp-gap failure class cannot trigger. All ratio/zscore math is zero- and NaN-guarded, and timestamp alignment is enforced at two independent layers to prevent the stale-leg phantom-spread bug. Fills three under-represented portfolio buckets: HYPERLIQUID venue, pairs scope, and market-neutral direction.

Negative edge with structural fat-tail risk (Sharpe -0.79, PF 0.86, omega 0.73, skew -2.44, kurtosis 20.4, max_dd 44%). The SOL/BTC log-ratio did not mean-revert over the test window — the strategy repeatedly faded a trending residual and got run over (2023 -40%; short leg win rate 40.6%). This is a premise mismatch (pair is not cointegrated/mean-reverting), not a parameter or code problem, so optimization of z_entry/z_exit/lookback cannot create an edge. The pairs-ratio MR mechanism class did NOT generalize to SOL/BTC, which is itself the answer to this second-pair validation.

Market-neutral SOL/BTC ratio mean-reversion pairs trade on Hyperliquid perpetuals, daily bars, OHLCV-only. Computes the z-score of log(SOL/BTC) over a rolling 45-day window from timestamp-aligned closes. When the ratio is statistically cheap (z <= -2) it goes LONG SOL / SHORT BTC; when rich (z >= +2) it goes SHORT SOL / LONG BTC, sized dollar-neutral at 0.5x equity per leg (gross ~1x, net ~0). Exits when z reverts inside +/-0.5, on a 12% adverse ratio move (emergency stop), or after a 30-day time stop. SOL is the primary leg; the BTC hedge leg is driven via _submit_entry/_submit_exit overrides. Alignment is double-guarded by the base class's same-timeframe barrier and SyncedBuffer's both-legs-present commit rule.

Implementation is correct: 64 trades (32 long / 32 short), both legs fire, timestamp alignment works, 0 dropped entries

Adequate trade sample (64) over ~3 years — the negative result is statistically meaningful, not noise

OHLCV-only design successfully avoided the Layer-3 supp-gap failure class

Clearly negative edge: Sharpe -0.79, profit_factor 0.86, omega 0.73, total return -21%, negative expectancy

Structural fat-tail risk: return_skew -2.44, kurtosis 20.4, tail_ratio 0.80, largest_loss -$16k > largest_win +$12.3k, max_drawdown 44%

Loss signature is that of mean-reverting a trending ratio — SOL/BTC was not reliably mean-reverting over the window (2023: -40%); short leg wins only 40.6% of the time

Premise mismatch, not a tuning gap: no z-threshold/lookback region converts a trending ratio into a reverting one, so optimization cannot recover an edge

This strategy set out to test whether pairs-ratio mean reversion is a reusable mechanism class by replicating the ETH/BTC HYPERLIQUID design on the structurally different SOL/BTC pair, market-neutral and OHLCV-only to sidestep the Layer-3 supplementary-data failures. The implementation was clean — 64 trades fired across both legs with zero dropped entries over ~3 years — but the result was a meaningful, not noisy, loss: Sharpe -0.79, -21% total return, 44% drawdown, and a fat negative tail from repeatedly fading a trending ratio. The analyst abandoned it at the pre-optimization review, concluding the SOL/BTC ratio simply was not mean-reverting over the test window, so optimization could not manufacture an edge. Later stages (optimization, post-optimization analysis, risk review) were never reached, and the negative outcome is itself the answer to the second-pair validation: the mechanism class did not generalize to SOL/BTC.

A mean-reversion mechanism that works on one pair does not generalize to another absent evidence the new pair is actually cointegrated/mean-reverting — verify the reverting premise before committing to second-pair validation.

It was abandoned at the BACKTEST_REVIEW gate before optimization: the analyst judged this a premise mismatch rather than a tuning gap, since the SOL/BTC log-ratio did not mean-revert over the window (2023 ~-40%, short-leg win rate 40.6%), so no z-threshold or lookback could convert a trending residual into a reverting one.

A market-neutral, long-short daily pairs trade that faded z-score extremes in the log(SOL/BTC) ratio on HYPERLIQUID perps, intended as a second-pair validation of the pairs-ratio mean-reversion mechanism class (mirroring the ETH/BTC HL implementation) using OHLCV data only.

Over 235 days of data and 64 trades (32 long / 32 short), it produced a clearly negative edge: Sharpe -0.79, total return -21%, profit factor 0.86, omega 0.73, and negative expectancy (-$328/trade) despite a 51.6% win rate. Risk was structurally poor: max drawdown 44%, return skew -2.44, kurtosis 20.4, and a largest loss (-$16k) exceeding the largest win (+$12.3k).