Chuyển đến nội dung
Tất cả tài liệu trong thư viện

Thiết kế nghiên cứu chiến lược funding hợp đồng tương lai vĩnh cửu crypto

Bài viết Machine Learning for Trading

Tóm tắt

Nghiên cứu tình huống này phác thảo quy trình nghiên cứu hợp đồng tương lai vĩnh cửu crypto, xem các khoản thanh toán funding trao đổi giữa vị thế mua và bán tại các kỳ thanh toán định kỳ là một nguồn lợi suất tiềm năng. Tài liệu mô tả các giai đoạn dữ liệu và mô hình, từ xây dựng nhãn và đặc trưng tài chính đến mô hình thống kê và học máy, phân tích nhân quả, kiểm thử lịch sử, phân bổ danh mục, rủi ro và đánh giá chi phí. Thiết lập dùng một lát cắt ngang các cặp hợp đồng vĩnh cửu, quan sát mỗi tám giờ và các giả định về chi phí giao dịch; việc xác thực dựa trên số lượng fold thời gian hạn chế.

Tài liệu nhấn mạnh thời điểm sau khi nến hoàn tất, dòng tiền funding chính thức và việc tách bằng chứng từ mô hình khỏi các phép chẩn đoán chạy lại trên một tập dữ liệu nền đã cố định. Tài liệu cho biết sổ đăng ký hiện tại không có backtest hoặc nhóm ứng viên, vì vậy quy trình phát hành hoàn chỉnh chưa phải là một chiến lược đầu cuối mà độc giả có thể tái lập. Có thể chạy các sổ tay ở bước sau cho những mục đích chẩn đoán đã nêu, nhưng không nên kết hợp đầu ra của chúng thành một chiến lược hiện hành cho đến khi giải quyết xong sổ đăng ký và lịch sử công bố. Vì vậy, phác thảo quy trình hữu ích như một thiết kế nghiên cứu, chứ không phải bằng chứng về hiệu suất sinh lời.

Ý chính

  • Các khoản chuyển funding trong hợp đồng tương lai vĩnh cửu được khảo sát như một nguồn lợi suất khả dĩ bên cạnh tín hiệu dựa trên giá.
  • Quy trình xây dựng nhãn và đặc trưng trước khi kiểm thử các mô hình tuyến tính, tăng cường và học sâu.
  • Thời điểm sau khi nến hoàn tất, dòng funding chính thức và chi phí giao dịch là trọng tâm của thiết kế nghiên cứu.
  • Việc xác thực chỉ dùng hai fold, làm hạn chế sức nặng của các kết luận.
  • Các phép chẩn đoán trên tập dữ liệu nền đã cố định không cấu thành chiến lược đầu cuối hiện hành khi chưa có backtest và nhóm ứng viên trong sổ đăng ký.

Thẻ

Toàn văn
# Crypto Perpetuals Funding


# Crypto Perpetuals Funding

This case study uses Binance perpetual futures to examine an asset-class-specific return source:
the transfer between long and short positions at each 8-hour funding settlement. Nineteen
perpetuals create the book's smallest cross-section and highest non-intraday decision frequency.
The pipeline therefore emphasizes completed-bar timing, official funding cash flows, transaction
costs, and uncertainty from only two validation folds.

## Dataset Profile

| Property | Value |
|---|---|
| Asset class | Crypto perpetual futures |
| Frequency | 8-hourly, aligned to funding settlements |
| Universe | 19 perpetual pairs |
| History | 2020-2025 |
| Primary label | `fwd_ret_8h` |
| Validation design | 2 folds, 2-year train and 1-year validation |
| Cost model | 2 bps maker and 4 bps taker |

## Pipeline

