Crypto futures automated trading system — master plan from backtesting to live trading

Crypto futures automated trading system — master plan from backtesting to live trading

Version: v1.0 (2026-07-07) Initial capital: about 1,000,000 KRW / target: Binance USDT-M futures (starting with BTC only) Objective function: not maximizing profit but completing "a low-deviation validation system + a track record" Labelling convention: [verified] = verified widely in academia and practice / [inference] = logical inference, to be confirmed by backtesting / [TBD] = to be confirmed at implementation

0. The premises this document stands on (3 assumptions corrected in conversation)

The design judgments of this project rest on the corrected premises below. When sharing with collaborators, agree on these premises first.

1. Small capital ≠ high expected return. The only advantage of small capital is that slippage is small, so strategy returns are realized close to theoretical values. Expectancy itself is independent of capital size. The "high return potential" felt with small capital is mostly increased variance mistaken for increased expected return. [verified — basic statistics]
2. Price movement ≠ account return. BTC's daily volatility standard deviation is roughly 2~3% (a daily conversion of 41~53% annualized as of 2026-07). ±5% is "an occasional 2σ event", not the default. What a strategy actually captures is range × capture rate, and leverage does not raise the capture rate. [verified — based on measured values; note this is a point-in-time snapshot]
3. Parameter sweep ≠ diversification. Parameter variations of the same logic (RSI 14 vs 21) are structurally highly correlated and give no diversification. Diversification arises only between strategies with different market mechanisms (mean reversion vs trend vs market-neutral). [verified]

Phase 0 — defining principles and criteria (before coding, half a day)

Fix things in documents before writing a single line of code. Skipping this stage leads, in loss periods, toward "refining the backtest further instead of dropping the strategy" — the trading version of the pattern of expanding the plan when execution stalls.

0.1 Kill Criteria (fixed in numbers, no amendment after the fact)

⚠️ The numbers above are examples. The owner sets the final values, but once set, they are not amended while in a loss. If an amendment is needed, only with no positions.

0.2 Success criteria (not profit)

• Backtest ↔ paper trading deviation < 20% [inference — a reasonable threshold, not a standard]
• 3+ months of uninterrupted automated operation (system stability)
• Automatic recording of every trade log and decision rationale (track record = the real asset for collaboration and raising capital)

0.3 Fixing the environment and tools

• Language: Python 3.11+ / libraries: vectorbt or backtesting.py (no building the engine from scratch — compress to 100~300 lines)
• Data storage: local parquet or SQLite (initially), TimescaleDB if scale grows [TBD]
• Version control: Git (same workflow as 64patterns), stored outside the OneDrive folder (to avoid file truncation issues)
• Exchange: Binance USDT-M futures + a separate testnet account (testnet.binancefuture.com)

Phase 1 — data pipeline (within 1 week)

1.1 What to collect

1.2 Period and resolution principles

• At least 2 years, 4+ years if possible (must include 3 regimes: bull, bear and sideways) [verified — single-regime data leads straight to overfitting]
• Base resolution 1h, down to 5m depending on the strategy. Tick/second level is outside v1 scope.
• Download scripts support incremental updates (no full re-collection each time).

1.3 Data quality checks (run automatically right after collection)

• Missing candle detection (timestamp continuity)
• Outlier detection (distinguishing flash crashes such as a single candle ±30% — flag, not remove)
• Fix the 3-way data split boundaries: train 60% / validation 20% / final test 20%. The final test period stays sealed until Phase 3 is complete. Touching parameters after opening it contaminates it at that moment — a re-split is needed.

Phase 2 — backtesting engine MVP (1~2 weeks)

Scope: 1 strategy (RSI mean reversion), 1 coin (BTC), 200~400 lines. If the urge to widen the scope arises here, that is the signal the plan-expansion pattern is triggering.

2.1 Layered structure (module separation — the skeleton of every later Phase)

[1] Data layer       load_data(symbol, timeframe, start, end) → DataFrame
[2] Indicator layer  each indicator = an independent pure function (rsi(), bbands(), atr(), ...)
[3] Signal layer     conditions defined by config (JSON/dict) → change combinations without code changes
[4] Money management layer  position sizing + leverage (in earnest in Phase 4; fixed values in the MVP)
[5] Execution/statistics layer  delegated to the library (vectorbt/backtesting.py)

2.2 Must be in the MVP (omissions bias results structurally toward optimism)

2.3 Output metrics (the common language for comparing strategies)

Total return, CAGR, Sharpe/Sortino, MDD, win rate, payoff ratio, trade count, average holding time, total fees + funding (% of profit), monthly return heatmap.

Phase 3 — strategy layer + validation methodology (2~4 weeks)

3.1 v1 strategy candidates (implementation order)

3.2 Validation protocol (applied identically to every strategy)

1. Parameter search only in the train period (grid/random search)
2. Check top candidates in the validation period — a sharp drop versus train means overfitting; discard
3. Walk-forward: must pass a rolling window (e.g. 6 months train → 1 month validation, stepping forward 1 month at a time)
4. Open the final test period — only 1 time. If it fails here, review the whole strategy family
5. Record the number of parameter combinations searched → multiple-testing correction (with 100 searched, 1~2 that look good by chance are a statistical certainty) [verified]

3.3 Regime classification (v1.5, excluded from the MVP)

• 3 classes, trend/sideways/high-volatility, by ADX / moving-average slope / realized volatility [inference — effectiveness cannot be judged before backtesting]
• Purpose: the real value of parallel strategies may come not from running them simultaneously but from shifting weights by regime.

Phase 4 — money management layer (1~2 weeks, can partly run in parallel with Phase 3)

