BtcDominantStaticAllocationLongSpot1D

BTC-Dominant Static Allocation (60/30/10 BTC/ETH/SOL Long-Only Spot) with Quarterly Rebalancing on Drift — Analyst-Recommended Honest Expression of Crypto Winner-Take-All

Long-only multi-instrument STATIC ALLOCATION portfolio on BINANCE_SPOT: 60% BTCUSDT + 30% ETHUSDT + 10% SOLUSDT, anchored at these target weights, rebalanced quarterly (every 90 days) OR when any asset's weight drifts beyond ±15% of its target (whichever fires first). This is the EXPLICIT analyst-sanctioned alternative to the abandoned cross-sectional momentum rotation: per the recommendation issued after that abandon, 'IF the long-term winner-take-all thesis is to be tested, consider a STATIC WEIGHTING strategy that overweights BTC at portfolio level and NEVER rotates — captures the structural winner-take-all without paying the whipsaw cost. This is essentially BTC-tilted buy-and-hold which may be a more honest expression of the thesis.' Why this is META-DISTINCT from every recently-failed mechanism class: it makes NO predictions, performs NO timing, requires NO regime detection, runs NO rotation logic. The strategy expresses the ONE piece of crypto market structure the analyst has repeatedly confirmed as empirically TRUE — 'BTC outperformed alts cumulatively since 2022, structurally true on MULTI-YEAR horizons' — in the cleanest implementable form. Diversification across 3 majors smooths the equity curve relative to 100% BTC HODL (reducing max DD from ~80% to expected ~50-60%); the BTC anchor at 60% preserves exposure to the structural winner; the 30/10 minority weights capture occasional alt-leadership episodes (2021 Q1, 2024 Q1) without overcommitting. Quarterly cadence keeps turnover minimal (4 scheduled + ~2-4 drift-triggered events/year × 3 assets × 2 trades = ~36-50 trades/year). Over 7+ years of BINANCE_SPOT data: 250-350 total trades, giving 17-23 OOS trades per walk-forward window — comfortably above the analyst's 5-trade floor. ONLY 3 parameters (well below 5-param overfit ceiling): two target weights (third is derived) + rebalance_period_days + drift_threshold. Target weights themselves are HARD PRIORS (60/30/10) explicitly NOT optimizable — they're chosen from the analyst's recommendation language, not from backtest fitting, which is the entire point of preventing the optimizer from curve-fitting weights to historical regime artifacts.

The backtest reached Layer 3 but was uninterpretable (metrics_reliable=false, 1 daily return, avg_position_pct 317%, Sharpe 0); signal/rebalance logic already passed earlier layers, so the change is confined to the venue, which is the single root cause of BOTH reported defects. On the prior BINANCE_SPOT CASH account, buying BTC/ETH/SOL converts USDT into separate coin-currency balances that this engine does not mark into equity, so get_account_equity() returned only the ~5% residual USDT after deployment. That one defect explains both failures: (1) the equity curve never marked the coin holdings, so the run yielded a single daily return with all PnL realized on the forced final-day close; and (2) leg notionals measured against the collapsed equity denominator appeared as ~317% (the under-count, not real leverage). A strategy cannot fix engine-side spot-balance marking from its own code. Routing the identical portfolio to BINANCE USD-M futures at leverage 1.0 (long-only) resolves both: futures positions carry continuous unrealized PnL that the equity tracker samples every bar (a real daily-return series for Sharpe/DD/DSR), and the USDT balance read by get_account_equity() stays ~100k so establishment deploys exactly deploy_fraction x equity (gross <= ~95%, avg_position_pct ~95%) and rebalances anchor to the marked portfolio value. This matches how the multi-asset always-in-market portfolios that passed this session (Donchian basket, TSMOM) are built. Long-only is preserved because every sell is capped at current holdings (never net short), satisfying the no-short requirement on the futures venue. All rebalance/sizing/diagnostic code is byte-identical to the previous iteration (it is venue-agnostic), so every earlier-layer check stays green; only the config instrument IDs, bar types, and leverage changed. Note on the analyst's benchmark gate (#3): this is admittedly BTC-tilted beta, and the corrected, mark-to-market result must beat a passive 60/30/10 hold on max-DD-adjusted return net of fees to be worth optimizing — the rebalancing premium is the only possible edge over buy-and-hold, and if it merely tracks the passive benchmark it should be abandoned as market beta.

