The Data Hierarchy

Not all data is equal. Here’s the hierarchy from essential to advanced:

Start with OHLCV candles. You can build your first strategy, backtest it, and deploy it with nothing else. Add funding rates and open interest when you want to model costs properly and explore positioning-based signals. The rest comes later.

Timeframes

Candles come in different timeframes. Each serves a different purpose:

• Weekly — for slow, trend-following strategies (3–5 trades per year)
• Daily — the standard for most swing strategies and indicator calculations
• 4-Hour / 1-Hour — for intraday swing strategies
• 15-Minute / 5-Minute — for active intraday strategies
• 1-Minute — for precise entry timing and tape-reading simulation

More timeframes = more data = more storage = more maintenance. Start with daily and weekly. Add smaller timeframes only when your strategy requires them.

Free Sources (Exchange APIs)

For crypto: One tier-1 perpetual venue with a clean API and good depth, paired with a tier-1 spot venue with the deepest history, is a solid default. Use the deeper-history source for historical backfill and your primary trading venue for live data.

For non-crypto: A retail FX/CFD broker with a free practice account is the easiest free source for FX, commodity, and index data going back many years. Useful for cross-asset correlation testing.

Building a Data Fetcher

You need a script that:

1. Connects to the exchange API
2. Fetches candle data in pages (most APIs return 200–1000 candles per request)
3. Handles pagination correctly (use the last candle’s timestamp as the start for the next request)
4. Respects rate limits (add a small delay between requests)
5. Stores results in a database or CSV file
6. Runs on a schedule (cron job) to keep data up to date

This is a straightforward Python script. An LLM like Claude or ChatGPT can help you write it in under an hour if you describe exactly what you need.

The Options

Common Data Quality Issues

Minimum Data Quality Checks

1. No gaps: Every expected time period has a candle
2. No duplicates: No timestamp appears more than once
3. Reasonable volume: No candle has volume that is zero or more than 5x the rolling median
4. OHLC integrity: High ≥ Open, Close, Low. Low ≤ Open, Close, High.
5. Monotonic timestamps: Each candle’s timestamp is exactly one period after the previous
6. Complete candles: The most recent candle is for a period that has actually closed

Run these checks every time new data is ingested. Fail loudly if any check fails. Never let unvalidated data reach your strategy engine.

How Much History Do You Need?

• Minimum: 3 years. Covers at least one bull market, one bear market, and some chop.
• Recommended: 5+ years. Enough to split into training and test sets while still having meaningful data in each.
• For weekly strategies: 5 years gives you ~260 candles. 3 years gives you ~156. You need enough data for statistical significance.

The Backfill Process

Why WebSocket Beats Polling

For anything that changes faster than your cron interval — ticks, your own fills, your own order updates, position state — polling is the wrong tool. Three reasons:

• Latency. A WebSocket push arrives in tens of milliseconds. A 1-second poll loop has, on average, 500ms of dead air between “something happened” and “your bot heard about it”. For an order that filled and is now drifting against you with no stop in place yet, that’s a long time.
• Rate limits. REST endpoints are rate-limited; WebSockets generally are not (per-message, anyway). A polling loop tight enough to be useful is a polling loop that will eventually 429 and back off — usually exactly when the market is moving and the venue is busy.
• Completeness. Between two REST polls you can miss intermediate state entirely — a fill that arrived and was reduced by another fill, an order that was placed and cancelled inside one polling window. Streams emit every transition.

Division of Labour: WebSocket vs REST

The two are complements, not substitutes. A reasonable default split:

• WebSocket (streaming): ticks, trades, order-book updates, your account’s order updates, your account’s fills, position state changes, funding-rate updates.
• REST (snapshots and control): initial account state on startup, periodic full reconciliation snapshots, historical backfill, placing and cancelling orders. Many operators place orders over REST even when the venue offers WS order entry, because REST is simpler to reason about and the latency penalty on placement is small relative to a position’s holding period. Opinions vary.

The WebSocket is the source of truth for change. The REST snapshot is the source of truth for state. Both, together, defend against the failure modes of either alone.

Reconnection Discipline

Connections drop. Networks blip. Venues restart. Your reconnect logic decides whether you trade through it or sit blind for an hour.

• Exponential backoff with jitter. First reconnect attempt: 1 second. Then 2, 4, 8, 16, capped at 60. Add ±25% jitter to each delay so your bot and a thousand others don’t all hammer the venue at the same instant when it comes back up. Without jitter, the herd takes the venue down again on its first breath.
• Circuit-breaker on flap. If you’ve reconnected more than N times in the last minute, stop reconnecting and alert. A flapping connection is almost always a sign of a deeper problem (your network, the venue’s, or a key error) that more reconnects will not fix. Better to halt and page than to log-spam a runbook into oblivion.
• Resubscribe explicitly on reconnect. A new connection has no subscriptions. Re-send every subscribe message; do not assume the venue remembered.
• Reconcile on every reconnect. The window of disconnection is exactly when fills you missed live. The first thing to do after “CONNECTED” is a REST snapshot of orders, positions, and recent fills, diff against local state, and emit any reconciliation actions before resuming normal trading.

Sequence-Gap Handling

Most venues stamp every WebSocket message with a monotonically-increasing sequence number per channel. The discipline is small and absolute: if you receive seq N+2 after seq N, you missed N+1. There is no “probably nothing important happened.”

• On gap detection, fetch a REST snapshot for that channel (full order-book snapshot, full positions snapshot, etc.) and treat it as authoritative.
• Drop any buffered out-of-order messages older than the snapshot timestamp.
• Log the gap with both seq numbers and the time delta so you can diagnose whether it’s your network or the venue’s feed.

An order book that’s silently missing one update is worse than no order book at all — it makes confident decisions on stale state. Force-resnap is cheap insurance.

Checksum Verification on Order-Book Streams

Most venues that stream incremental order-book updates also publish a periodic checksum — typically a hash of the top-N levels of bids and asks. The contract is: if your locally-reconstructed book’s checksum doesn’t match the venue’s on the same tick, your local book is wrong. Causes range from a dropped delta to a mis-handled price-level deletion. The remedy is the same regardless: force-resnap. Discard the local book, fetch a full snapshot, replay any deltas that have arrived since.

If you trade off the order book at all — even just for sizing slippage estimates — verify checksums. A book you don’t verify is a book you can’t trust.

Idempotency and Deduplication

The same fill might land in your handler twice: once from the WebSocket fill stream, once from the REST snapshot you took on reconnect. Or three times, if the websocket re-delivers a buffered message after reconnect. The defence is a single line: dedupe by the venue’s fill_id (or order_id, or whatever immutable identifier the venue assigns). Before you process any fill, check whether you’ve already recorded it; if yes, drop. The cost is one indexed lookup per event; the benefit is that double-counting fills cannot corrupt your state.

The same applies to order updates: dedupe by (order_id, status, update_ts). Many venues will re-emit the “FILLED” status under various edge cases; your state machine should be a no-op the second time.

The Conversion Process

Most trading ideas sound like this: “BTC tends to rally after big dips.” That is not a strategy. It is an observation. To make it testable, you need to answer five questions:

1. What defines the condition? — What counts as a “big dip”? A 10% drop in 7 days? A daily candle closing below the 200-day moving average?
2. What is the entry signal? — Do you buy the moment the condition is met? The next candle open? After a confirmation candle?
3. What is the exit signal? — Time-based (hold for 14 days)? Target-based (sell at +5%)? Indicator-based (sell when RSI > 70)?
4. What is the position? — Long only? Short only? Both directions?
5. What timeframe? — Daily candles? Weekly? 4-hour?

Example: From Vague to Precise

The vague versions are untestable. The precise versions can be coded and backtested in an afternoon.

The Strategy Spectrum

Where to Start

Start with weekly trend following. Here is why:

• Fewest trades per year means lowest fees and least execution complexity
• Simplest logic: one indicator, one or two filters, binary position (long or flat)
• Long observation window: 5 years of weekly candles is ~260 data points, allowing the strategy to be exposed to multiple regimes
• Forces parsimony: a weekly system with only 3–8 trades per year cannot support many parameters — you are constrained to 1–2 indicators and a simple rule, which is the real defence against overfitting
• Set-and-forget: the system checks once per week, not every second

Important nuance: low trade count does not automatically mean “hard to overfit.” The opposite is true — low N means high variance, wider confidence intervals on every metric, and an easier path to fitting noise. The defence against overfitting at low N is parsimony (very few parameters), long observation windows (multiple regimes), simple rules (mechanism you can articulate), and cross-instrument validation (does the same rule work on ETH, SOL, etc. without re-tuning?). A weekly system is “safer” only because the format forces these constraints — not because few trades is inherently more honest.

Our simplest live strategy — a weekly trend-following system — trades a handful of times per year and shows a strong profit factor over a multi-year window. Simple does not mean weak — but a multi-year, low-double-digit-trade sample is still a wide confidence interval, which is why we lean on cross-instrument and walk-forward checks rather than the single point estimate.

Real Examples Across the Spectrum

What Is a Gate?

A gate is a condition that must be true in addition to the entry signal. If the signal fires but the gate is closed, the system does nothing. Gates filter out low-conviction setups.

Real Impact: Before and After Gates

Here is the directional impact gates had on one of our live strategies. The numbers are deliberately qualitative — the point is the shape of the improvement, not specific values:

Fewer trades, higher returns, lower drawdown. The gates eliminated trades that would have been losers — low-conviction entries during choppy or indecisive markets. The signal was the same. The gates made it profitable.

The Six Steps

Worked Example (Illustrative): A Day-of-Week Effect

This is a textbook illustrative example — not a proprietary investigation — chosen because it’s familiar and shows the template clearly. Imagine you’ve heard the claim that a major equity index has a “Tuesday effect” — that Tuesdays are systematically stronger than other weekdays. Here is the shape of how that investigation would play out under this template:

• Claim: The underlying has a positive Tuesday bias
• Hypothesis: Average daily return on Tuesdays exceeds the average daily return across all other weekdays by a statistically meaningful margin
• Data: Multi-year daily history of the index
• Raw result: Marginally positive Tuesday average return — not enough to act on standalone.
• Filters applied: Volatility (low/medium/high), regime (bull/bear/chop), month of year, prior-day direction, cross-asset
• Key finding: In low-volatility windows the Tuesday edge flipped from flat to clearly positive; in medium-volatility windows it went negative. The volatility filter was the entire differentiator.
• Cross-asset: The effect appeared on related indices, with a similar conditional pattern — suggesting a real (if narrow) market dynamic rather than single-asset noise.
• Verdict: Weak signal, not tradeable standalone. Interesting as a conditional relationship, insufficient for production capital.

Total time on a real investigation of this shape: about half a day. The investigation produces real knowledge: a conditional relationship exists, it’s not strong enough to trade, and the volatility filter is the key variable. That last insight is useful for other research.

What LLMs Are Good At

• Writing backtesting code: Describe your hypothesis precisely and an LLM can produce a working backtest script in minutes. Review it carefully — check for look-ahead bias, correct fee modelling, and proper data handling.
• Generating hypotheses: “Given this dataset of BTC daily candles with funding rate and open interest, what are 10 testable hypotheses about predictable price behaviour?” LLMs produce creative starting points.
• Interpreting results: Paste a backtest output and ask: “Is this statistically significant? What are the red flags? What would you test next?”
• Adversarial review: Use one LLM to build the strategy, then give the backtest results to a different LLM and ask it to attack. “Find every reason this strategy might be overfitted or misleading.”

What LLMs Are NOT Good At

• Predicting markets: An LLM has no access to current market data and no ability to forecast price movements. Never ask “will BTC go up tomorrow?”
• Replacing testing: An LLM might say “that strategy should work because…” That’s a theory, not evidence. Always test.
• Writing production-grade trading code without review: LLM-generated code can have subtle bugs — especially around look-ahead bias, timezone handling, and edge cases. Always review and test.

The Multi-LLM Workflow

For maximum rigour, use multiple LLMs in an adversarial workflow:

1. LLM #1 (Builder): Write the strategy code and run the backtest
2. LLM #2 (Attacker): Review the code for bugs, review the results for overfitting signals, suggest falsification tests
3. LLM #3 (Synthesiser): Given both perspectives, produce a final assessment

This mirrors how professional quant teams work: the researcher proposes, the risk team attacks, and the portfolio manager decides. You can simulate all three roles with different LLMs or different conversations.

The Core Loop

Every backtester, no matter how sophisticated, runs the same basic loop:

Evaluation Metrics: Beyond Sharpe and PF

Sharpe ratio, profit factor, win rate, and max drawdown are the starting set, but no single metric captures a strategy. Pros look at a panel. Add at least these three:

• Sortino ratio — like Sharpe but uses downside deviation (volatility of negative returns) in the denominator instead of total volatility. Preferred for asymmetric strategies (trend-following, long-tail-capture systems) where upside volatility is desirable and Sharpe unfairly penalises a strategy for having big winners. Sortino = (mean return − risk-free) / downside deviation.
• Calmar ratio — annualised return divided by max drawdown. The metric of choice for capital-preservation-conscious investors and for sizing decisions: it directly answers “how much return per unit of worst-case pain?” A Calmar of 1.0 means you earned, on a yearly basis, what your worst drawdown cost you. Above 2 is strong; above 3 is exceptional.
• Information Coefficient (IC) — for predictive signals (anything that produces a continuous score, not just binary entries), IC is the Spearman or Pearson correlation between the signal value and the forward return. It is the cross-section quant standard for “does my signal carry information?” Useful even before you have a fully formed entry/exit rule. Even a small but stable IC (0.03–0.05) can be tradeable; instability matters more than absolute level.

When each is most informative: Sharpe for symmetric / mean-reverting systems and broad portfolio comparisons. Sortino for trend-following or any strategy where upside vol is the point. Calmar when you’re sizing capital or comparing strategies for retirement-style accounts. IC for signal research before strategy construction. Profit factor for trade-by-trade asymmetry. Win rate only in combination with average-win/average-loss ratio — high win rate with poor PF is a red flag for “picking up pennies in front of a steamroller.”

Look at all of them. A strategy that looks good on Sharpe but ugly on Calmar has hidden tail risk. A strategy with a high IC but low Sharpe likely has an execution problem, not a signal problem. The panel tells you which.

Building Your Own vs Using a Framework

You have two options:

• Build your own: A simple backtester in Python/pandas is 100–300 lines. You control everything. You understand everything. Recommended for your first strategy.
• Use a framework: Libraries like backtrader, vectorbt, or zipline provide pre-built infrastructure. Faster to start but harder to customise and easier to misuse.

We recommend building your own for your first strategy, using an LLM to help with the code. This forces you to understand every line. Once you understand the mechanics, frameworks become useful for speed.

Why One Backtest Is Not Enough

Your backtest shows a max drawdown of -15%. Great. But what if the three worst trades had happened consecutively instead of spread out? The drawdown might have been -35%. The specific order of trades in history is one random sample from a much larger distribution of plausible orderings. Monte Carlo’s job is to estimate that distribution.

First-Pass Illustration: The Naive Shuffle (and Why It’s Wrong)

The textbook introduction to Monte Carlo on backtest output is “take your N trades, randomly shuffle the order, simulate the equity curve, repeat 10,000 times, look at the distribution.” This is useful as a first-pass illustration of variance — it shows that the historical equity curve is one of many possible paths — but it is the wrong production method for trading data.

The reason: shuffling assumes trades are independent and identically distributed (i.i.d.). They are not. Real trading P&L exhibits:

• Serial correlation: Trend-following systems win streaks during trending regimes and lose streaks during chop. Mean-reversion systems do the opposite.
• Regime clustering: A bear market produces clustered losses for long-only systems. Shuffling sprays those losses across the timeline and erases the cluster.
• Volatility clustering: High-vol periods produce both bigger wins and bigger losses, bunched together. Shuffling smears them flat.

This matters because real drawdowns come precisely from clustered losses — runs of correlated bad trades during the wrong regime. A naive shuffle systematically underestimates tail drawdown risk by destroying exactly the dependence structure that produces it. If you size your account on naive-shuffle 95th-percentile drawdown, you are sizing on an optimistic distribution.

Block Bootstrap (the Correct First Production Method)

Block bootstrap preserves local autocorrelation by resampling contiguous blocks of trades instead of individual trades.

Pseudocode:

trades = list of N trade returns in chronological order
block_size = round(sqrt(N))           # rule of thumb; see below
n_blocks = ceil(N / block_size)

FOR each of 10,000 simulations:
    sampled = []
    FOR i in 1..n_blocks:
        start = random integer in [0, N - block_size]
        sampled.extend(trades[start : start + block_size])
    truncate sampled to length N
    simulate equity curve from sampled
    record final return, max DD, Sharpe, etc.

distribution = the 10,000 results

Block-length rule of thumb: block ≈ √N is a reasonable default. For higher-frequency strategies (intraday, hundreds of trades), 5–10 trades per block is usually enough to preserve short-horizon dependence. For lower-frequency strategies with strong regime structure, push toward 15–20 trades per block so each block spans a meaningful slice of regime time. Sensitivity-test the result across two or three block sizes — if your tail estimates wobble dramatically, the dependence structure is doing real work and the answer is uncertain.

Stationary Bootstrap (Politis–Romano)

Fixed block lengths have an arbitrariness problem: why 5? why 20? The stationary bootstrap (Politis & Romano, 1994) draws a random block length each time from a geometric distribution with mean p⁻¹. This produces a resampled series that is itself stationary (the fixed-block version is not), and is generally more robust to block-size mis-specification.

Recipe: at each step, with probability p start a new block at a random position; otherwise continue the current block. Choose p so 1/p matches your target average block length (e.g. p = 0.1 for an average block length of 10 trades). For most retail-scale playbook work, stationary bootstrap is the default to reach for.

Regime-Stratified Resample

If you have already labelled each trade with the regime it occurred in (bull / bear / chop, or high-vol / low-vol), you can resample within each regime separately and recombine in proportion to the regime exposure you expect going forward. This preserves regime-conditional behaviour rather than averaging it out.

This is useful when the strategy clearly behaves differently across regimes and you care about scenarios like “what happens if the next 12 months are 70% chop and 30% bear?” You can also use it to stress-test against a regime mix that is more hostile than the historical mix.

Out-of-Sample (OOS) Testing

The simplest version: split your data into two parts.

• In-sample (70%): 2020–2023. Use this to develop and optimise your strategy.
• Out-of-sample (30%): 2024–2026. Test the finalised strategy here. Do not look at this data during development.

If the strategy performs similarly on both sets, the edge might be real. If it performs well in-sample but fails out-of-sample, you overfitted.

Walk-Forward Testing

A more rigorous version: roll through time in windows.

1. Train on 2020–2022, test on 2023
2. Train on 2021–2023, test on 2024
3. Train on 2022–2024, test on 2025

Each test period is truly unseen. If the strategy is consistently profitable across all test windows, the edge is robust. If it works in some windows and fails in others, investigate which market conditions caused the failures — that tells you about regime sensitivity.

Rolling vs Anchored Walk-Forward

Two variants, with a real trade-off:

• Rolling: the training window has a fixed length (e.g. 3 years) and slides forward. Each retraining drops the oldest data. Adapts faster to regime change because old, no-longer-representative data falls off. Use when you believe the data-generating process drifts — market microstructure changes, new venues, post-halving regime shifts.
• Anchored: the training window grows — the start point stays fixed, more data is appended each cycle. Uses all available history. More statistical power, less adaptive. Use when the underlying mechanism is stationary (a structural carry trade, a well-grounded behavioural pattern) and old data is still informative.

Rule of thumb: rolling for crypto and fast-moving microstructure-driven edges; anchored for macro-structural or cross-asset patterns. If unsure, run both and compare — if rolling is materially better than anchored, that itself tells you the edge is regime-sensitive and you have a degradation-risk dimension to monitor in production.

Time-Cut Hygiene: Data Freeze, Commit Hash, Single-Look

Walk-forward is only as honest as the discipline around it. Three rules:

• Data freeze date. Record, in the strategy report, the exact date and time at which the OOS data was carved off and the in-sample window was sealed. Any data that arrives after that timestamp is OOS. If you re-run the analysis later with newer data, that is a new walk-forward cycle, not a continuation.
• Commit hash discipline. Every backtest result is associated with a code commit hash. Results from uncommitted code are unverifiable — you can’t reproduce them, and a future you can’t audit them. Strategy reports without an attached commit hash get treated as informal notes, not evidence.
• Single-look OOS. Once you have looked at the OOS performance, you have used that data to inform your decisions, even if all you did was “think about it.” Your subsequent choices are now informed by the OOS sample — the data is contaminated. You have two honest options: (a) accept the result as the final, single-look verdict on the strategy in its current form; or (b) freeze a new OOS window going forward (true walk-forward into the future) and treat the previous OOS result as part of the in-sample. There is no third option that preserves OOS purity.

How to Run a Sensitivity Sweep

1. Identify every tuneable parameter in your strategy (e.g., a moving-average lookback, a close-position gate threshold, an efficiency-ratio gate threshold)
2. For each parameter, test a range of values around your chosen setting (e.g., for a lookback of N, test N−1, N, N+1, N+2)
3. Run the full backtest for each combination
4. Plot the results as a heatmap or table
5. Check: is your chosen parameter in a “plateau” of good performance? Or is it a lone spike?

What Good vs Bad Sensitivity Looks Like

Here is the shape of a healthy parameter sweep. Imagine sweeping a gate threshold across its plausible range and recording CAGR and profit factor at each value:

This is a robust parameter: performance is strong across a wide range, and the selected value sits in a broad plateau. Moving the threshold by ±10% barely changes the result. This is what you want.

A fragile parameter would show a sharp spike at exactly one value, with sudden collapse one tick in either direction. If one tick destroys the strategy, the “edge” is an artefact of the specific data, not a real market phenomenon.

The Multiple-Testing Problem

Run 100 strategy variants and apply a p < 0.05 cutoff. If none of them have any real edge, you still expect ~5 of them to look statistically significant by pure chance. The standard p-value is calibrated to a single test. Run many tests and the probability that at least one looks significant climbs fast: with 20 independent tests and no real signal, there is a 64% chance at least one comes in under p < 0.05. Run 100, it is essentially certain.

This affects almost everything in trading research:

• Parameter sweeps within a strategy (“the best of 200 combinations”)
• Hypothesis scans across instruments (“works on 3 of 23 coins”)
• Anomaly-scanner output filtering (“80 anomalies, 40 plausible”)
• Cross-venue tests, time-of-day effects, day-of-week effects, calendar effects

If you don’t correct for the number of tests, you are guaranteeing a steady stream of fake winners.

Bonferroni Correction (Conservative)

The simplest fix: divide your significance threshold α by the number of tests N. To claim a finding is significant at α = 0.05 across 100 tests, that finding must individually satisfy p < 0.0005. Bonferroni controls the family-wise error rate (FWER) — the probability of any false positive across the whole family of tests — at α.

Bonferroni is the right call for confirmatory tests: when a false positive is genuinely costly (you’re about to deploy capital), and you would rather miss real edges than ship a fake one.

The downside: it is brutally conservative. Real but moderate edges will fail Bonferroni in any large sweep, and you’ll under-discover.

Benjamini–Hochberg / FDR Control (Better for Exploratory Research)

The Benjamini–Hochberg (BH) procedure controls the False Discovery Rate (FDR) — the expected fraction of false positives among the tests you call significant, rather than the probability of any false positive at all. This is usually what you actually want: “of the 12 strategies I’m flagging as winners, I’m willing to tolerate ~10% being noise, in exchange for finding more real edges.”

Recipe:

1. Run all N tests, collect their p-values.
2. Sort the p-values ascending: p₍₁₎ ≤ p₍₂₎ ≤ … ≤ p_(N).
3. Choose your desired FDR level q (e.g. 0.10 = tolerate 10% false positives among discoveries).
4. Find the largest rank i for which p_(i) ≤ (i/N) × q.
5. Reject (call significant) all tests with rank ≤ i.

BH is the right call for exploratory research: anomaly scans, parameter sweeps, multi-instrument hypothesis testing — situations where you can tolerate some false positives downstream because they get filtered by paper trading and the falsification suite, but you want to bound the noise rate so the candidate list is meaningful.

Choosing & Applying

Practical note: track the total number of tests run on a research idea across the whole project lifetime, not just inside one notebook. If you tested 50 variants last week, killed them, and are now testing 50 more, the relevant N is 100. This is uncomfortable but honest. Selection bias compounds across sessions if you don’t.

The Three Ways Backtests Lie

The Falsification Funnel

Kill It

• Fails the placebo test (not better than random)
• Performance collapses completely out-of-sample (zero or negative)
• Only works at one exact parameter setting (narrow spike, no plateau)
• The mechanical reason for why it should work doesn’t hold up logically
• Sample size is too small for meaningful conclusions (<20 trades)

Tune It

• Works well in two regimes but fails in a third → add a regime gate (Module 10)
• OOS performance is positive but weaker than in-sample → likely some overfitting, but the core signal may be real. Simplify the strategy (fewer parameters) and re-test.
• Fails on one exchange but works on two others → investigate the exchange-specific issue (different trading hours, different fee structure)
• Time stability shows degradation in the recent period → the market may have changed. Investigate what changed and whether the signal can adapt.

The Adversarial Review Prompt

Give a fresh LLM (one that did not help build the strategy) the following:

• The strategy rules (entry, exit, gates, parameters)
• The backtest results (all metrics, trade list)
• The parameter sensitivity sweep results
• The out-of-sample results

Then ask: “Your job is to find every reason this strategy might fail in live trading. Attack the methodology, the statistics, the assumptions, and the implementation. Assume the builder has confirmation bias. What are they not seeing?”