Must be implemented separately from the signal layer — if mixed, "signal problem vs money-management problem" cannot be debugged.

4.1 Staged introduction

4.2 Validation method

A/B backtest with the same signals, changing only the money-management method. Comparison focuses not on returns but on MDD and probability of ruin (Monte Carlo simulation).

Phase 5 — parallel strategy portfolio (2 weeks)

5.1 Inclusion conditions (all must be met)

1. Pass every stage of the Phase 3 validation protocol
2. Return time-series correlation with already admitted strategies < 0.3 [inference — the threshold is conventional; lower is better]
3. Executable with the allocated capital under minimum order size constraints

5.2 Capital allocation

• v1: equal allocation (1/N)
• v2: risk parity (inverse volatility weighting) — theoretically superior but implementation complexity jumps; limited benefit with 3 or fewer strategies [inference]

5.3 Explicit pitfalls

Running highly correlated strategies in parallel = hidden leverage, not diversification. Skipping the correlation check at admission exposes the whole portfolio to a single risk.

Phase 6 — automated strategy search (optional, only after validating the whole pipeline)

• Reason for its position: putting automated search on an unvalidated system makes it impossible to tell which layer a problem is in.
• Mandatory safeguards when introduced: strict 3-way data split + walk-forward + multiple-testing-corrected metrics such as the Deflated Sharpe Ratio.
• Psychological pitfall warning: "optimal values found by the system" carry authority and lower the threshold for live deployment. Automated search results must pass the same validation protocol as manual strategies — no exceptions.
• Compute cost: combinations × parameters × walk-forward windows = thousands of backtests. If too heavy locally, cloud spot instances [TBD].

Phase 7 — paper trading (at least 2~4 weeks, never skipped)

The mandatory gate between backtesting and live trading. What is checked here is deviation, not profit.

7.1 Execution

• Run the actual bot code as is on the Binance futures testnet (not backtest code — a rehearsal of the Phase 8 live code)
• In parallel: shadow records based on real-account prices (the testnet's liquidity differs from real accounts, which may distort fill prices [TBD — needs measurement])

7.2 Measurement items

If the deviation criterion is not met: no live trading entry; retry after calibrating the slippage/fee/execution model. After 3 consecutive failures, the Phase 0 kill criteria trigger.

Phase 8 — going live: the Binance API live system

8.1 Live system architecture (sharing signal code with the backtester is the key)

┌─────────────────────────────────────────────────┐
│                  Live Trading Bot                │
│                                                  │
│  [A] Data Feed      WebSocket kline/markPrice   │
│         ↓            (REST fallback, reconnection logic) │
│  [B] Signal Engine  ★imports the same module as the backtester★ │
│         ↓            (two code paths = the root of deviation) │
│  [C] Risk Manager   pre-order checkpoint:          │
│         ↓            daily loss limit / max position / │
│         ↓            leverage cap / kill switch     │
│  [D] Order Manager  order submission, fill tracking, │
│         ↓            partial fill handling, retries (idempotency) │
│  [E] State Store    position, balance, order status DB │
│  [F] Monitor        logs + alerts (Telegram) +     │
│                      heartbeat + daily report      │
└─────────────────────────────────────────────────┘

Reuse patterns already proven in 64patterns: idempotency keys (preventing duplicate orders — the same principle as credit_transactions), graceful partial handling on failure, webhook/event-based state updates.

8.2 Safeguards (all P0)

8.3 Operating routine

• Daily: automatic report (profit, trade count, measured slippage, system status) — check only, no intervention
• Weekly: review deviation between backtest expectations and results
• Monthly: check against the kill criteria, review whether each strategy stays admitted
• Intervention principle: manual parameter changes only with no positions + a documented rationale

8.4 Infrastructure

• v1: an always-on VPS (low spec is enough for hourly strategies, around $5~10 per month) or a home server
• Latency: not a competitive factor for 1h/5m strategies. Low-latency infrastructure investment is unnecessary until v2 strategies such as OFI [inference]

Final system composition (target state)

                    ┌──────────────┐
                    │  Data Store   │ ← incremental collection pipeline (Phase 1)
                    └──────┬───────┘
                           │
        ┌──────────────────┼──────────────────┐
        ▼                  ▼                   ▼
┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│  Backtester   │   │ Paper Trader  │   │   Live Bot    │
│  (Phase 2-6)  │   │  (Phase 7)    │   │  (Phase 8)    │
└──────┬───────┘   └──────┬───────┘   └──────┬───────┘
       │                  │                   │
       └────────┬─────────┴───────────────────┘
                ▼
     ★ shared module (single source) ★
     indicators / signals / risk / sizing
     — all three execution environments import the same strategy code
                │
                ▼
        ┌──────────────┐
        │  Trade Ledger │ → track record (asset for collaboration and raising capital)
        │  + Reports    │
        └──────────────┘

Design principle no. 1: the backtester, paper and live share the strategy code. The moment the code diverges, the cause of deviation between backtest results and live trading can never be found.

Timeline summary (conservative)

In total about 3~4 months (excluding Phase 6). If pressure to go faster arises, reread the objective function in Phase 0.

Summary for onboarding collaborators (when sharing externally, this document + the 3 lines below)

1. The goal is not short-term profit but a validated system and track record (1,000,000 KRW at 20~30% a year ≈ 200,000~300,000 KRW — the profit itself is meaningless at this stage).
2. Every strategy must pass the 3-way split + walk-forward + deviation measurement to be admitted to live trading.
3. The kill criteria are fixed in a document, and the principle is no amendment while in a loss.