| Stage | Notebook | Chapter | Description | Writes |
|---|---|---|---|---|
| Feasibility | [`01_feasibility_analysis`](01_feasibility_analysis.ipynb) | Ch6 | Checks universe breadth at the funding timestamp, move scale against the fee, premium persistence, and the walk-forward folds. | Nothing; the contract list is fixed in `setup.yaml` |
| Labels | [`02_labels`](02_labels.ipynb) | Ch7 | Builds forward returns and class labels without admitting holdout-ending observations; folds are derived from `setup.yaml` and the label timeline, not written here | One parquet per label in `labels/` (`fwd_ret_8h` plus the `fwd_ret_24h`, `fwd_dir_8h`, `fwd_dir_8h_3c` variants), each with a `.digest.json` sidecar |
| Financial features | [`03_financial_features`](03_financial_features.ipynb) | Ch8 | Produces 39 premium, funding, momentum, volatility, and liquidity features. | `features/financial.parquet` |
| Model-based features | [`04_model_based_features`](04_model_based_features.ipynb) | Ch9 | Adds five fold-specific volatility and regime features fit on prior data. | `features/model_based.parquet` |
| Evaluation | [`05_evaluation`](05_evaluation.ipynb) | Ch7-9 | Evaluates the exact 44-feature training frame on the canonical label clock. | `evaluation/triage_ledger.parquet`, `evaluation/ic_timeseries.parquet` |
| Linear models | [`06_linear`](06_linear.ipynb) | Ch11 | Fits complete Ridge, Lasso, and ElasticNet validation surfaces. | Training runs and prediction sets in `run_log/registry.db`; coefficients under `run_log/training/{hash}/`, scores under `run_log/predictions/{hash}/` |
| Gradient boosting | [`07_gbm`](07_gbm.ipynb) | Ch12 | Trains the CUDA LightGBM grid and preserves physical boosters and predictions. | Training runs and prediction sets; boosters, `learning_curves.parquet`, and `fold_metrics.parquet` under `run_log/training/{hash}/` |
| Tabular deep learning | [`08_tabular_dl`](08_tabular_dl.ipynb) | Ch12 | Trains TabM checkpoints on the same fingerprinted frame. | Training runs and prediction sets; checkpoints under `run_log/training/tabular_dl/` |
| LSTM | [`09_dl_lstm`](09_dl_lstm.ipynb) | Ch13 | Evaluates causal 60-bar recurrent sequences on CUDA. | Training runs and prediction sets; checkpoints under `run_log/training/deep_learning/` |
| TCN | [`10_dl_tcn`](10_dl_tcn.ipynb) | Ch13 | Evaluates dilated causal convolutions on the same sequence contract. | Training runs and prediction sets; checkpoints under `run_log/training/deep_learning/` |
| Causal DML | [`11_causal_dml`](11_causal_dml.ipynb) | Ch15 | Tests whether the basis premium has a causal interpretation after adjustment. | A row in the registry's `causal_runs` |
| Model analysis | [`12_model_analysis`](12_model_analysis.ipynb) | Ch12-15 | Compares four current family leaders on one physical validation panel. | Nothing - it reads the registry |
| Backtest | [`13_backtest`](13_backtest.ipynb) | Ch16 | Replays a frozen carrier with completed-bar prices and official funding. | Nothing - it replays a frozen carrier with `register=False` |
| Portfolio | [`14_portfolio_management`](14_portfolio_management.ipynb) | Ch17 | Compares corrected point-in-time allocation methods on that carrier. | Nothing - it replays a frozen carrier with `register=False` |
| Risk | [`15_risk_management`](15_risk_management.ipynb) | Ch19 | Evaluates fixed and pre-validation-calibrated position-risk rules. | Nothing - it replays a frozen carrier with `register=False` |
| Costs | [`16_costs`](16_costs.ipynb) | Ch18 | Measures cost sensitivity and price-only versus funding-inclusive breakevens, on the configuration risk management selected. | Nothing - it replays a frozen carrier with `register=False` |
| Synthesis | [`19_strategy_analysis`](19_strategy_analysis.ipynb) | Ch20 | Keeps current model evidence separate from frozen carrier diagnostics. | Nothing - it reads the registry |

## Running

Run notebooks from the repository root. Notebooks 07-10 require CUDA; the other notebooks use CPU.
The complete release pipeline is not yet supported because the current model registry has no
backtests or cohorts, while notebooks 13-16 preserve a frozen carrier for diagnostic replay. The
publication lineage must be chosen before the downstream producer sequence can be documented as a
reader-reproducible run.

The signed current-model sequence is:

```bash
uv run python case_studies/crypto_perps_funding/01_feasibility_analysis.py
uv run python case_studies/crypto_perps_funding/02_labels.py
uv run python case_studies/crypto_perps_funding/03_financial_features.py
uv run python case_studies/crypto_perps_funding/04_model_based_features.py
uv run python case_studies/crypto_perps_funding/05_evaluation.py
uv run python case_studies/crypto_perps_funding/06_linear.py
uv run python case_studies/crypto_perps_funding/07_gbm.py
uv run python case_studies/crypto_perps_funding/08_tabular_dl.py
uv run python case_studies/crypto_perps_funding/09_dl_lstm.py
uv run python case_studies/crypto_perps_funding/10_dl_tcn.py
uv run python case_studies/crypto_perps_funding/11_causal_dml.py
uv run python case_studies/crypto_perps_funding/12_model_analysis.py
```

Notebooks 13-17 are signed for their declared frozen-versus-current boundaries. They are not a
current end-to-end strategy and should not be combined into one until the release registry is fixed.

Hiển thị toàn văn kèm ghi nguồn theo giấy phép của tài liệu gốc. Giấy phép: MIT

Bản tóm tắt này do tác nhân nghiên cứu của Stratmill biên soạn từ tài liệu gốc; đây không phải bản sao của tài liệu.