The Trading System

The ideas behind it, and the engineering that runs it.


§ 01 — The Market

A young, inefficient market is the right place to prove a method.

Most quantitative work starts by competing head-on with Renaissance and Citadel in equities — deep liquidity, razor-thin edges, decades of infrastructure advantage. I deliberately started somewhere the structure favors a careful newcomer.

Binary BTC prediction markets are an unusually clean proving ground. Outcomes resolve to a simple yes/no, so the feedback loop is fast and honest — you find out quickly whether a model is actually calibrated. The contracts settle at resolution, so there’s no exit spread to fight. And the venue is young and growing fast: it’s currently subsidizing growth rather than extracting commission, so trading costs are minimal — a structural tailwind that won’t last forever, and a tell that this is an early, still-inefficient arena where rigorous work can find edges that would vanish in seconds on the NYSE.


§ 02 — The Model

The interesting part wasn't the model. It was the validation.

I trained calibrated, gradient-boosted models on years of high-frequency BTC data — tens of thousands of samples across a broad feature set spanning market microstructure, derivatives positioning, cross-asset behavior, momentum, and volatility regimes. Building the model is the easy part. Trusting it is the hard part.

So I put it through the wringer: walk-forward cross-validation, probability calibration compared across several methods, information-coefficient and SHAP analysis to understand what the model actually keyed on, and permutation-based significance testing to separate genuine signal from lucky noise — all with transaction costs built into the expected-value math from the start.

The result I’m proudest of is a negative one. Searching for pockets of predictability, I found 17 promising candidates — and killed all 17 when they failed honest out-of-sample testing. The edge was real but thin and diffuse, not concentrated where it would have been easy to exploit. That finding is what told me exactly what kind of strategy could actually harvest it.


§ 03 — The Strategy

A prediction is the opening move. The money is in everything after it.

Plenty of engineers can train a model to predict a market. Far fewer know what to do once it has — and closing that gap is what I set out to learn. A forecast is only step one. The real work is the trader’s craft around it: knowing when an edge is too thin to bet, capping your downside before you ever need it, cutting or flipping a position when the market turns against you, and protecting profit instead of pressing your luck.

So the system doesn’t just predict — it trades. It treats its own signal with suspicion, acting only when the edge clears costs. It enters with downside already hedged, adapts as each market plays out and new information arrives, and sizes every position with fractional-Kelly discipline so conviction maps to capital without ever betting the farm. The guiding instinct is a trader’s, not a scientist’s: survive being wrong often, protect what you’ve made, and let a modest edge compound. In backtesting it stayed positive across every quarter I tested and held up under added transaction costs — robustness I valued far more than any flashy number.


§ 04 — The Engineering

Research is half the work. The other half is making it run, unattended, on real money.

A model is worthless if it can’t trade reliably while I sleep, so the live system is a small distributed system built for correctness under failure. A FastAPI trading service orchestrates Nautilus Trader strategy lifecycles and execution; a separate inference sidecar serves calibrated predictions; Postgres is the single source of truth; and market settlement runs as a durable async workflow that survives restarts.

FILLSPREDICTEPOCH CLOSECOMMITClientlive dashboardCloudFrontTLSTrading ServiceFastAPI · Nautilus · riskMarketsdata · executionInference Sidecarcalibrated modelPostgressource of truthS3 · AthenaanalyticsStep FunctionsLambdadurable settlementCloudWatchtracing
Fig. 01 — Live system topology on AWS · dashed lines: telemetry

Two engineering decisions I’d call out. First, I split inference into a dedicated Go sidecar: model training stays in Python, but serving compiles down to a tiny native binary with a sub-100ms cold start and a ~15MB image — a fraction of a Python equivalent — and lets me redeploy a retrained model without touching the trading engine. Second, settlement is durable: because outcomes can lag the market close and must survive a crash, resolution runs as an idempotent Step Functions + Lambda workflow that retries with backoff and writes results transactionally — never guessing an outcome if it can’t confirm one. The stack is built to grow from a lean single instance to fully managed, multi-AZ infrastructure without a rewrite.