Do not optimize, and do not iterate a third time. (1) BROKEN BACKTEST, AGAIN: the iteration-2 fix (re-routing BINANCE_SPOT -> USD-M futures to make legs mark-to-market) did NOT resolve the defect it targeted — the result still shows a single daily return over ~6 years (2026-06-25: -142.26%, all PnL dumped on the final bar), avg_position_pct 958% (~10x equity), end_unrealized_pct 846%, return_kurtosis 1075, annualized_volatility 312%, max_drawdown CI 100%, and metrics_reliable=FALSE. The multi-instrument long basket is still not being marked to market per bar and leg sizing still runs to ~10x equity, so the backtest is uninterpretable and cannot be optimized or walk-forward validated. The developer has now spent two targeted iterations on this exact equity-accounting/sizing symptom without resolving it, indicating a persistent engine-interaction problem rather than a quick fix. (2) NO OPTIMIZABLE EDGE EVEN IF FIXED: the hypothesis itself describes this as 'essentially BTC-tilted buy-and-hold' — a pure beta product (beta 0.66, benchmark_correlation 0.85, alpha 0.027) that makes no predictions and performs no timing. Its target weights are explicitly declared NON-optimizable hard priors, leaving only rebalance_period_days and drift_threshold as tunables, neither of which can manufacture alpha on a static long-only basket. Optimization exists to find a robust parameter edge; here there is none to find. A static BTC-tilted HODL allocation belongs in a benchmark/allocation sleeve, not the strategy-optimization pipeline. Abandon: the result is uninterpretable due to a twice-unfixed accounting defect, and the underlying construct has no optimizable edge regardless.

Long-only 60/30/10 BTC/ETH/SOL static-allocation buy-and-hold portfolio on BINANCE USD-M futures (leverage 1.0, long-only), daily bars. Establishes the three legs once at target weights (deploying 95% of equity) and rebalances back to 60/30/10 whenever 90 days elapse OR any leg's weight drifts beyond +/-15% of its target. Iteration 2 moves the portfolio off the BINANCE_SPOT CASH account — whose unmarked coin balances made equity collapse to residual USDT, producing the 317% apparent over-deployment and a flat one-point equity curve — onto a futures MARGIN account where each leg is a real position marked to market every bar (true daily-return series) and equity stays stable (~100k) so gross stays bounded at ~95%. Sells precede buys and are capped at holdings, so the book never shorts. Three tunable parameters (rebalance_period_days, drift_threshold, and the BTC/ETH weights which are hard priors); SOL weight derived.

Conceptually simple, no prediction/timing; honest expression of the BTC winner-take-all thesis

Low turnover design with sensible 3-asset diversification

Backtest is broken AGAIN after the iteration-2 venue fix: a single daily return (2026-06-25 -142%), avg_position_pct 958% (~10x equity), end_unrealized_pct 846%, annualized_vol 312%, metrics_reliable=FALSE — the equity-marking/sizing defect the venue change was meant to fix persists identically

Uninterpretable metrics: CAGR -100%, max_drawdown CI 100%, only 3 'trades' counted, avg_holding 2110 days — cannot be optimized or validated

Even when working, it is BTC-tilted buy-and-hold beta (beta 0.66, benchmark_correlation 0.85, alpha 0.027) with no timing edge

Weights are explicitly NON-optimizable hard priors, leaving only rebalance cadence/drift — which cannot create alpha on a static long-only basket, so optimization has nothing to find

