NautilusTrader

What it is

NautilusTrader is an event-driven trading engine: a Rust core with a Python control plane, where a strategy subscribes to data and emits orders against either a simulated venue or a real one. The same strategy object runs in both. That is the whole design argument — there is no research implementation to keep in sync with a separate production one, and no class of translation bug between them.

Event-driven rather than vectorised. The engine replays quote ticks, trade ticks, order-book deltas, bars and custom data through a message bus with nanosecond timestamps, and a strategy sees each event in order. That costs runtime against a library that computes over a whole series at once, and it buys the ability to express a rule that depends on what happened at the last fill. It is also the architectural choice you do not get to revise later.

The project is mid-migration. Version 2.0.0rc5 was tagged on 2026-09-15, while the newest stable release on PyPI is 1.231.0 from 2026-08-02; during the transition v1 receives only critical security backports, on a separate branch. The repository is not archived and the default branch had commits on the day this card was written.

Pricing

Nothing to pay for the engine. It is LGPL-3.0, installs from PyPI, and no feature is held behind a tier — the funding settlement, the margin models, the fill models and every adapter are in the same package.

Nautech Systems, which publishes it, sells around it rather than inside it. NautilusTrader Pro is a set of Docker-delivered components — execution algorithms (VWAP, POV, iceberg, sniper), a risk engine, a monitoring dashboard, a zero-copy IPC messaging layer — described as flexible product subscriptions and gated behind a waitlist. Nautilus Cloud offers managed and self-hosted deployments and both options are labelled coming soon, with the page stating the product is still under active development. As of 2026-09-19 there is no pricing page on the site and neither offering quotes a number, so there is no tier list on this card to compare against anything.

Data & coverage

The engine ships no data. You bring it, either as a Parquet-backed catalog for historical replay or through an adapter. Every integration in the repository's own table is marked stable: Binance, BitMEX, Bybit, Coinbase, Deribit, Kraken and OKX on the centralised side; dYdX, Derive, Hyperliquid, Lighter (including its Robinhood Chain deployment) and Polymarket on the decentralised side; Architect's AX perpetuals exchange; Databento and Tardis as data vendors; and Interactive Brokers and Betfair for everything that is not crypto.

Perpetuals are simulated rather than approximated. Funding is settled from FundingRateUpdate records at the venue's funding boundaries: the simulated exchange emits a FundingSettlement, a positive rate debits longs and credits shorts, and the payment lands in realised PnL and the account balance. Margin accounts use a leveraged margin model by default, with a standard model available that reserves the instrument's fixed initial and maintenance percentages without reducing them by leverage. Mark prices are a first-class data type and are what margining, liquidation checks and unrealised PnL read when you feed them.

Check the defaults before you believe a result. The default fee model charges the instrument's own maker and taker rates by liquidity side, which means an instrument definition you assembled by hand with zero fees will charge zero. The default fill model treats a touched limit order as filled and applies no probabilistic one-tick slippage; ten other fill models ship with the engine, from a one-tick slippage model to tiered synthetic books, and choosing one is a deliberate act.

Bar backtests are a plausible path, not the real one. A bar does not record whether its high preceded its low, so the engine splits each bar into four synthetic L1 updates — open, high and low in a configured order, then close — and matches after each. The timestamp convention matters more than it looks: a bar's initialisation timestamp must be the close of its interval, or the complete bar becomes visible to the strategy before it formed.

On-chain coverage is EVM and narrower than the adapter list suggests. Uniswap V3 and PancakeSwap V3 are replay-ready on Ethereum, Base, Arbitrum and BSC; Aerodrome Slipstream is analysis-only on Base; Uniswap V2 and V4, Camelot V3 and Fluid DEX are discovery-only; Curve and SushiSwap are registered without event parsers. Direct websocket RPC clients exist for Ethereum, Polygon, Base, Arbitrum and BSC, and other configured chains fall back to block history. Solana and Bitcoin are not among the chains the adapter indexes at all.

Integrations

• Python 3.12 to 3.14 with prebuilt wheels, so no Rust toolchain is needed; Linux, macOS and Windows. Strategies can also be written entirely in Rust.
• A sandbox adapter runs paper trading against live market data through the same order matching engine the backtest uses.
• ReportProvider turns cached orders, fills, positions and account states into pandas DataFrames, and the same reports exist in backtest and in live trading.
• An optional visualization extra writes self-contained Plotly HTML tearsheets — equity, drawdown, monthly-return heatmap, rolling Sharpe and an OHLC candlestick chart with the run's fills overlaid — or a static PNG or PDF through Kaleido.
• Option Greeks arrive either streamed from a venue or computed locally by a Black-Scholes calculator with portfolio aggregation, shock scenarios and beta weighting.
• Optional Redis-backed state persistence, plus a CLI for Postgres schema management and the blockchain adapter's block, pool-discovery and pool-analysis commands.

Limitations

Liquidation is off by default. liquidation_enabled is false on a backtest venue unless you set it. Run a perpetuals backtest on the defaults and the simulation will hold a losing position straight through the price at which the venue would have closed it — the machinery is there, it is just not armed.

Funding only settles if you brought funding data. No adapter conjures the history, and a funding rate record without a settlement boundary is explicitly inert: the documentation says such updates remain strategy data and do not create funding payments. The same applies to mark prices — margining and liquidation use whatever is in the cache, so a backtest with no mark prices marks against the last traded price.

Liquidation, once armed, is per settlement currency. Only positions settling in the breached currency are closed; positions in another currency stay open. The code notes a cross-margin venue mode as a possible future, not a current option.

The default fills are optimistic in two directions. Every touched limit fills, and with liquidity consumption off the same displayed size at a price level can support more than one simulated order in the same iteration. Neither default is wrong for a first pass; both flatter a strategy that trades size.

The v2 transition is happening now. 2.0 is at release candidate 5 and v1 is down to critical security backports on its own branch, so a new build is a choice between a release candidate and a line in maintenance.

The DeFi execution client is experimental and Python cannot reach it. It signs Uniswap V3 market swaps locally, the documentation calls it not production-ready, the Python module does not register its factory, and the repository ships no maintained runnable execution example. Treat the on-chain side as a data integration.

LGPL-3.0 is not a permissive licence. Running your own strategies on it is unencumbered; shipping a modified engine inside a closed-source product is a question to answer before you start, not after. Read the LICENSE file rather than a badge — and note that the version on PyPI today, 1.231.0, still carries LGPL-3.0-or-later in its package metadata while the repository, the source headers and the v2 packaging all say LGPL-3.0-only. If the difference matters to you, the file is the one that governs.

There is no GUI and no strategy configuration format. Every strategy is code, every venue is a config object, and the smallest useful backtest is a hundred lines or so. That is the price of the research-to-live parity, and it is charged up front.

Alternatives

If the question is whether a signal had an edge on hourly or daily bars, a vectorised library answers it in a fraction of the code and a fraction of the runtime, and the event loop here is overhead you would be paying for a capability you are not using. If you want to configure a bot rather than build a trading system, this is the wrong shape entirely.

The case for it is specific: perpetuals, where the funding and the liquidation are the strategy rather than a rounding error, and a plan to run the result live without rewriting it.

If the job is thousands of parameter combinations rather than one event loop, vectorbt answers it vectorised, and vectorbt PRO is its paid edition — neither of which models funding or liquidation, so they answer a different question about a different kind of strategy.