What Good Adversarial Review Looks Like

A good adversarial review will surface things like:

• “The headline CAGR is driven primarily by a small handful of trades clustered in one favourable year. Remove those and the CAGR drops by more than half.”
• “You used Monday-start weeks but didn’t verify this against the exchange’s actual weekly candle definition.”
• “The backtest assumes entry at the open, but the weekly open on Monday at 00:00 UTC is often a low-liquidity period with wider spreads.”
• “Your stop-loss is calculated from the entry price, but in a gap-down scenario, the actual fill could be significantly worse.”

Each of these is either a fixable issue (update the spec, add gap-down handling) or a genuine threat (if 3 trades drive all the returns, the sample is too concentrated). The review process surfaces these before real money is at risk.

The Formula

Every position size calculation follows this structure:

Risk Percentage Guidelines

Under fractional-fraction sizing (always risk a fixed % of current equity), the account is never literally “depleted” by a fixed number of consecutive losses — each loss is smaller than the last in absolute terms. The correct compounding formula is:

equity_remaining = (1 - r)^N

where r is risk per trade and N is the number of consecutive losses.

Start at 1%. 100 consecutive losses at 1% leaves you with roughly 36.6% of starting equity — a brutal 63% drawdown, but not zero. The real metric to focus on is probability of ruin (or probability of hitting a chosen drawdown threshold), which depends jointly on win rate, payoff ratio (avg win / avg loss), risk per trade, and the drawdown level you treat as ruin. Naive “consecutive-loss-to-zero” math both overstates safety (you don’t actually go to zero) and understates damage (you can hit a 50% drawdown long before any “ruin” threshold). Model probability of ruin explicitly using your validated strategy’s edge stats.

Types of Stop-Losses

Exchange-Side Stop Order Mechanics

“Place a stop” sounds like one button. It isn’t. The flags you set on that order determine whether it does what you actually wanted in adverse conditions. The following are the parameters every operator should consciously choose, not accept by default.

Trigger price source: mark vs last

Most perpetual venues let you trigger a stop on either the mark price (an index-derived fair value, often a moving average of multiple spot venues) or the last traded price. The trade-off:

• Mark price — smoother, harder to manipulate, less prone to wick-outs. A single bad-print trade on your venue won’t take you out.
• Last price — faster to react, but vulnerable to a wick on a thin book or a one-tick spoof. Your stop fires on a price that may not represent fair value.

Default to mark price for protective stops. Last price is acceptable only when you specifically need wick-speed reaction and your liquidity is deep enough that wicks reflect real flow.

Reduce-only flag

A stop should only ever close exposure, never open new exposure. Set reduceOnly = true on every stop order. Without this flag, an edge case can flip you into a doubled position: the entry order is still partially filling when the stop fires, the stop sells the full intended size, and you end up short the unfilled portion. Reduce-only tells the venue “this order can only reduce or close my position; if there’s nothing to close, do nothing.” Belt-and-braces against the partial-fill race.

Time-in-force (TIF)

Every order has a TIF that governs how long it lives:

• GTC (good-till-cancel): rests on the book until filled or cancelled. Default for stops — you want the stop to stay until it triggers, not expire silently.
• IOC (immediate-or-cancel): any portion that can’t fill immediately is cancelled. Useful for market entries where you want the fill or nothing — rather than have a partial sit on the book at a price that’s now stale.
• FOK (fill-or-kill): entire order fills immediately or the whole thing cancels. Rarely useful at retail size; mostly relevant for block executions where partial fills break the strategy.
• GTD / Day: good-till-date or session. Avoid for stops — you do not want your protective stop to expire at midnight UTC.

OCO (one-cancels-the-other)

If your strategy has both a stop-loss and a take-profit on the same position, you want them linked: when one fills, the other cancels automatically. Otherwise the surviving order remains live with no position behind it — and on next move it opens a fresh position in the wrong direction.

• If your venue supports OCO natively: use it. One submission, one atomic cancel-on-fill.
• If not: emulate. Submit two separate orders, then subscribe to the venue’s order-update stream; when one fires, immediately cancel the other. Build the cancellation into the same handler so there is no window where both can fill.
• Failure mode to test: what happens if the stream disconnects between fill and cancel? Your reconciliation loop (Module 8.3) should catch the orphaned opposing order on its next pass.

Position mode: hedge vs one-way

Most venues offer two position modes:

• One-way mode: a symbol has a single net position. A buy in a short position reduces or flips the position. Simpler accounting; one stop per symbol.
• Hedge mode: a symbol can hold a long and a short position simultaneously, each with its own margin and PnL. Lets independent strategies trade the same symbol without interfering. Each side gets its own stop.

Stops behave differently across modes — a reduce-only sell stop in hedge mode reduces your long position; the same order in one-way mode could open a short if your long has already closed. Choose a mode explicitly per venue and document it in your config. Mismatch between local-state assumptions and venue-side mode is a classic source of phantom positions.

Re-sizing stops after partial fills

Your entry order is for 1.0 BTC; the venue fills 0.6 BTC and you decide to cancel the remainder. Your initial stop was sized for 1.0 BTC. Now it’s wrong — if it fires, it sells 1.0 of position you don’t have (or, worse, with reduce-only off, it flips you short by 0.4). The pattern:

on partial_fill(order_id, filled_qty):
    current_position = filled_qty   # what you actually hold
    if existing_stop_order:
        cancel(existing_stop_order)            # remove the wrongly-sized stop
        wait_for_cancel_ack()                  # confirm before placing new
    new_stop = place_stop(
        symbol      = order.symbol,
        side        = opposite(order.side),
        qty         = current_position,        # match the actual fill
        trigger     = stop_price,
        trigger_src = "mark",
        reduceOnly  = True,
        tif         = "GTC",
    )
    persist(new_stop.id)

Note the cancel-then-replace pattern is not free of race conditions (see Module 8.4 on amend-vs-replace) — if your venue supports atomic amendment of stop quantity, prefer that. The window between cancel and new-place is your exposure window: keep it short, alert if the cancel-ack is slow, and the reconciliation loop is your safety net.

Circuit Breaker Rules

The Hard Stop

At the account level, set an explicit drawdown threshold calibrated to your strategy’s expected drawdown profile — an absolute circuit breaker. If the account drops past that threshold from its peak, everything stops. All positions are closed. The system enters a mandatory cooling-off pause.

The reason to fix this number in advance is asymmetry: recovering from a 40% drawdown requires a 67% gain (achievable); recovering from a 70% drawdown requires a 233% gain (functionally starting over). The circuit breaker exists to prevent the drawdown from ever reaching the point of no return — and to take the decision out of your hands when you’re emotional.

Correlation Risk

If you run a trend-following long strategy and a momentum long strategy on BTC, both will lose during a sudden market crash. Your portfolio drawdown is not the average of the two strategies — it’s additive. Two -15% drawdowns happening simultaneously become a -30% portfolio drawdown.

Mitigation strategies:

• Trade different assets: BTC and ETH are correlated (~0.85). BTC and gold are weakly correlated (~0.15). A BTC trend strategy + a gold mean-reversion strategy provides genuine diversification.
• Trade different directions: A long-only strategy paired with a short-only strategy (on different assets or regime-gated) provides natural hedging.
• Trade different timeframes: A weekly strategy and an intraday strategy have low trade overlap even on the same asset.
• Capital allocation: Don’t put 100% of capital into correlated strategies. Allocate based on correlation: high correlation = lower combined allocation.

The Architecture Spectrum

Our production system uses per-exchange containers. Each exchange runs in its own Docker container with its own strategy engine, order executor, and state management. They share a data layer (candle database) and a regime detection service. If one container crashes, the others keep running.

Start Simple

Do not start with per-exchange containers. Start with a single script. Get it working. Then refactor into modules. Then containerise. Premature architecture is as dangerous as premature optimisation.

Order Executor Patterns

The executor sits between intent (“buy 1 BTC at market”) and reality (a possibly-partial fill on a possibly-flaky API). The patterns below are what separate a toy executor from one you can leave running unattended.

Idempotent submission

Every order has a deterministic clientOrderId derived from the underlying intent — not a fresh UUID per call. If you crash mid-submit and retry, the venue dedupes on the ID and gives you back the existing order rather than creating a duplicate. Pattern:

def make_client_order_id(strategy_id, symbol, intent_ts, nonce):
    # Deterministic from intent. Same inputs --> same ID.
    raw = f"{strategy_id}|{symbol}|{intent_ts}|{nonce}"
    return hashlib.sha256(raw.encode()).hexdigest()[:32]

def submit_idempotent(intent):
    coid = make_client_order_id(
        intent.strategy_id, intent.symbol,
        intent.intent_ts,   intent.nonce,
    )
    try:
        return venue.place_order(client_order_id=coid, **intent.params)
    except VenueError as e:
        if e.code in {"DUPLICATE_CLIENT_ORDER_ID", "ORDER_ALREADY_EXISTS"}:
            return venue.get_order_by_client_id(coid)   # already accepted
        raise

Most tier-1 venues honour clientOrderId for deduplication for at least a few hours. Read your venue’s docs for the dedup window and design your retry policy to fit inside it.

Retryable error classification

Maintain a tight allowlist of retryable error codes per venue. Everything not on the list fails fast.

RETRYABLE = {
    "RATE_LIMIT",          # HTTP 429 or venue-specific
    "NETWORK_TIMEOUT",     # transport-level
    "TEMP_SERVER_ERROR",   # 5xx
    "VENUE_OVERLOAD",      # documented transient
}

PERMANENT = {
    "INVALID_SIGNATURE", "INVALID_TIMESTAMP",   # config error
    "INSUFFICIENT_BALANCE", "POSITION_LIMIT",   # state error
    "INVALID_SYMBOL", "INVALID_PARAMETER",      # logic error
    "IP_NOT_WHITELISTED", "PERMISSION_DENIED", # auth error
}
# Anything not in either set: log, alert, treat as permanent until classified.

Never retry on permanent errors. Hammering a dead API doesn’t fix it; it just buries the real problem under noise and burns your rate-limit budget.

Cancel-replace vs amend

To move a stop or change a price, you have two options:

• Cancel + replace: cancel the existing order, place a new one. Two round trips. Race condition: if the cancel succeeds but the replace fails (rate limit, transient error, validation), you have no protective order on the position until you notice and recover.
• Amend: a single atomic call that modifies the existing order in place. One round trip, no exposure window.

Prefer amend wherever the venue supports it. Especially for stop-loss adjustments, where the exposure window between cancel and replace is exactly the window during which you might need the stop.

Partial fill handling

Track filled_qty separately from order_qty in local state. Decide a policy per intent:

• Leave remainder open (GTC): default for resting limit entries; you wanted the price, accept slow fills.
• Cancel remainder: for time-sensitive entries; better to take the partial than carry stale exposure on a moving market.
• Replace at new price: for execution-bot patterns; cancel residual, re-quote at current best.

The choice is strategy-dependent; the requirement is that you make it explicitly, encode it in config, and re-size every dependent order (stop, take-profit) to match the actual filled quantity (Module 7.2).

Order status: websocket vs polling

Two ways to learn what happened to your order: poll the REST endpoint or subscribe to the venue’s private order-update websocket. Differences:

• Polling: simple, but high-latency (you only learn about a fill on the next poll) and rate-limit-expensive at any reasonable cadence.
• Websocket: push-based, sub-second latency, doesn’t consume your REST rate budget, lets you react to fills the moment they happen (e.g., for OCO emulation).

Use websocket for order updates wherever the venue supports it. Keep polling as a fallback for reconnection scenarios and for the reconciliation pass — the websocket is for “tell me what changed,” the REST poll is for “tell me ground truth.”

What State Must Be Persisted

• Position state: in_trade (yes/no), direction (long/short), entry_price, current_stop_loss
• Strategy state: any variables the strategy needs across candles (e.g., “last exit was a slope exit” flag for trend resumption logic)
• Pending orders: order IDs, expected fills, timeout timestamps
• Last processed candle: so the system knows where to resume

Store this in an embedded SQL database or a JSON file. Update it after every state change. Read it on startup.

Concrete State Schema

Three tables are the irreducible core: orders, positions, fills. Use any embedded SQL store you like — the shape is what matters. Schemas below are vendor-agnostic.

-- orders: every order ever submitted, current and historical
CREATE TABLE orders (
    id                 INTEGER PRIMARY KEY AUTOINCREMENT,   -- monotonic local ID
    client_order_id    TEXT    NOT NULL UNIQUE,             -- deterministic; idempotency key
    strategy_id        TEXT    NOT NULL,
    symbol             TEXT    NOT NULL,
    side               TEXT    NOT NULL CHECK (side IN ('buy','sell')),
    order_type         TEXT    NOT NULL CHECK (order_type IN ('market','limit','stop','stop_limit')),
    qty                REAL    NOT NULL,
    price              REAL,                                -- NULL for market
    status             TEXT    NOT NULL CHECK (status IN
                          ('PENDING','SUBMITTED','ACK','PARTIAL_FILL',
                           'FILLED','CANCELLED','REJECTED','UNKNOWN')),
    submitted_at       INTEGER NOT NULL,                    -- epoch ms
    last_updated_at    INTEGER NOT NULL,
    exchange_order_id  TEXT,                                -- assigned by venue; NULL until ACK
    error_code         TEXT,
    error_message      TEXT
);
CREATE INDEX idx_orders_strategy_status ON orders (strategy_id, status);
CREATE INDEX idx_orders_symbol_status   ON orders (symbol, status);