Do NOT optimize — the backtest is uninterpretable (metrics_reliable=false, a single daily return over a 9-year run, 3 trades, Sharpe 0). This is the same defect pattern as the BTC-ETH rebalance strategy. Fixes required: 1. CAPTURE A DAILY RETURN SERIES FOR OPEN POSITIONS. The portfolio establishes BTC/ETH/SOL once and holds ~2106 days, but the equity curve / daily returns are not recorded (only 1 daily return point, all PnL dumped on the final day). Ensure the always-in-market portfolio marks to market every bar so the engine produces a real daily-return series — otherwise Sharpe/drawdown/DSR are meaningless and optimization is impossible. 2. FIX THE CASH OVER-DEPLOYMENT (avg_position_pct 317%). On a SPOT CASH account gross notional cannot exceed equity, yet positions average 3.17x. Audit the initial establishment and rebalance buy legs: sells must precede buys and only freed cash funds buys; total deployed must cap at deploy_fraction (0.95) x equity. Verify post-fix that avg_position_pct <= ~95% and no leg buys beyond available cash. 3. BENCHMARK VS PASSIVE 60/30/10 BUY-AND-HOLD (hard gate). This is admittedly BTC-tilted buy-and-hold; the rebalance cadence/drift params only tweak a second-order rebalancing premium and cannot create alpha. The corrected backtest MUST be compared against a passive 60/30/10 hold (no rebalancing): the strategy has to deliver measurably better risk-adjusted return (e.g. materially lower max DD at comparable return) net of fees. If it merely tracks buy-and-hold, abandon — it is market beta, not an edge. After fixing (1) and (2), re-run; only a reliable, beta-benchmarked result that beats passive holding is worth optimizing.

BtcDominantStaticAllocationLongSpot1D was the analyst-recommended 'honest' expression of the BTC winner-take-all thesis: a static 60/30/10 BTC/ETH/SOL long-only basket rebalanced on schedule or drift, with weights deliberately fixed as hard priors to prevent curve-fitting. But the backtest was uninterpretable — the iteration-2 re-routing to USD-M futures did not resolve the equity-marking/sizing defect, leaving a single daily return, ~958% position sizing, and metrics flagged unreliable. Beyond the broken accounting, the construct is by its own description BTC-tilted buy-and-hold beta with no timing edge and non-optimizable weights, so optimization had nothing to find. With the defect unfixed across two iterations and no optimizable alpha regardless, the analyst abandoned the strategy at the backtest-review gate, noting it belongs in a benchmark sleeve rather than the optimization pipeline.

A static, prediction-free BTC-tilted buy-and-hold allocation belongs in a benchmark or allocation sleeve, not the strategy-optimization pipeline — optimization exists to find a robust parameter edge, and a basket with non-optimizable weights and pure beta offers none, while a twice-unfixed engine accounting defect signals a persistent integration problem rather than a quick fix.

The analyst abandoned it at the backtest-review gate for two reasons: the equity-accounting/sizing defect persisted unfixed across two targeted iterations (the multi-instrument long basket still was not marked to market per bar and leg sizing ran to ~10x equity, making the result uninterpretable), and even if fixed it has no optimizable edge — it is BTC-tilted buy-and-hold beta (beta 0.66, benchmark correlation 0.85, alpha 0.027) with non-optimizable weights, leaving only rebalance cadence and drift, neither of which can manufacture alpha.

A long-only, 3-asset static allocation portfolio (60% BTC / 30% ETH / 10% SOL) — the analyst-sanctioned 'honest' expression of crypto winner-take-all that makes no predictions and runs no rotation, simply rebalancing back to fixed target weights quarterly or when any asset drifts beyond ±15% of its target, with the 60/30/10 weights declared non-optimizable hard priors.

There is no interpretable performance: after an iteration-2 venue change meant to fix equity marking, the backtest was still broken — a single daily return over ~6 years (all PnL dumped on the final bar at -142%), avg_position_pct 958% (~10x equity), end_unrealized_pct 846%, annualized volatility 312%, CAGR -100%, max-drawdown CI to 100%, only 3 trades counted, and metrics_reliable=FALSE.