Desenho de pesquisa para estratégias com funding em futuros perpétuos de cripto
Artigo Machine Learning for Trading
Resumo
Este estudo de caso apresenta um fluxo de pesquisa para futuros perpétuos de cripto, tratando os pagamentos de funding trocados entre posições compradas e vendidas em liquidações regulares como uma possível fonte de retorno. Descreve etapas de dados e modelos, desde a construção de rótulos e indicadores financeiros até modelos estatísticos e de aprendizado de máquina, análise causal, backtesting, alocação de carteira, risco e avaliação de custos. A configuração usa um corte transversal de pares perpétuos, observações a cada oito horas e hipóteses de custos de transação, com validação baseada em um número limitado de divisões temporais.
O documento enfatiza o momento de conclusão das barras, os fluxos de caixa oficiais de funding e a separação entre evidências dos modelos e diagnósticos reproduzidos em um veículo congelado. Afirma que o registro atual não contém backtests nem coortes, portanto o fluxo completo de publicação ainda não é uma estratégia de ponta a ponta reproduzível pelo leitor. Notebooks posteriores podem ser executados para fins diagnósticos declarados, mas seus resultados não devem ser combinados em uma estratégia atual até que o registro e a linhagem de publicação sejam esclarecidos. Assim, o esboço do fluxo é útil como desenho de pesquisa, não como evidência de desempenho lucrativo.
Ideias principais
- As transferências de funding em futuros perpétuos são examinadas como possível fonte de retorno junto com sinais baseados em preços.
- O fluxo constrói rótulos e indicadores antes de testar modelos lineares, de boosting e de aprendizado profundo.
- O momento de conclusão das barras, os fluxos oficiais de funding e os custos de transação são centrais no desenho da pesquisa.
- A validação usa apenas duas divisões, o que limita a força das conclusões.
- Diagnósticos em um veículo congelado não constituem uma estratégia atual de ponta a ponta enquanto faltarem backtests e coortes no registro.
Tags
Texto completo
# 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.Exibido na íntegra, com atribuição conforme a licença da fonte. Licença: MIT
Este resumo foi escrito pelo agente de pesquisa da Stratmill com base no original; não é uma cópia da fonte.