-- positions: net exposure per (strategy, symbol)
CREATE TABLE positions (
    id                 INTEGER PRIMARY KEY AUTOINCREMENT,
    strategy_id        TEXT    NOT NULL,
    symbol             TEXT    NOT NULL,
    side               TEXT    NOT NULL CHECK (side IN ('long','short','flat')),
    qty                REAL    NOT NULL,
    avg_entry_price    REAL    NOT NULL,
    unrealised_pnl     REAL    NOT NULL DEFAULT 0,
    realised_pnl       REAL    NOT NULL DEFAULT 0,
    opened_at          INTEGER NOT NULL,
    closed_at          INTEGER                              -- NULL while open
);
CREATE INDEX idx_positions_strategy_symbol ON positions (strategy_id, symbol);

-- fills: every execution event the venue reports
CREATE TABLE fills (
    id                 INTEGER PRIMARY KEY AUTOINCREMENT,
    order_id           INTEGER NOT NULL REFERENCES orders(id),
    exchange_fill_id   TEXT    NOT NULL UNIQUE,             -- dedup on replays
    qty                REAL    NOT NULL,
    price              REAL    NOT NULL,
    fee                REAL    NOT NULL,
    fee_currency       TEXT    NOT NULL,
    ts                 INTEGER NOT NULL                     -- epoch ms
);
CREATE INDEX idx_fills_order ON fills (order_id);

Two design notes:

• client_order_id is UNIQUE — the database itself enforces idempotent submission. A retry that re-inserts the same intent gets a constraint violation, not a duplicate order.
• exchange_fill_id is UNIQUE in fills — a websocket replay or a polling-overlap won’t double-count a fill into your PnL.

Order Lifecycle State Machine

An order moves through a finite set of states. Every transition has a trigger, every terminal state is reached intentionally or by timeout.

Trigger and timeout rules:

• PENDING → SUBMITTED: on submit() call. Persist row before the network call so a crash after-send leaves a recoverable record.
• SUBMITTED → ACK: on the venue’s order-accepted response. Capture exchange_order_id.
• SUBMITTED → REJECTED: permanent error from venue (signature, balance, parameter). Terminal.
• SUBMITTED → UNKNOWN: no ACK within timeout (e.g. 5 seconds). Trigger reconciliation by client_order_id: query the venue, find the order’s real state, transition the row.
• ACK → PARTIAL_FILL / FILLED / CANCELLED: driven by fill events (websocket or polling).
• PARTIAL_FILL → FILLED / CANCELLED: further fills or operator cancel of remainder.
• Terminal states (FILLED, CANCELLED, REJECTED) are write-once. No further transitions.

Reconciliation Algorithm

Treat the exchange as the source of truth for state (positions, order statuses, fills). Treat your local DB as the source of truth for intent (strategy_id, signal_id, the why behind each order). Reconciliation is the periodic alignment of these two.

def reconcile(strategy_id, now):
    # 1. Pull ground truth from venue
    venue_orders    = venue.get_open_orders(strategy_filter=strategy_id)
    venue_positions = venue.get_positions(strategy_filter=strategy_id)

    # 2. Pull local view
    local_orders    = db.select_open_orders(strategy_id)
    local_positions = db.select_positions(strategy_id)

    # 3. Diff and classify each discrepancy
    diffs = []
    for vo in venue_orders:
        lo = find_by_client_id(local_orders, vo.client_order_id)
        if lo is None:
            diffs.append(("MISSING_LOCALLY", vo))         # venue has it, we don't
        elif lo.status != vo.status or lo.qty != vo.qty:
            diffs.append(("STATE_MISMATCH", lo, vo))      # statuses differ

    for lo in local_orders:
        if not any(vo.client_order_id == lo.client_order_id for vo in venue_orders):
            diffs.append(("MISSING_ON_EXCHANGE", lo))     # we have it, venue doesn't

    # Same diff for positions, comparing (symbol, side, qty).

    # 4. Apply resolution rules atomically
    with db.transaction():                                # all-or-nothing
        for d in diffs:
            kind = d[0]
            if   kind == "MISSING_LOCALLY":
                # Venue wins on existence + state; we annotate with intent if recoverable
                db.insert_order_from_venue(d[1], strategy_id=strategy_id)
                log.warning("reconcile.insert", coid=d[1].client_order_id)
            elif kind == "STATE_MISMATCH":
                # Venue wins on qty/status; local keeps strategy_id, signal_id
                db.update_order_state(d[1].id, status=d[2].status, qty=d[2].qty)
                log.warning("reconcile.update", coid=d[1].client_order_id)
            elif kind == "MISSING_ON_EXCHANGE":
                # Order is gone (filled, cancelled, expired). Mark terminal, fetch final state.
                final = venue.get_order_history(d[1].client_order_id)
                db.update_order_state(d[1].id, status=final.status)
                log.warning("reconcile.terminal", coid=d[1].client_order_id)

    return diffs

Resolution rules in one line: exchange wins on state (qty, status, fills); local wins on intent metadata (strategy_id, signal_id, the reason this order exists).

Cadence

• Slow strategies (weekly, daily): every N minutes — cheap insurance.
• Fast strategies (hourly or below): every M seconds — tighter loop, but never on every cycle (rate-limit cost; reconciliation can saturate your budget).
• On startup, always: a full reconciliation before resuming any signal evaluation. Never let the strategy take a decision against a stale local view.
• On UNKNOWN-state timeout: targeted reconciliation by client_order_id, not the full sweep.

Atomicity

All updates from a single reconciliation pass run inside one DB transaction. Either every diff is applied or none is — you never want a torn state where half the positions match and half don’t after a crash mid-loop.

YAML Configuration Example

Why This Matters

• Auditability: You can see exactly what parameters the system is running by reading one file
• Safety: Changing a threshold doesn’t risk introducing code bugs
• Multi-strategy: Each strategy gets its own config file. Adding a new strategy means adding a new YAML file.
• Version control: Config changes are tracked in git alongside code changes

The Right Way to Use AI for Code

1. Describe what you want precisely. “Write a data fetcher” is too vague. “Write a Python script that fetches BTCUSDT daily candles from a tier-1 perpetual venue’s public API starting from 2020-01-01, handles pagination with 200 candles per page, saves to a lightweight embedded SQL database file called market_data.db with columns (timestamp, open, high, low, close, volume), and runs data quality checks after each batch” is precise.
2. Review every line. AI-generated code can have subtle bugs. Read the code. Understand what it does. Ask the AI to explain any part you don’t understand.
3. Test before trusting. Run the code on a small sample. Verify the output makes sense. Check edge cases.
4. Iterate. “This works but the timestamps are in milliseconds and I need seconds.” “Add error handling for HTTP 429 rate limit responses.” Small, precise iterations produce better code than trying to get everything right in one prompt.

Recommended Tools

For building the actual production system, a CLI-based AI tool that can read your files, run your tests, and edit your code directly is dramatically more productive than copy-pasting between a chat interface and a text editor.

The Four Constraints Every Order Must Satisfy

Every symbol on every venue advertises four numerical constraints. An order that violates any of them is rejected; you don’t get a partial credit for getting three out of four right.

• Minimum quantity (minQty). The smallest size the venue will accept. Below this, your order is rejected with a “below minimum” error. Different per symbol; sometimes different across the same symbol on linear vs inverse contracts.
• Step size / lot size (stepSize). Quantity must be a multiple of this increment. If stepSize = 0.001, then 0.13427 is invalid; 0.134 is valid. Round down (never up — rounding up can push you over your risk budget).
• Tick size (tickSize). Limit-order price must be a multiple of this increment. If tickSize = 0.5, then $94,517.83 is invalid; $94,517.50 is valid. For a buy, round down (better price for you, more fillable); for a sell, round up. The exact convention varies; pick one and document it.
• Minimum notional (minNotional). The order’s value — quantity × price — must clear a venue-wide floor (often $5, $10, or similar). This is independent of minQty; an order can pass minQty and still fail minNotional if the price is low enough. Especially relevant for low-priced altcoins and for sizing-down trades during drawdowns.

Fetch these constraints from the venue’s symbol-info / instrument endpoint at startup, cache them, and refresh on a schedule. They do change — venues adjust tick size after sustained price moves and shift step size for new contract series.

Linear vs Inverse Perpetuals: The P&L Math Differs

Two perpetual contract families dominate. They look superficially similar in a venue UI but the P&L math is fundamentally different, and getting them confused will cause your sizing to be off by a factor that depends on price.

• USDT-margined (linear). Quantity is denominated in the underlying coin. Margin and P&L settle in stablecoin. P&L is linear in price: P&L = qty × (exit_price - entry_price) for a long. Long BTC at $90,000, exit at $100,000, qty 0.1 → P&L = 0.1 × $10,000 = $1,000. Simple.
• COIN-margined (inverse). Quantity is denominated in USD notional. Margin and P&L settle in the underlying coin. P&L is inverse in price: P&L (in coin) = qty_usd × (1/entry_price - 1/exit_price) for a long. Same trade, expressed as “long $9,000 of BTC at $90,000, exit at $100,000” → P&L = 9000 × (1/90000 - 1/100000) ≈ 0.01 BTC.

Two consequences operators repeatedly miss:

1. Position sizing math is different. A linear-contract sizing function passing into an inverse-contract executor will produce wrong sizes. They are not interchangeable.
2. Inverse contracts have non-linear sensitivity to price. Your COIN-margined long’s effective leverage increases as price falls (because your collateral is also falling). Liquidation behaviour and margin-call behaviour are correspondingly different. Stop placement that’s reasonable on a USDT-M contract may be too tight on COIN-M during a violent move.

The Rounding Helper

Rather than scatter rounding logic across every place that places an order, isolate it in one helper that takes intended values and returns venue-compliant ones (or raises). The contract is small and explicit:

class RoundingHelper:
    def __init__(self, symbol_info):
        self.min_qty       = symbol_info.min_qty
        self.step_size     = symbol_info.step_size
        self.tick_size     = symbol_info.tick_size
        self.min_notional  = symbol_info.min_notional
        self.contract_type = symbol_info.contract_type   # "linear" | "inverse"

    def prepare(self, intended_qty, intended_price, side):
        # 1. Round qty DOWN to step
        qty = floor(intended_qty / self.step_size) * self.step_size

        # 2. Round price to tick (down for buy, up for sell)
        if side == "buy":
            price = floor(intended_price / self.tick_size) * self.tick_size
        else:
            price = ceil(intended_price / self.tick_size) * self.tick_size

        # 3. Validate against floors
        if qty < self.min_qty:
            raise OrderTooSmall(f"qty {qty} below min {self.min_qty}")
        if qty * price < self.min_notional:
            raise OrderTooSmall(f"notional {qty*price} below min {self.min_notional}")

        return qty, price

Two non-obvious choices baked in: rounding qty down (so we never accidentally exceed our risk budget by rounding up to the next step), and raising on impossible orders rather than silently shrinking. A silent shrink-to-zero is worse than a loud rejection — the loud rejection bubbles up and your strategy can decide whether to skip the trade or alert.

Why They Have to Be Separate

Research is exploratory. You want notebooks, large historical datasets sitting on disk, a half-dozen plotting libraries, the ability to reach for a GPU when you decide to fit something heavier, and tolerance for mutable state — you re-run cells, you keep variables around, you experiment. Dependencies sprawl naturally because you don’t know in advance what you’ll need.

Production is the opposite. You want a small, deterministic, immutable container that does exactly one thing. Every dependency in production is a security and reliability surface; every megabyte of image is something that has to download and start cleanly when a host fails over. The environment must be reproducible byte-for-byte from version control. Mutable state is your enemy.

The conflict is total. A single environment that satisfies research also drags Jupyter, plotting libraries, two ML frameworks, and a CUDA stack into your live trading container — multiplying the surface area of what can break and what can be exploited, while making the container slow to start and impossible to audit.

The Shared Layer Is the Strategy Itself

The asymmetry doesn’t mean two parallel implementations — that’s the worst of both worlds. The split that works:

• Strategy logic lives in a shared package. A pure Python module with no notebook-specific dependencies, no heavy ML libraries, no I/O wired in. Inputs are arrays/DataFrames; outputs are signals/orders. Same code, byte-for-byte identical, called from research notebooks and from the production runner.
• Research environment imports the package. Notebooks call from lib.strategies.my_strategy import generate_signals exactly like the production runner does. The research environment provides the data, the exploration tools, the plotting — the strategy logic is shared.
• Production environment imports the same package. A small headless service that calls the same generate_signals function with live data and routes the output to the order executor.

