NautilusTrader — Project History
A chapter-based excavation of how NautilusTrader grew from a closed-source Cython FX prototype into a production Rust-native, multi-asset, multi-venue trading engine — written for someone reading the code in 2026 who needs to understand why the shape is what it is.
Generated with the excavate skill on 2026-04-27, against the repo at the tip of
develop(6480cfd9f7, post-v1.225.0).
Repo at a glance
Section titled “Repo at a glance”| First commit | 1b83d67682 — Initial commit, 2018-06-25 by Chris Sellers |
| Latest commit (tip) | 6480cfd9f7 — Tighten DST common-leg wall-clock smoke gate, 2026-04-27, post-v1.225.0 |
| Total non-merge commits | 18,468 in nearly 8 years |
| Tagged releases | v1.90.2 (Nov 2020) → v1.225.0 (Apr 2026), 206 tags |
| Issue tracker | GitHub issues + the RFC issue convention (e.g. #2084 high-precision mode, #2206 TA-Lib deprecation, #3555 Coinbase Intl removal). Project board. |
Top contributors (commits): Chris Sellers + cjdsellers + Christopher Sellers ≈ 16,097 combined; Filip Macek 307; faysou 275; Bradley McElroy 259; David Blom 134; Ishan Bhanuka 118; Vadim Nicolai 96; sunlei 76; rsmb7z 66; Pushkar Mishra 58. Long tail of ~50 contributors.
Activity curve:
- <100 commits/month through 2018–2019.
- 3-month near-zero “open-source prep” gap Apr–Jun 2020.
- Ramps through 2021 (~150–300/mo).
- Steady ~250/mo through 2023.
- 300–400/mo in 2024–2025.
- ~370/mo in early 2026 (single peak month: 2025-05 at 421).
Authoritative design docs: docs/concepts/ — architecture.md, message_bus.md, cache.md, data.md, execution.md, portfolio.md, live.md, backtesting.md, dst.md, options.md, greeks.md, rust.md, …; plus the canonical RELEASES.md (6,001 lines back to v1.106.0) and ROADMAP.md.
The author distribution is a one-author-plus-collaborators shape. Chris Sellers
(cjdsellers) is effectively the architect; almost every chapter’s structural
move is his. Outside contributors do adapter work, indicator ports, and
specialised features.
How to read this book
Section titled “How to read this book”Each chapter is a self-contained markdown file under chapters/.
Read them in order, or jump to the era you care about. Chapters share a common
shape:
- Why — one sentence motivation for the chapter.
- Timeline — anchor commits / PRs / tags with dates.
- Architecture before & after — what shape was the system in at the start of the chapter, what shape was it in at the end.
- Key decisions — the trade-offs that defined the chapter, with the release notes / commit citations that committed the team to them.
- Casualties — what was removed in that chapter (often more illuminating than what survived).
- Q&A — seed questions worth challenging (the interactive part of an excavation).
- Insights for daily work — chapter-level takeaways.
For deeply-distilled “what I wish someone had told me” notes, see Architecture Insights.
Activity by month — the inflection points
Section titled “Activity by month — the inflection points”| Window | Notes |
|---|---|
| 2018-06 → 2018-12 | Genesis. Pure Python → Cythonized in Dec 2018. |
| 2020-04 → 2020-06 | 3-month dead zone before the open-source release. Cleanup, license headers, FXCM stripping. |
| 2020-07 → 2020-10 | Public release; first PyPI wheel on 2020-07-21. |
| 2020-11 | First tagged release (v1.90.2); semantic versioning starts at 1.90 (continuing the closed-source counter). |
| 2021-01 → 2021-02 | OrderBook in Cython, then v1.106 IB scaffold + identifier overhaul. |
| 2021-07 | MessageBus introduced (v1.125). |
| 2022-04 | First Rust files committed (crates/); the long Rust port begins. |
| 2023-06 | Rust OrderBook + HttpClient + WebSocketClient integrated (v1.175). |
| 2023-12 | Rust RedisCacheDatabase; Bybit adapter (v1.182). |
| 2024-08 | MessageBus v2 + DataEngine v2 in Rust (v1.197). |
| 2025-02 | High-precision (128-bit) value types (v1.211). |
| 2025-03 | Poetry → uv migration; OwnOrderBook for self-trade prevention. |
| 2025-04 | Blockchain adapter, FIPS-grade crypto, exponential-backoff reconnects. |
| 2025-07 | Hyperliquid adapter; tracing subscriber. |
| 2026-01 → 2026-04 | Architect AX, Coinbase, Kraken, multi-account, deterministic simulation testing, bon builder migration. |
Chapter map
Section titled “Chapter map”Where to start
Section titled “Where to start”If you are new to the codebase, read chapters 010, 040, 050, 070, 100, and 140 first — those carry the structural moves the rest of the chapters refine. Skim the others.
If you are about to touch a specific subsystem, jump to the chapter that introduced it:
| Subsystem | Chapter |
|---|---|
MessageBus, pub/sub | 050 (intro), 100 (v2 in Rust), 120 (actor framework v3) |
Cache | 050 (unification), 080 (Rust Redis), 100 (Rust port) |
| Order book | 030 (Cython prototype), 070 (Rust integration), 110 (high-precision) |
OrderEmulator | 060 (introduced) |
RiskEngine | 040 (scaffolded), 050 (iteration 2), 100 (Rust port) |
ExecutionEngine | 050, 100 (Rust port), 140 (multi-account) |
Portfolio | 100 (Rust port), 120 (mark prices, PortfolioConfig) |
BacktestNode / BacktestEngine | 060 (NautilusKernel unification), 120 (Rust port) |
OrderMatchingEngine | 060 (introduced), 110–120 (incremental Rust port) |
| Adapters — IB | 040 (scaffolded), 060 (v1 beta), 080 (v2), 140 (Rust adapter w/ PyO3 layer) |
| Adapters — Binance | 060, 090 |
| Adapters — Betfair | 040 (introduced), 050 (rewrite for performance), 080 (Rust), 130 (race-data) |
| Adapters — crypto (Bybit/dYdX/Polymarket/OKX/Hyperliquid/Kraken/BitMEX) | 090, 130, 140 |
| Adapters — Tardis, Databento | 090, 140 |
| Adapters — Blockchain (DEX) | 130, 140 |
| Adapters — Architect AX, Coinbase | 140, 150 |
| Logging | 080 (Rust log crate), 130 (rotation), 150 (tracing subscriber) |
| Crypto / TLS | 130 (aws-lc-rs, FIPS), 140 (credential zeroization) |
| Persistence — catalog | 050 (Parquet intro), 080 (catalog v2), 130 (consolidation), 140 (catalog refactor) |
bon config builders | 150 (codebase-wide migration) |
Legend
Section titled “Legend”- Casualties in each chapter — modules / configs / experiments that were removed in that window. The shape of the current code is often easier to understand by what was tried and abandoned than by what survived.
- Why in each chapter — the apparent motivation, inferred from commit messages, release notes, and PR / issue context. Where motivation is genuinely opaque, the chapter says so rather than guessing.