Bitcoin Direction Model

The problem

The notebook compares models for a three-day Bitcoin direction target using market and on-chain features. The current evaluation needs correction before its performance can support a predictive claim.

How should market and on-chain features be evaluated without using future outcomes to select the prediction population?

Time-series labels, preprocessing, and sample selection can make retrospective results look stronger than they are. This archive keeps the methods visible and identifies the required validation changes.

How it works

1. 01

   Yahoo Finance + CoinMetrics

2. 02

   Engineered features

3. 03

   Three-day target / retrospective filter

4. 04

   Chronological model comparison

5. 05

   Validation review

From input to output

1. 01Merge Yahoo Finance daily BTC history with CoinMetrics Community API MVRV data.
2. 02Construct momentum, trend, volatility, oscillator, lag, and valuation features, then define a three-day forward-return target.
3. 03Remove near-flat forward returns using the documented ±1% filter and retain a chronological 80/20 split.
4. 04Compare linear, logistic, Lasso, random-forest, and XGBoost models; document where fold preprocessing and overlapping labels require correction.

Data sources

• Yahoo Finance daily BTC market history
• CoinMetrics Community API MVRV series

Technical approach

• Market and on-chain feature engineering
• Chronological holdout
• TimeSeriesSplit model comparison
• Retrospective uncertainty analysis requiring time-aware review

What you can inspect

• The notebook contains feature construction and model-comparison outputs.
• Performance figures are omitted until the dataset, preprocessing, label boundaries, and uncertainty method are reconciled.

The useful artifact is the documented modeling process and its validation review; a reliable predictive edge has not been established.

Where this is useful

• Preserve a frozen data snapshot and run identity before comparing reruns.
• Use train-fold preprocessing, label-aware purging, and appropriate baselines before interpreting accuracy.

Checks & engineering decisions

Verification evidence

• Future-target filtering, pre-fold scaler fitting, and overlapping labels prevent a reliable current prediction claim.
• A frozen dataset, fold-local preprocessing, date-aware label purging, stronger baselines, and time-aware uncertainty are required before publishing revised metrics.

Key decisions

• Preserve time order but verify label availability at every boundary.
• Treat future-return filtering as retrospective sample selection, not a deployable eligibility rule.
• Withhold unresolved performance figures instead of implying tradability.

tscv = TimeSeriesSplit(n_splits=5)

cv_mse = [
  np.mean([
    mean_squared_error(
      y_train[val],
      Lasso(alpha=l, max_iter=10000)
        .fit(X_lasso_train_scaled[tr], y_train[tr])
        .predict(X_lasso_train_scaled[val])
    )
    for tr, val in tscv.split(X_lasso_train_scaled)
  ])
  for l in lambdas
]

Role & status

Research archive · Evaluation under review Source review: 2026-10-14.

Limitations

• Filtering on the future target creates a retrospective population that is unavailable at prediction time.
• The current scaler fitting and overlapping forward labels require a fold-level leakage review.
• Row-wise bootstrap intervals do not establish uncertainty under temporal dependence.
• The charts are historical notebook outputs, not validated trading performance.

Explore the evidence

Archived notebook and research report. Historical charts are retained for context; their numeric outputs are not endorsed as current validated performance.