If the research notebook and the production runner are calling the same function with the same arguments, their behaviour is identical by construction. Bugs you find in one are fixed in the other for free. Backtest-vs-live divergence becomes a data problem, never a code problem.

The Anti-Pattern

The single most common environment-separation failure looks like this:

# In production_runner.py, deep in the strategy module
from research.notebooks.helpers import compute_indicator

Now your production code path imports a notebook helper. Three things have just gone wrong: production now requires Jupyter to be installed; production behaviour depends on a file that lives in the “mutable, exploratory” part of your repo; and a researcher refactoring their notebook has just changed live trading behaviour without realising it. The file path is the bug.

The remedy is mechanical: the production environment cannot import anything outside lib/. Enforce it with import path discipline; if you have a build pipeline, fail the build when production code imports from research/.

Directory Structure

The simplest layout that enforces the split:

repo/
├── lib/                           # SHARED (production must only import from here)
│   ├── strategies/
│   │   └── my_strategy.py        # pure functions: data in, signals out
│   ├── indicators/
│   ├── execution/
│   └── risk/
├── research/                      # NEVER imported by production
│   ├── notebooks/
│   ├── adhoc_scripts/
│   └── data/                     # large local datasets
├── production/                    # the live runner
│   ├── runner.py                 # imports from lib/ only
│   ├── Dockerfile                # small, lean, deterministic
│   └── requirements.txt          # minimal
└── tests/
    └── strategies/                # tests run on lib/ — same code as production

The Promotion Path

The path from idea to live is the same every time, with explicit gates:

1. Notebook proves the idea. Quick-and-dirty exploration in research/. The output is a clear yes/no on whether to invest the engineering effort to formalise it.
2. Logic moves into lib/strategies/. Refactored into a pure function with explicit inputs and outputs. The notebook now imports the function and uses it; nothing strategy-relevant lives in the notebook anymore.
3. Backtest harness validates. The same generate_signals the notebook uses, the production runner will use, and the backtester uses — one code path, three call-sites.
4. Falsification & adversarial review (Module 6). Same code, attacked.
5. Paper-trade in production runner (Module 9.3). First time the strategy runs against real-time data through the production code path. Catches integration issues that backtest can’t.
6. Live, with size ramp. Module 9.4.

At every stage the strategy logic is the same shared code. The only thing changing is the data (historical vs live) and the side-effects (none in research; orders submitted in production).

Recommended: A Tier-1 European Dedicated-Server Provider

We run all production trading infrastructure on modest dedicated hardware (a few cores, ~64GB RAM) from a tier-1 European dedicated-server provider. Why this class of provider, rather than a hyperscaler:

• Cost: Dedicated servers at a small fraction of AWS/GCP/Azure pricing for equivalent specs.
• Reliability: 99.9%+ uptime in well-run European data centres with excellent connectivity.
• Performance: Dedicated CPU and RAM, not shared with other tenants.
• No surprise bills: Fixed monthly pricing, not usage-based.

For a first system, a small shared VPS is sufficient (a few vCPU, 8GB RAM, a recent Ubuntu LTS). Upgrade to dedicated hardware when you have multiple strategies running.

Initial Setup Checklist

Why Docker

• Isolation: Each container has its own Python environment. No dependency conflicts between strategies.
• Reproducibility: The container runs the same way on your laptop, on the server, and a year from now.
• Auto-restart: Docker can automatically restart your container if it crashes (restart: unless-stopped).
• Easy deployment: docker compose up -d starts everything. docker compose down stops everything.

Healthchecks, Restart Policy, and Volumes (Operational Depth)

The minimal compose above is a starting point. The version below adds the three pieces that separate a toy deployment from one you can leave running unattended: a healthcheck, a finite restart policy, and named volumes for stateful data.

