Home

sbt2

sbt2 is a backtesting engine built on nautilus_trader. It is a from-scratch rewrite of sbt, which grew too messy to maintain. See Lessons from v1.

It is general-purpose: data sources and asset classes plug in (see Data sources and Asset classes), and the core only sees nautilus types. It supports everything from bars to full L2 order book and trade data.

The goal is a published package: a user installs sbt2, writes only a strategy, and sbt2 handles data, splits, optimisation and reporting. See Library.

The first use case is crypto perpetuals, documented on its own pages (Crypto perpetuals, Source Bybit). The framework pages don't depend on it.

Guiding principles

• Use nautilus wherever it already does the job. sbt2 is built on nautilus v2, whose Rust core settles funding, records mark-to-market equity, builds bars and writes the catalog. Write code only for real gaps (e.g. splits, the test lock, stored results, the thin strategy base).
• Results must be trustworthy before they are convenient. That means real instrument specs, real costs, carry costs (funding, borrow, rollover) in PnL and no look-ahead.
• Memory safety for L2: data is streamed and runs are isolated. A single run can never take the machine down.
• Strategies are nautilus strategies. A thin sbt2 base adds only what the pipeline needs: metadata readable without running, bar subscriptions and the warm-up gate.
• Docs live here, at the architecture level. Code-level detail belongs in docstrings next to the code.

Pages

• Architecture: module map, data flow, dependency rules
• Library: sbt2 as a published package, from the user's side
• C4 model: the architecture as C4 diagrams (context, containers, components, dynamic, deployment)
• Plug-ins: Data sources · Asset classes
• Modules: Data · Spec · Strategy · Run · Results · CLI
• Quality: testing and CI
• Glossary: terms used in this wiki
• Decisions: what we chose and why
• Deferred: parked for later
• Lessons from v1
• Paper extraction: research papers to structured records, in sbt2.papers
• References: papers and projects the design draws on

Status

M0 (foundations), M1 (walking skeleton), M2 (real data), M3 (splits and batches), M4 (brackets and risk) and M5 (analysis and reports) are done; M6 (L2 order book) is next. The engine milestones (M2–M7) come first, then the library ones (M8–M11, see Library).