# NautilusTrader

Event-driven Rust engine that settles perpetual funding at the venue boundary.

*https://cryptomarkets.tools/tools/nautilus-trader · Backtesting & Research Libraries*

## Also covered on

- [NautilusTrader on StockMarketStack](https://stockmarketstack.com/tools/nautilus-trader.md) — the same engine reached through Interactive Brokers and Databento, for equities

## Facts

### At a glance

| Field | Value |
| --- | --- |
| Vendor | NautilusTrader |
| Category | Backtesting & Research Libraries |
| Job | backtesting |
| Website | https://nautilustrader.io |
| Pricing model | open-source |
| Free tier | true |
| Open source | true |
| Licence | LGPL-3.0-only |
| Self-hosted | true |
| KYC required | false |
| Tested hands-on | false |
| Last updated | 2026-09-21 |

### Coverage

| Field | Value |
| --- | --- |
| Asset classes | spot, perpetuals, futures, options, defi |
| Chains | ethereum, base, arbitrum, polygon, bnb |
| Venues | cex, dex, derivatives |
| Data latency | realtime |
| Platforms | library, cli |
| AI features | none |

### Interfaces

| Field | Value |
| --- | --- |
| API | false |
| Webhooks | false |
| Scripting | Python |
| MCP server | false |
| Export | parquet |

### Capabilities

Yes: charting, backtesting, automation, live_trading, paper_trading, portfolio_tracking, onchain_data, derivatives_analytics

No: screening, exchange_import, tax_reporting, alerts, news, wallet_tracking

*Verified: pricing 2026-09-19; capabilities 2026-09-19; coverage 2026-09-19.*

## 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](https://cryptomarkets.tools/tools/vectorbt) answers it vectorised, and [vectorbt PRO](https://cryptomarkets.tools/tools/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.

## FAQ

### Does NautilusTrader model perpetual funding in a backtest?

Yes, if you supply the funding history. Funding arrives as FundingRateUpdate data; at each settlement boundary the simulated exchange emits a FundingSettlement that debits longs and credits shorts and moves the account balance. A rate record with no boundary attached pays nothing — the docs call it strategy data.

### Does the backtest liquidate a losing position?

Only if you switch it on. liquidation_enabled defaults to false on a backtest venue. When enabled, the venue closes positions in a settlement currency once balance plus unrealised PnL falls to maintenance margin multiplied by liquidation_trigger_ratio, which defaults to 1.0.

### Is it event-driven or vectorised?

Event-driven. Quotes, trades, order-book deltas, bars and custom data are replayed through a message bus at nanosecond resolution and the strategy sees each event in order. That is slower than a vectorised sweep over a series and it is what lets a rule depend on the last fill.

### What does NautilusTrader cost?

The engine is free under LGPL-3.0 and no feature is held back. Nautech Systems sells NautilusTrader Pro as Docker components and is building Nautilus Cloud; as of 2026-09-19 Pro is waitlist-only, Cloud is marked coming soon, and neither publishes a price. The site has no pricing page.

### Can I use it for on-chain trading?

For data, largely yes on EVM chains. For execution, no — the blockchain adapter ships an experimental client for locally signed Uniswap V3 market swaps that the documentation calls not production-ready, and the Python module does not expose it at all.

## Also worth comparing

- [Backtesting.py](https://cryptomarkets.tools/tools/backtesting-py.md) — Two thousand lines, one OHLC series, and no idea what a funding payment is.
- [Barter](https://cryptomarkets.tools/tools/barter.md) — Rust trading engine and market-data streams — live execution is a trait you implement.
- [HftBacktest](https://cryptomarkets.tools/tools/hftbacktest.md) — Tick-by-tick backtesting that models order queue position and feed and order latency.
- [LEAN](https://cryptomarkets.tools/tools/lean.md) — The engine behind QuantConnect, Apache-2.0 and runnable on your own machine.
- [Lumibot](https://cryptomarkets.tools/tools/lumibot.md) — One Python strategy that backtests and then trades live, across eight CCXT exchanges.
- [Jesse](https://cryptomarkets.tools/tools/jesse.md) — Python backtesting and research framework whose live-trading half is a paid plugin.

## Named as a replacement for

- [Enigma Catalyst](https://cryptomarkets.tools/alternatives/enigma-catalyst.md)