# docker-compose.yml (operator-grade)
version: "3.8"
services:
  btc-strategy:
    build: .
    container_name: btc-strategy
    env_file: .env

    # Restart policy: bounded retries, not infinite crash loop
    restart: on-failure
    deploy:
      restart_policy:
        condition: on-failure
        max_attempts: 5
        window: 120s

    # Healthcheck: container is "healthy" only when /health responds 200
    healthcheck:
      test: ["CMD", "curl", "--fail", "--max-time", "5", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s   # grace window on first boot

    volumes:
      - btc_strategy_data:/app/data    # named volume; survives container recreate
      - ./config:/app/config:ro        # configs read-only into container
    ports:
      - "8080:8080"

volumes:
  btc_strategy_data:                   # declared once, persists independent of container lifecycle

Why each change matters:

• restart: on-failure with max_attempts: unless-stopped retries forever, which means a bug that crashes on boot becomes an infinite crash-loop that fills logs and masks the real issue. on-failure with a finite retry surfaces persistent failures to your alerting instead of hiding them under restart spam.
• healthcheck:: Docker now knows the difference between “process is running” and “process is operational.” Your watchdog (Module 9.5) and any orchestrator can read the health status; without it, a hung-but-not-crashed process looks healthy from the outside.
• Named volumes: a bind-mount (./data:/app/data) ties your state to a path on the host, which is fine until you move servers or recreate the container with a different working directory. A named volume (btc_strategy_data) is owned by Docker, lives independently of the container, and survives docker compose down. For stateful containers (your trading bot’s local SQL DB lives here) this is the safer default.
• Read-only configs: mounting ./config as :ro means a misbehaving container cannot write to your strategy YAMLs.

The application must expose the /health endpoint the healthcheck calls (covered in Module 9.5). Without it, the healthcheck can’t do its job.

Why Paper Trading Matters

• Catches bugs that backtesting misses: Timezone issues, API edge cases, state management bugs, order handling errors
• Verifies infrastructure: Does the cron job fire? Does the bot restart after a crash? Do your instant-messaging alerts work?
• Builds confidence: Watching the system make correct decisions in real time, with real data, for weeks, before committing capital
• Validates live performance vs backtest: Are the signals matching what the backtest predicted? If live paper results diverge significantly from backtest expectations, something is wrong.

How Long to Paper Trade

Minimum: 2–4 weeks. Longer for low-frequency strategies. You need enough time to observe:

• At least 2–3 signal events (entries and exits)
• At least one server restart or maintenance window
• At least one period of high volatility (to test error handling)

For a weekly strategy that trades 3 times per year, you might need 2–3 months to see a full signal cycle. For a daily strategy, 2 weeks may suffice.

Fill-Simulation Spec (Why “Just Run It” Isn’t Enough)

Without an explicit fill-simulation spec, paper P&L cannot be compared to live P&L — you don’t know whether divergence is “the strategy decayed” or “the simulator was optimistic.” The spec below is the minimum operator-grade contract for what paper fills mean.

Entry fills

• Market entry: fill at the next candle’s open price, plus a slippage adjustment in the adverse direction (long entries fill above open, short entries below). Open-of-next-candle is the conservative baseline; never fill at the signal-bar close (look-ahead).
• Limit entry: fill only if the next-bar low (for buy limits) reaches the limit price, or the next-bar high (for sell limits) reaches it. Fill at the limit price exactly (no improvement).
• Alternative entry models (declare which is in use, do not mix):
  • VWAP within candle: fill at the candle’s typical price (HLC/3 or volume-weighted) — less conservative; only valid when the strategy claims to use TWAP/VWAP execution in live.
  • Mid + slippage model: fill at mid + slippage_bps in the adverse direction, where the slippage model is parametric or empirical (see below).

Stop exits

• Trigger condition: for a long stop, the candle’s low reaches or breaches the stop price; for a short stop, the candle’s high reaches or breaches it.
• Fill price (intra-bar): fill at the stop price, plus a worst-case slippage of K basis points beyond the stop in the adverse direction. Default K conservatively (e.g. 5–10bp on liquid majors, more on alts).
• Gap-through-stop: if the candle’s open already breaches the stop (i.e. the bar gapped through the stop level), simulate as filled at the next-bar open, not at the stop price. This models genuine gap risk — on a major news gap, you do not get the stop price; you get whatever’s available when the market re-prices.

Target / take-profit exits

• Trigger: for a long target, the candle’s high reaches the target; for a short, the candle’s low.
• Fill price: fill at the target price exactly (no positive slippage on resting limits in conservative simulation).
• Both stop and target hit in the same bar: ambiguous — the candle gives high and low but not order. Pick a deterministic rule (we recommend: assume the stop hit first, the conservative outcome) and document it. Never assume target-first; that’s a known overfit lever.

Slippage model

State which model is in use and why:

• Parametric (constant bp): simplest; one number per asset. Fine for liquid majors at retail size. Calibrate from observed live fills if available.
• Depth-based: use L2 order-book snapshots to compute the impact of your size against the resting depth. More accurate at scale; requires storing book data.
• Empirical: fit a slippage distribution from your own historical live fills (price you got vs price you intended) and sample from it. Only available once you have live fills to calibrate against.

Funding accrual (perpetuals)

For each funding tick (typically every 8h, sometimes 1h or 4h depending on venue) the position is open, accrue funding using the actual historical funding rate for that interval:

funding_payment = position_notional * funding_rate * sign
# sign: longs pay when funding is positive; shorts pay when funding is negative
position.realised_pnl += -funding_payment

Carry funding through the trade’s PnL accounting, not as a separate ledger — otherwise paper PnL looks rosier than live PnL on funding-heavy markets.

Fee model

• Default to taker fee for both entry and exit in conservative paper simulation. Most market entries and stop-triggered exits are taker.
• If your strategy explicitly rests as maker, model maker fee (or rebate) on those legs — but require live evidence that your maker fills are actually filling at maker rates before you trust paper PnL that assumes them.
• Apply fees to both legs (open and close) and include them in the same PnL ledger as funding.

The Go-Live Checklist

Essential Alerts

Health Watchdog

A separate script (not part of the trading bot) that runs on a cron schedule and checks:

• Are all trading containers running? (docker ps)
• Has the candle update cron fired recently? (check file modification time)
• Are there any stale positions (open for longer than expected)?
• Is disk space running low?
• Are there error patterns in container logs?

If any check fails, send an instant-messaging alert. This is your insurance against the 3am crash you sleep through.

Health and Readiness Endpoints

Every container exposes two HTTP endpoints. The distinction matters: a container can be alive without being operational.

• /health — process is alive. Returns 200 if the HTTP server is responding. Used by Docker healthcheck and the watchdog’s liveness probe.
• /ready — process is operational. Returns 200 only if: data is fresh (latest candle younger than 2 candle intervals), DB is reachable, last reconciliation succeeded, no fatal-error flag is set. Used by the watchdog’s readiness probe.

@app.get("/health")
def health():
    return {"status": "alive", "ts": now_ms()}, 200

@app.get("/ready")
def ready():
    checks = {
        "data_fresh":   latest_candle_age_seconds() < 2 * candle_interval_seconds(),
        "db_reachable": db_ping(),
        "reconcile_ok": last_reconcile_age_seconds() < max_reconcile_age,
        "no_fatal":     not fatal_flag.is_set(),
    }
    if all(checks.values()):
        return {"status": "ready", "checks": checks}, 200
    return {"status": "not_ready", "checks": checks}, 503

An always-200 /health is a lie if the bot is hung, blocked on a deadlock, or has lost its data feed. /ready is what tells you whether to trust the system right now.

Watchdog Checklist (Concrete Commands)

The watchdog is a separate process — usually a cron-driven shell or Python script — that exercises the system from the outside. The minimum check set:

# 1. Liveness: each container responds to /health
for container in $TRADING_CONTAINERS; do
  curl --fail --max-time 5 "http://${container}:${PORT}/health" \
    || alert "container ${container} not alive"
done

# 2. Readiness: each container reports operational
for container in $TRADING_CONTAINERS; do
  curl --fail --max-time 5 "http://${container}:${PORT}/ready" \
    || alert "container ${container} not ready"
done

# 3. Data freshness (sanity check, even if /ready already covers it)
latest_ts=$(query_db "SELECT MAX(ts) FROM candles WHERE symbol=$SYMBOL")
age=$((NOW - latest_ts))
[ "$age" -gt "$((2 * INTERVAL))" ] && alert "candles stale: ${age}s old"

# 4. Position reconciliation: exchange == local for every (strategy, symbol)
diffs=$(reconcile_dry_run --all-strategies)
[ -n "$diffs" ] && alert "reconcile diffs: ${diffs}"

# 5. Heartbeat-to-monitor: container writes last_loop_at to a status file
for container in $TRADING_CONTAINERS; do
  last=$(stat -c %Y "/var/run/${container}.heartbeat")
  age=$((NOW - last))
  [ "$age" -gt "$HEARTBEAT_THRESHOLD" ] && alert "${container} heartbeat stale: ${age}s"
done

# 6. Disk and log volume
df -h | awk '$5 ~ /9[0-9]%|100%/ { print }' | grep . && alert "disk pressure"

Run the watchdog from a process that cannot share a failure mode with the trading containers: a different host where practical, or at minimum a separate systemd unit on the same host. If your watchdog dies with your bot, you have no watchdog.

Log Shipping and Retention

• Structured JSON logs — every log line is a parseable object with fields (ts, level, strategy, event, coid, etc.). Free-text logs are unsearchable at the volume a live system produces.
• Ship to a central collector — not because you need a fancy stack, but because logs on the same host as the failing container are often unreachable when you most need them. A simple syslog forward, a journald forward, or a lightweight log-shipper agent is enough.
• Retention: hot retention (instantly searchable) at least 7–14 days covers most incident windows; cold retention (compressed archive) 3–12 months for post-mortem and regulatory needs.
• Redact secrets at the source, never at the collector — if a key ends up in your central log store you have to rotate the key.

SLOs and Metric Thresholds

Pick a few measurable targets and alert when reality breaches them. Examples calibrated for a daily/intraday system at retail size:

Numbers are illustrative — calibrate to your strategy’s timescale. The point is to have numbers, not to invent them ad hoc when something breaks.

Alert Routing

Not every alert deserves to interrupt you. Tier alerts by required action:

• Chat / push (high-urgency, action-required): container crash, reconciliation hard-fail, account drawdown breach, exchange API blackout, fatal-error flag set. Wakes you up. Has a human-readable runbook link.
• Email / dashboard (informational, review-during-business-hours): trade entries/exits, daily PnL roll-up, weekly performance vs backtest, normal cron completion.
• Suppress / aggregate: repeated identical alerts within a window collapse to one. The 47th “rate-limit hit” tells you nothing the first did not.

Alert fatigue is a real failure mode. If every notification is “urgent,” the genuinely urgent ones get muted with the rest. Be ruthless about what gets to interrupt sleep.

Runbook Entries (Per-Alert)

For every alert your system can fire, write a runbook entry. Four lines, not a novel:

1. What it means. “Reconciliation found a position on exchange that local DB doesn’t know about.”
2. How to verify. “SSH to host; docker exec ... reconcile --dry-run; check the diff output.”
3. How to fix. “If the venue position is intentional (manual hedge), insert a row tagged manual in positions. If unintentional, close it via venue UI and re-run reconcile.”
4. How to prevent recurrence. “If this fires more than once a week: investigate the venue order-update stream for dropped messages.”

Runbooks live in version control next to the code, not in someone’s head. The point of writing them is the next 3am page is handled by reading, not thinking.

State DB Backups: Continuous and Periodic

The trading system’s state DB — orders, positions, fills, strategy state — is the only piece of local data that, if lost, cannot be reconstructed in minutes. Candle history can be re-fetched. The DB cannot. Two layers of backup, both required:

• Continuous WAL streaming. Most production-grade SQL databases support write-ahead-log streaming to a remote target. Every committed transaction is shipped, asynchronously, to a backup endpoint. Recovery point objective approaches zero — in the worst case you lose only the transactions in flight when the primary died.
• Periodic full snapshots. Daily or weekly, take a consistent snapshot of the entire DB and ship it offsite, encrypted at rest. Snapshots cover failure modes WAL streaming cannot — logical corruption, accidental schema changes, an attacker silently overwriting WAL too — and they give you a known-good restore point with a known timestamp.

Encryption is non-negotiable: the backup contains your full trading history and any secrets your DB persisted. Treat it as you would the live DB.

Infrastructure as Code: Rebuild From Git

If the box dies right now, how long until you have a replacement running? The honest answer for most retail operators is “hours, while I remember how I set it up.” The target answer is “under 30 minutes, from a script.”

Every server in the system should be rebuildable from a git repository. The minimum content of that repo:

• A provisioning script (Ansible, Terraform, a shell script — the form matters less than the existence) that installs the OS-level dependencies, configures firewalls, sets up the user, and pulls the application repo.
• A docker-compose.yml (or equivalent) that brings up the trading containers, the watchdog, the log shipper, the DB.
• A documented secrets-injection process — the secrets themselves do not live in git, but the procedure to fetch them from your secret store does.
• A RECOVERY.md at the repo root with the literal commands, in order, to bring up a new host from cold metal to live trading.

If you can’t hand the repo to a competent engineer who has never seen it and have them bring up a working replica in under an hour, the IaC isn’t complete.

Blue/Green Deployment

Deploying a new version of the trading bot directly over the running version is a needless risk. The blue/green pattern:

• Run the new version (green) alongside the old (blue). Both connect to the same DB and the same venue, but only one of them is the “active” instance permitted to place orders. The other runs in shadow mode, evaluating signals against the same data and writing them to a parallel log.
• Switch traffic by flipping a single config flag. The active flag is read by both containers; whichever sees active = true places orders. Switch from blue to green; observe; if anything looks wrong, flip back.
• Keep blue around for 24–72 hours. An instant rollback is just a config flag flip. After the watch window expires, decommission blue.

Many failure modes — a subtle indicator change, a new bug introduced by a refactor, a venue API behaviour you didn’t notice — only manifest under live data. Blue/green lets you catch them with a five-second rollback rather than a forty-minute redeploy.

Region and Provider Failover

Your provider can have an outage. Whole datacentres lose power. Networks partition. The defence isn’t complex multi-region orchestration on day one — it’s a documented runbook plus a cold standby:

• Cold standby on a different provider. A second host, on a different provider in a different region, with the IaC repo cloned and the DB backups synced. It is not running — you pay only for the disk and the small instance fee. Activation is a script: pull latest backup, restore DB, bring up containers, point DNS / API alerts at the new host.
• Activation runbook in version control. Step-by-step. Time-it under non-emergency conditions: from “decide to fail over” to “new host taking trades,” the target is under 30 minutes. The first time you measure it, it will be longer; iterate the runbook until it isn’t.
• Test the failover quarterly. Same logic as backup restore drills: an untested failover is a hope. The drill is “bring up the standby on cold backup, run paper trading on it for an hour, decommission.”

The Catastrophic-Loss Runbook

The worst case: local DB is corrupted, latest backup is also corrupted, infra is intact but state is gone. You don’t know what you own.

The recovery is structural: the venue is the source of truth for fills, orders, and positions. Every fill that ever happened was recorded by the venue; every open position has a record there. The reconcile-from-venue procedure:

1. Halt all strategies. No new orders until reconciliation completes.
2. Pull full history from the venue. All fills, all closed orders, all open orders, all positions, going back as far as the venue’s API exposes (usually 90 days for fills; longer with paginated requests; full account-statement export for older history).
3. Rebuild local state from venue history. Reconstruct positions by replaying fills; reconstruct strategy attribution from your clientOrderId tags — this is why the clientOrderId discipline in Module 8 is non-negotiable. Without strategy tags in the order id, you cannot tell which strategy owns which position.
4. Reconcile against current open state. The replayed positions should match what the venue currently reports. If they don’t, there’s a fill you missed — investigate before resuming.
5. Resume strategies one at a time, with size reduced, watching for any abnormal behaviour.

This procedure is slow and tedious. The point isn’t that it’s elegant; the point is that it exists, it’s documented, and you have rehearsed it once. The day you need it is not the day to discover that fill history beyond 30 days isn’t available on the venue’s standard API.

The 3-2-1 Rule

The simplest discipline that covers almost every backup failure mode: 3 copies, 2 different media, 1 offsite.

• 3 copies: the live DB, plus two independent backups. One of the backups can be derived from the other (e.g. WAL stream archived to disk, then disk snapshot to object storage).
• 2 different media / providers: not just “two folders on the same disk.” A provider-managed object store and a local NAS, or two different cloud providers. The point is that one ransomware/corruption/policy event cannot take both.
• 1 offsite: at least one copy is in a different physical location and a different ownership domain (different cloud provider, different region). A flooded datacentre or a billing-suspension at your primary provider should not be the end of your data.

Retail systems often run with 1 copy and call it “a backup.” That’s not a backup; that’s a single point of failure with extra steps.

The Regime Problem

Markets exist in distinct regimes. Each regime has different statistical properties:

The Most Expensive Mistake

Running a trend-following strategy during chop is the most common and most expensive regime mismatch. The system enters on a “breakout,” the breakout fails, the system exits at a loss, enters again on the next “breakout,” that fails too. Each trade loses fees + slippage. After 10 whipsaw trades, you’ve lost 5–10% of your account with zero market exposure. This is called death by a thousand cuts.

The solution: don’t trade in regimes where your strategy has no edge. This is what regime gates are for.

Simple Regime Classification

The pattern below uses a slow weekly moving-average slope (direction) crossed with a volatility or efficiency measure (character of motion). Pick your own indicators — the structure is what matters:

This is not sophisticated. It does not need to be. The goal is to prevent your trend strategy from trading during chop and your short strategy from trading during bull markets. Broad strokes are enough.

Advanced: External Regime Signals

For more nuanced detection, add external data:

• Fear & Greed Index: Extreme fear (<20) often precedes reversals. Extreme greed (>80) often precedes corrections.
• Funding rates: Deeply positive = crowded longs (bullish sentiment). Deeply negative = crowded shorts (bearish sentiment). Extremes tend to revert.
• VIX (if trading correlated assets): VIX >30 signals high fear in traditional markets, which often spills into crypto.
• DXY (US Dollar Index): Strong dollar typically pressures BTC. Weak dollar typically supports BTC.

These are filters, not signals. They don’t tell you what to trade. They tell you whether conditions are favourable for your strategy type.

Key Macro Indicators for Crypto

You do not need to trade these instruments. You just need to read them as context for your crypto strategies. “DXY just spiked 2% and VIX is above 30” is important context when your BTC strategy wants to go long.

The Pattern

From a calendar-effect investigation (a deliberate test of a weak claim, used here as an example of how filters change a verdict):

• The headline signal across all conditions: barely positive average return — effectively flat.
• Filtered to low volatility only: strongly positive average return.
• Filtered to medium volatility: negative — the signal flips sign with the regime.

From a derivatives-driven contrarian signal we tested:

• All conditions: hit rate above 60%.
• Filtered to low volatility only: hit rate well above 80% (small sample, but striking).

The same pattern appears in trend following, mean reversion, and derivatives signals. Low-volatility environments compress ranges, reduce noise, and make genuine signals cleaner. High-volatility environments are full of noise that triggers false signals.

What to Track

Some deviation is expected — live trading will never perfectly match backtesting due to slippage variance, execution timing, and market microstructure differences. The question is whether the deviation is within the range your Monte Carlo simulations predicted.

The Review Cadence

• Daily: Check that the system is running (watchdog alerts handle this)
• Weekly: Review any trades from the past week. Do the entries and exits make sense?
• Monthly: Compare cumulative live performance to backtest expectations. Check all metrics in the table above.
• Quarterly: Full strategy review. Is the edge still intact? Has the market regime changed? Should position sizing be adjusted?

Statistical Methods for Degradation Detection

• Bootstrap confidence intervals on rolling metrics. Take the long-run trade list (backtest + live), bootstrap a distribution of N-trade-window Sharpe (or PF, or mean P&L) under the assumption that the strategy is unchanged. If the recent N-trade window’s metric falls outside the 95% CI of that long-run distribution, that is statistical evidence of drift. This is the most general method and works whether N is 10 or 200.
• CUSUM (cumulative sum) tests. Track the cumulative sum of (actual P&L − expected P&L) trade by trade. Under the null of “strategy unchanged” the CUSUM is a random walk around zero; under degradation it drifts persistently below zero. Trigger when the CUSUM crosses a control limit calibrated to a target false-alarm rate. CUSUM is the textbook tool for detecting persistent small shifts that a noisy rolling-mean would miss.
• Bayesian posterior updating. Maintain a posterior distribution on the strategy’s key performance parameters — e.g. a Beta posterior on win rate, a Normal-Inverse-Gamma posterior on per-trade returns. Update with each new trade. Flag when the posterior mean shifts materially relative to the backtest prior, or when the posterior probability that the true edge is positive drops below a threshold (e.g. 80%). This naturally weights recent data without you having to choose a window length.
• GLR (Generalized Likelihood Ratio) change-point tests. Formal change-point detection: at each new trade, compute the likelihood ratio of “the return distribution changed at some point in the recent past” vs “the distribution is unchanged.” Trigger when the ratio crosses a threshold. The most rigorous of the four; also the most computationally involved. Worth the cost on flagship strategies.

Pick one or two and commit to them in the strategy’s monitoring spec. The choice matters less than the discipline of applying it.

Cross-Instrument Sanity Check (When Stats Are Too Thin)

For low-frequency strategies where even bootstrap CIs are unreliable, fall back to a structural sanity check: does the strategy still produce signals on instruments where it should, and do those signals still correlate with the things they used to correlate with? If you have a funding-rate-extreme reversal strategy and funding extremes still occur but no longer mean-revert, that is degradation evidence even without any new live trades. If the strategy is signal-silent on instruments it used to fire on, the underlying condition is gone.

This is qualitative but it bridges the gap when the trade count is too thin to support a formal test.

Surface-Level Symptoms (Use as Triggers, Not Decisions)

• Rolling win rate declining below backtest average and trending downward
• Profit factor below 1.0 over recent trades
• Increasing whipsaw frequency (entering and exiting rapidly without capturing moves)
• Drawdown exceeding bootstrap 95th percentile from Module 5.3
• Trade frequency change — significantly more or fewer signals than expected

Each of these is a flag to investigate, not a verdict. Run the statistical tests above before acting.

What to Do When Degradation Is Confirmed

1. Reduce position size immediately. Don’t wait for full diagnosis — cut risk first, investigate after.
2. Check the market regime. Is the strategy running in a regime it wasn’t designed for? If so, the fix might be a tighter regime gate, not a strategy change.
3. Re-run the backtest with recent data included. Does the strategy still work historically? If adding recent data destroys the edge, the market structure has shifted.
4. If degradation persists: suspend the strategy. Paper trade it for another cycle to see if the edge returns. Do not throw good money after bad.

The Research Pipeline

What the Scanner Looks For

The scanner is a battery of statistical tests run on a fixed schedule against the operator’s instrument universe. The test categories cover:

• Cross-asset relationships: Do two instruments move together in unusual ways? Does one lead another with a time delay?
• Temporal effects: Are returns at specific hours, days, or other calendar windows consistently different from random?
• Regime-conditional patterns: Does a pattern only appear in bull markets, or only in high-volatility environments?
• Feature interactions: Do combinations of indicators predict returns better than the same indicators do individually?

A typical scan produces a long list of raw findings. After filtering and LLM-assisted evaluation, a smaller subset becomes new hypotheses. Most will fail validation. Some will survive. The ones that survive become candidates for the paper-trading pipeline.

The Human Gate

No strategy goes live without human approval. The system scans, evaluates, registers, and paper-trades on its own. The decision to allocate real capital is a separate, manual step. The reason is structural, not philosophical: paper-trading parity is never perfect, and the cost of a mis-approved live deployment is much higher than the cost of a slow approval queue.

How It Works

You discover that BTC shows a mean-reversion pattern after extreme funding rate readings. Instead of only trading BTC with this signal, test it on ETH, SOL, and every other perpetual futures instrument in your data. If the pattern persists across 5+ instruments, the underlying mechanism (crowded positioning creates mechanical pressure) is likely real. If it only works on BTC, it might be BTC-specific or overfitted.

Cross-Asset Discovery

Even more powerful: test signals across asset classes entirely.

• Does a signal from the FX market predict crypto behaviour? (DXY strength → BTC weakness)
• Does a signal from equity indices predict crypto behaviour? (S&P fear → BTC sell-off)
• Does a pattern in gold appear in BTC? (Both are “alternative store of value” assets)

Our research environment maintains an instrument universe spanning crypto, FX, commodities, and indices. Every finding is automatically tested across all of them. This cross-pollination is where the most surprising and robust edges are found — because an edge that works across multiple markets is much harder to explain away as noise.

The Cost of Treating Tax as an Afterthought

The pattern shows up regularly: an operator runs a high-frequency strategy for a year, makes money, and arrives at tax season with a screenshot of the venue’s P&L tab and the assumption that it will suffice. It will not. The venue’s P&L tab is not a tax record — it’s a marketing surface. It typically excludes funding payments, bundles fees in ways your jurisdiction may not accept, doesn’t track per-lot cost basis, and goes back only as far as the venue feels like keeping it. The accountant asks for the data the tax authority will ask for, you don’t have it, and the cost is either an estimated assessment (almost always against you) or a forensic reconstruction project that costs more than the year’s profits.

The defence is structural and cheap if done early: the records you need at tax time are exactly the records the trading system already produces. You just have to make sure they’re saved, exportable, and reconcilable. That’s a one-time engineering cost that pays itself back the first time you produce a clean tax export in an hour rather than a panic-week.

What Differs by Instrument, Jurisdiction, and Structure

• Instrument. Spot crypto, perpetual futures, dated futures, options, and stablecoin transfers each have distinct treatment in most jurisdictions. Capital gains vs ordinary income vs mark-to-market vs trading-stock all turn on what the instrument is and what your activity pattern looks like.
• Jurisdiction. Cost basis methods, holding-period rules, treatment of perps, treatment of staking and DeFi, GST/VAT applicability, and what counts as a “disposal” vary materially. Two operators in the same trade pay different tax in different jurisdictions; the trade was the same.
• Structure. Trading as an individual, through a discretionary trust, in a company, or inside a self-managed retirement vehicle each give you different rates, different deductibility, different reporting, and different paperwork. The choice is partly about tax and partly about asset protection and estate planning.

The Four Methods

• FIFO (First-In, First-Out). The oldest acquired lot is the first sold. Default in most jurisdictions; simplest to compute; produces the largest gain in a rising market (because the oldest lots have the lowest cost basis).
• LIFO (Last-In, First-Out). The most recently acquired lot is the first sold. Some jurisdictions allow it; others prohibit it. Produces a smaller gain in a rising market — useful for tax deferral but not legal everywhere.
• Specific identification. You explicitly identify which lot is sold per disposal. Most flexible: you can choose to realise gains or harvest losses. Requires per-lot tracking with timestamps and quantities. Often the best method for active traders, where allowed.
• Average cost. The cost basis of all units of an asset is averaged into a single per-unit number; each disposal uses that average. Common for long-term holders, rare for active traders — loses precision and is often not optimal for tax outcomes.

FIFO Accumulator Pseudocode

The simplest production-grade implementation is a per-symbol FIFO queue of lots. Each lot stores (qty, price, timestamp); on a disposal, lots are popped from the front until the disposal qty is satisfied:

class FifoCostBasis:
    def __init__(self):
        self.lots = defaultdict(deque)   # symbol -> deque of (qty, price, ts)

    def add_acquisition(self, symbol, qty, price, ts):
        self.lots[symbol].append((qty, price, ts))

    def realise_disposal(self, symbol, qty, price, ts):
        remaining = qty
        realised  = 0.0
        consumed  = []
        while remaining > 0 and self.lots[symbol]:
            lot_qty, lot_price, lot_ts = self.lots[symbol][0]
            take = min(lot_qty, remaining)
            realised  += take * (price - lot_price)
            consumed.append((take, lot_price, lot_ts, price, ts))
            remaining -= take
            if take < lot_qty:
                self.lots[symbol][0] = (lot_qty - take, lot_price, lot_ts)
            else:
                self.lots[symbol].popleft()
        if remaining > 0:
            raise InsufficientLots(symbol, qty, qty - remaining)
        return realised, consumed   # consumed is your per-lot tax record

The consumed list is the row-level tax record: each entry is one (proceed, cost basis, hold-period) tuple, which is exactly what a tax preparer needs. Persist it.

Spot

In most jurisdictions, spot crypto disposal is a capital gains event: you compute (proceed − cost basis) at the moment of sale. Holding period often matters — many jurisdictions distinguish short-term (taxed as ordinary income) from long-term (lower rate). What counts as a “disposal” is broader than people expect: selling crypto for fiat is obvious; swapping one crypto for another is also a disposal in most jurisdictions, as is using crypto to pay a fee. Spending it counts. Lending it sometimes counts.

Perps and Futures

Perpetual futures and dated futures are often treated as a separate asset class, frequently with mark-to-market treatment: at year-end, every open position’s unrealised P&L is treated as if realised, taxed in that year, and the cost basis is reset for the next year. Two operator-relevant consequences:

• You can owe tax on positions you haven’t closed. A long that was up at year-end and reverses in January generates a tax bill you have to fund from cash on hand, not from the position.
• Wash-sale rules and carry-back/carry-forward rules differ from spot. Losses that would offset gains in spot may behave differently for derivatives. This is jurisdiction-specific; ask the specialist.

Funding Payments

On perpetuals, you receive or pay funding at each interval. Treatment varies: some jurisdictions treat it as ordinary income / expense at each tick; others bundle it into the position’s P&L. The system needs to record every funding event regardless — treatment decisions belong to the tax preparer.

Fees and Stablecoin Transfers

• Trading fees are typically deductible against gains as a cost of acquisition or disposal — track them per fill, not just as a monthly aggregate.
• Stablecoin transfers between exchanges are usually not a disposal — same asset, different wallet. But timestamps, quantities, and on-chain hashes must reconcile, or the transfer can be flagged as an unaccounted disposal-and-acquisition pair.
• Stablecoin-to-stablecoin swaps (USDT to USDC) are usually disposals, even though the value is stable, because they are different assets in tax terms.

The Minimum Record Set

• Every fill. Timestamp (UTC, to the second or better), symbol, side, quantity, price, fee, fee asset, the venue’s fill_id, your clientOrderId, the strategy that owned it.
• Every funding payment. Timestamp, symbol, position direction, quantity, funding rate, payment in stablecoin (or coin, for inverse contracts).
• Every deposit and withdrawal. Timestamp, asset, quantity, source/destination address, on-chain transaction hash where applicable, network used. The on-chain hash is what reconciles your records to the blockchain if the venue or your records ever come into question.
• Every fiat ramp transaction. Bank transfer in or out, date, amount, currency, crypto purchased or sold, the rate used, the fees charged. Banks ask for this; tax authorities ask for this; you cannot reconstruct it after the fact.
• Every transfer between your own wallets/venues. Same data as a deposit/withdrawal. These should not be taxable disposals, but they have to be visible in the audit trail or they look like undocumented disposals.

Immutability and Backups

Tax records are an append-only log. Once written, never edited — if a fill needs correcting, write a correcting entry, don’t mutate the original. The same backup discipline from Module 9.6 applies: continuous WAL streaming plus periodic encrypted snapshots, with at least one offsite copy. Tax records are also subject to retention requirements — many jurisdictions require 5–7 years of immutable history; some longer.

The tax_export View

Build a database view (or materialised table refreshed nightly) that joins fills, funding payments, deposits, withdrawals, and fiat ramps into one chronological event stream. Columns at minimum:

timestamp_utc | event_type | venue | symbol | side | qty | price |
fee | fee_asset | counterparty_id | tx_hash | strategy | notes

Where event_type is one of fill, funding, deposit, withdrawal, fiat_in, fiat_out, transfer. The output is one append-only stream, sortable by timestamp, with every event in your trading history. From this view, any required tax report — capital gains schedule, income summary, fee deduction list — is a query.

Annual Exports

• CSV is the lingua franca. Whatever else you do, the year-end deliverable is a CSV your accountant can open in their tooling. One file per event_type, or one master file with the type column — preferences vary.
• Parquet for archive. CSV is fine for handoff but loses type fidelity at scale. Keep a Parquet copy of every annual export; it preserves dtypes, compresses well, and is portable across tools.
• Generate the export deterministically. The same query against the same data must produce the same output every time. If your accountant comes back with a question in March, you should be able to regenerate the exact file you sent them in January.

The Reconciliation Gate

Before sending the export to your accountant, run a reconciliation:

1. Sum realised P&L from your records — total proceeds minus total cost basis from disposals, plus funding income/expense, minus fees.
2. Compare to the venue’s reported P&L for the same period. Some discrepancy is normal (the venue may bundle fees differently); large discrepancy is a flag.
3. Compare to your own banking — total cash in minus total cash out plus current account value should approximate (cumulative realised P&L − tax paid). It will not match exactly because of unrealised P&L, but it should not be wildly off.
4. If the numbers don’t reconcile, you have incomplete records. Find the gap before tax season, not during it.

The Common Options

• Individual. Simplest. No setup cost. Trade in your own name; report on your personal return. Full marginal-rate exposure, which becomes painful at higher income brackets. Limited asset protection — a personal lawsuit can reach the trading account.
• Discretionary trust. Income earned by the trust can be distributed to beneficiaries (yourself, spouse, adult children, sometimes a corporate beneficiary) at the trustee’s discretion each year. This permits income-splitting where the lower-income beneficiary pays at a lower marginal rate. Common in jurisdictions that allow it; not all do. Setup cost is non-trivial; ongoing administration (separate accounts, separate returns, trustee resolutions) requires a competent accountant. Asset protection is meaningful in many jurisdictions.
• Trading company. A separate corporate entity that trades and pays corporate tax on its profits. The corporate rate is often materially below the top personal marginal rate, so retained profits compound at a higher effective rate. The catch: most jurisdictions require you to demonstrate you are “carrying on a business” (regular activity, profit motive, business-like records) rather than passive investing — passive investment in a company is often treated punitively. Asset protection is strong; setup and ongoing compliance costs are higher.
• Self-managed retirement vehicle. Long-horizon strategies inside a tax-advantaged retirement wrapper (the form varies by jurisdiction — SMSF, IRA, SIPP, etc.) can compound tax-deferred or tax-free for decades. Restrictions are heavy: contribution limits, rules on what you can invest in, prohibition on personal use, age-locked withdrawals. Best suited to slow, low-turnover strategies with clear tax advantages, not to high-frequency trading.

The Bar

You’re ready when, asked at any point in the year, you can:

• Produce a year’s P&L in a vendor-neutral format your accountant can use, in under an hour.
• Articulate your jurisdiction’s treatment of perps vs spot, including whether perps are mark-to-market and what that means for your January cashflow.
• Point to a written cost-basis method you have applied consistently across all symbols and all years.
• Reconcile your own records against the venue’s — not because the venue is the source of truth, but because a discrepancy is a signal.
• Show that you do not rely on any venue’s tax-export tool as your primary record.
• Name your tax specialist and confirm they have explicit experience with crypto derivatives in your jurisdiction.

What the Drawdown Reveals

Up until the drawdown, “systematic” is just a posture. You backtest, you specify rules, you write a falsification suite, you put it on a server. The system makes money for a while. You feel virtuous. You haven’t been tested yet.

The test is the drawdown. The system is doing exactly what it was specified to do. The Monte Carlo distribution from Module 5.3 said this drawdown was within the 95% confidence band. The market is not broken; the strategy is not broken; the only question is whether you stay out of the way while the system finishes the recovery curve it was built to walk.

Most people don’t. They override. They “just close this one position because it doesn’t look right.” They “reduce exposure until things calm down.” They “temporarily turn off the strategy and watch.” Each of these is the moment the operator stopped being systematic. The drawdown didn’t cost them money — it was already costing them money on paper, and would have recovered. The override cost them the system itself.

The Bar

You either trust your validated system more than your in-the-moment gut, or you don’t. There is no honourable middle position; the “hybrid” trap (Module 1.1) is the same trap dressed up. The drawdown is where you find out which side you’re actually on.

If the answer is “I don’t trust it,” the right move is not to override during a drawdown. The right move is to kill the strategy when it’s not in drawdown, with a clear head, and rebuild whatever was missing in your validation. Override-during-drawdown is the worst-case version of every decision; it is made under stress, with the loudest emotional input and the least information.

The Three Modes

• Engineering override. You discovered a real bug. The system is doing something it was not specified to do — a stop-loss isn’t firing, an indicator is computed on stale data, a strategy is duplicating positions. You halt to investigate and fix. This is legitimate, and the work is to define ahead of time what counts as “a real bug.” The lazy version — “the system did something I didn’t expect” — reclassifies any unwelcome valid behaviour as a bug. The disciplined version requires an objective discrepancy between specification and behaviour, demonstrated in code or logs, before you halt.
• Risk override. Exposure has materially exceeded your risk budget — usually because correlated positions moved together more than the model assumed, or because a venue produced an unexpected fill. You cap exposure to bring it back inside the budget. This is legitimate only if the rule is pre-declared (“if portfolio gross exposure exceeds X% of equity, halve the largest position”) and applied mechanically. A “risk override” that’s improvised on the day is just an emotional override wearing a risk-management costume.
• Emotional override. You don’t like the P&L. The position scares you. The drawdown is uncomfortable. The strategy hasn’t fired in weeks and you’re bored. None of these are legitimate reasons to touch the system. The whole point of building a systematic operation is to insulate execution from the operator’s in-the-moment emotional state — if the operator’s emotional state can override the system, the system isn’t systematic.

The Override Log

The discipline that makes this real: every manual override goes in a log, with a written reason, a timestamp, and a classification. Three columns plus a free-text reason field:

timestamp_utc | classification        | action                   | reason
2026-04-12T14:33Z | Engineering         | halted strategy_X        | stop-loss didn't fire on fill at 14:31; logs show ...
2026-04-15T09:01Z | Risk                | reduced position to 50%  | gross exposure 142% of budget after correlated fills
2026-04-22T22:18Z | Emotional (logged)  | none taken               | wanted to close but recognised this is emotional

The third row is the most important kind of entry. Logging an emotional impulse you did not act on trains the muscle of recognising the impulse without acting. Over time, the proportion of (Emotional, action_taken) entries should fall to zero; the proportion of (Emotional, none_taken) entries should rise and then fall as the impulse itself fades.

The test of legitimacy: can you write a non-emotional reason? If the “reason” field reduces to “I don’t like how this looks,” the override is emotional. Don’t take the action.

The Three Pre-Committed Thresholds

Before going live, write down three numbers. Quantitative, specific, signed and dated. They will not be perfect — they don’t need to be. They need to exist:

1. The investigation threshold. “If the strategy reaches drawdown level X, I halt new entries, leave existing positions to run their stops, and conduct a structured investigation: is the strategy operating inside its MC distribution? Is the regime materially different from the validation period? Has any input data changed?” The threshold should be calibrated to your strategy’s expected drawdown profile — deep enough that you don’t investigate every wiggle, shallow enough that you investigate before disaster.
2. The kill threshold. “If the strategy reaches drawdown level Y, I close all positions, halt the strategy, and do not resume it without rebuilding the validation case from scratch.” This is the “the strategy is dead” threshold. Below it, you assume something fundamental has changed and the prior validation no longer applies. Y is materially deeper than X.
3. The size-stays-fixed threshold. “If the strategy is performing above expectation by margin Z, I do not increase size on the basis of recent strength.” This is the under-discussed threshold. Most operators don’t need rules to prevent them from cutting a winner; they need rules to prevent them from upsizing a winner that’s fired five times in a row. Recency-bias upsizing is how a 1% strategy becomes a 5% strategy at the worst possible moment.

What “Pre-Specified” Actually Means

The thresholds must be quantitative, written, dated, and committed to in advance. Two failure modes to avoid:

• Inventing the threshold during the drawdown. “I think 25% is my kill point” said at 23% drawdown is not a kill threshold; it’s a rationalisation gathering momentum. By 26% it will be 30%, and by 30% it will be 40%. Numbers chosen under stress drift.
• Vague thresholds. “I’ll halt if things get bad” is not a threshold. “I’ll halt at -22% on the strategy’s own equity curve, measured against the all-time high of that strategy’s equity” is a threshold. Vagueness is where willpower goes to die.

Honouring the Contract

The protocol works on one principle: honour the contract with your past self even when your present self disagrees with it. Your past self chose those numbers in conditions of clear-headed analysis; your present self is in a drawdown. The past self has better epistemic access to the truth of the strategy than the present self does. Trust the past self’s numbers, not the present self’s gut.

If you find yourself wanting to renegotiate the contract during the drawdown, that wanting is itself diagnostic information — it tells you the protocol is doing exactly what it was built to do, which is sit between you and the worst version of your judgement. Honour it; renegotiate later, in writing, in non-stress conditions.

Don’t Watch the Tick

Watching live P&L move minute by minute is corrosive even when the P&L is going up. The brain treats the equity curve as feedback — up feels good, down feels bad — and that feedback loop quietly shifts your relationship with the system away from “trust the validated process” and toward “feel the line.” The drawdown then triggers an emotional response disproportionate to its statistical significance, because you’ve been emotionally invested in every wiggle for weeks.

The discipline: read the dashboard once per day, at a fixed time, for a fixed duration. Pick a time that’s outside any major venue rollover or funding tick — mid-morning local works for most. Five to fifteen minutes. Look at the metrics that matter (current positions, current P&L, recent trades, watchdog status, any pending alerts), confirm the system is healthy, close the dashboard. Don’t graze.

Mute Alerts That Aren’t Action-Required

Module 9.5 covers the mechanics of alert routing; this is the operator-side complement. Every alert that fires without requiring an action is teaching your nervous system to ignore alerts in general. By the time the genuinely urgent alert fires — reconciliation hard-fail, drawdown threshold breach, exchange API blackout — you’ve already trained yourself to swipe it away with the rest.

The rule: every alert reaching your phone should require an action you would actually take in the next 15 minutes. Trade entries, daily PnL, “rate-limit recovered” — these belong in a dashboard or a daily-digest email, not on the lock screen.

Social Inputs During Drawdowns

Discretionary traders’ opinions on your validated systematic strategy, especially during a drawdown, are not signal. They are a hostile influence on your decision-making, even if the discretionary trader is a friend. Their emotional state is not yours, their information set is not yours, and their incentives during your drawdown are unaligned (they often want company in their pessimism).

Concrete moves: during drawdowns, mute or unfollow the noisy chat groups. Don’t doom-scroll instrument-specific Twitter. Don’t read Reddit threads about your strategy’s underlying instrument. The validated system is the system; its inputs are price, your indicators, and your gates — not other people’s panic.

The Checklist Beats the Hero

The temptation in an incident is to skip steps because you “know what’s wrong.” You don’t. You have a hypothesis. The hypothesis is contaminated by stress, by recency bias, by the symptom that’s loudest, and by the fix you would emotionally prefer to be the answer. Three out of four times you push a fix in this state, the symptom changes but the bug remains, and now there’s a second bug stacked on top.

The discipline is mechanical:

1. Read the runbook. Module 9.5 specifies that every alert has a four-line runbook entry. Read it. The runbook was written when you were calm; your present self is not. Trust the runbook over the impulse.
2. Verify the symptom. Reproduce it in logs. Confirm the bug is what you think it is, not just what you fear it is. Surprisingly often the “bug” is a misread of normal behaviour under unusual market conditions.
3. Halt the system. If the bug is real and material, halt new entries before investigating. A halted system that’s safe is preferable to a running system you don’t trust.
4. Investigate. Read the code. Read the data. Reproduce the bug in a non-production environment if possible.
5. Fix. Write the fix. Tests for the fix. Run the tests.
6. Deploy with blue/green. Module 9.6 covers the mechanics. Push the fix to the green instance; observe; only then promote.
7. Document the incident. Write the post-mortem while it’s fresh: what happened, when, what you did, what you should have done, what changes to prevent it. The post-mortem is the longest-term ROI of the incident.

The Pair Voice

Stressed engineers ship typos. The single highest-leverage anti-pattern intervention is to not work alone during incidents. The pair partner does not need to be an expert — they need to be a second voice that asks “wait, what does that line do?” before you push it. A competent AI assistant in pair-programming mode counts; a human friend on a video call counts; the rule is just “not alone with the keyboard at 2am, scared.”

The pair’s job is to slow you down. They will catch the missing semicolon, the wrong sign on a comparison, the off-by-one in the time window, and the deployment-to-prod-instead-of-staging that you would otherwise make. Their cost is their attention; the saving is the bug they prevent.

If You Can’t Walk Away, You Don’t Have a System

The blunt test: can you go on holiday for two weeks, leave the system running, and not check it? If the answer is no — if you have to dial in daily, if certain manual interventions only you can do, if there are alerts that only your judgement can resolve — you don’t have a systematic operation. You have a job. The job pays you, but it owns you.

The remedy is automation, not willpower. Anything you find yourself doing manually on a schedule should be automated. Anything that requires your judgement to resolve should either become a rule (and therefore automated) or be acknowledged as an unsystematic dependency that limits the strategy’s viability long-term. The system runs without you; the only role you should be filling on a daily basis is “person who reads the dashboard once and confirms it’s healthy.”

Schedule Deliberate Downtime

Running a system continuously for years requires deliberate periods where you are not the operator. Not just “I’m not at the keyboard” — properly off. Phone notifications muted (except for true Critical-tier alerts), dashboard not opened, mental model of the system not engaged. A weekly half-day, a monthly weekend, a quarterly week.

Build the system to make this safe: redundant alerting that reaches a designated backup contact (a paid service, an instrument-monitor alongside, anything that catches a true emergency without you), and a hard-coded rule that during your scheduled off-time the system reduces position size or halts new entries. Both can co-exist — the system trades through your weekend; the watchdog is loud enough that a true emergency reaches you anyway; routine alerts don’t.

Anxiety as a Sizing Signal

If you’re too anxious to sleep, the system is undersized for your psychological capital, even if it’s correctly sized for your financial capital. The fix is not “tough it out” — the fix is to reduce capital until you can sleep. Sleep-deprived operators make worse decisions during incidents, are more prone to emotional override, and burn out faster. The Sharpe of a strategy run by a rested operator is higher than the same strategy run by an exhausted one, holding everything else constant.

The ratchet works in both directions: as you live with the system through drawdowns, your psychological capital grows, and you can size up. But size up because you’re sleeping fine and have been for six months, not because the recent equity curve is flattering.

The Markers

• Written drawdown protocol thresholds. Three numbers, signed and dated, visible in your runbook.
• Override log with classification. Every manual touch tagged Engineering / Risk / Emotional, with a written reason.
• Hands-off endurance. Capable of leaving the system unattended for a week without your hands itching to intervene.
• Fixed dashboard cadence. Reading the dashboard at a defined time and duration, not on demand and not in response to emotional spikes.
• System-trust hierarchy. You trust your validated system more than your in-the-moment gut, and you have a clear, pre-specified rule for when the gut is allowed to override (Engineering or Risk only, with documented reason).
• Pair-during-incidents discipline. You do not push live fixes alone under stress.
• Sleep test. You sleep through drawdowns. If you don’t, you’ve already identified the next adjustment to make.