Quantitative trading has finally received its true “ultimate weapon”! NautilusTrader is currently one of the most hardcore open-source trading engines on GitHub (already with 26,000+ stars!). Rust-native core delivers brutal performance + memory safety. Python strategy writing offers silky-smooth execution. The most powerful feature: backtested strategy code requires zero modification for seamless transition to live trading. The same event-driven architecture, identical time model, identical execution logic. Research = Production, completely ending the classic pitfall of “beautiful backtests, tragic live results”! Supports: • Multi-asset coverage (crypto, forex, equities, futures, options) • Simultaneous multi-exchange operation (market-making, arbitrage, etc.) • Nanosecond-precision historical data backtesting • Advanced order types (IOC/FOK/iceberg/OCO/OTO all supported) • Can even train AI trading agents. Achieving true “frictionless transition from lab to battlefield.” Quant traders, high-frequency players, strategy developers… this is a must-bookmark! GitHub link: https://github.com/nautechsystems/nautilus_trader #QuantTrading #AlgoTrading #Rust #Python #NautilusTrader #HighFrequencyTrading

nautechsystems/nautilus_trader

Source: https://github.com/nautechsystems/nautilus_trader

rustc (https://crates.io/crates/nautilus-core)

crates.io (https://crates.io/crates/nautilus-core)
codspeed (https://codspeed.io/nautechsystems/nautilus_trader)
pythons
pypi-version
Downloads (https://pepy.tech/projects/nautilus-trader)
Discord (https://discord.gg/NautilusTrader)

• Docs:
• Website:
• Support: [email protected]

Introduction

NautilusTrader is an open-source, production-grade, Rust-native engine for multi-asset, multi-venue trading systems. The system spans research, deterministic simulation, and live execution within a single event-driven architecture, with Python serving as the control plane for strategy logic, configuration, and orchestration. This separation provides the performance and safety of a compiled trading engine with the flexibility of Python for system composition and strategy development. Trading systems can also be written entirely in Rust for mission-critical workloads.

The same execution semantics and deterministic time model operate in both research and live systems. Strategies deploy from research to production with no code changes, providing research-to-live parity and reducing the divergence that typically introduces deployment risk.

NautilusTrader is asset-class-agnostic. Any venue with a REST API or WebSocket feed can be integrated through modular adapters. Current integrations span crypto exchanges (CEX and DEX), traditional markets (FX, equities, futures, options), and betting exchanges.

nautilus-trader

Features

• Fast: Rust core with the mimalloc allocator and asynchronous networking using tokio.
• Reliable: Type- and thread-safety backed by Rust, with optional Redis-backed state persistence.
• Portable: Runs on Linux, macOS, and Windows. Deploy using Docker.
• Flexible: Modular adapters integrate any REST API or WebSocket feed.
• Advanced: Time in force IOC, FOK, GTC, GTD, DAY, AT_THE_OPEN, AT_THE_CLOSE, advanced order types and conditional triggers. Execution instructions post-only, reduce-only, and icebergs. Contingency orders including OCO, OUO, OTO.
• Customizable: User-defined components, or assemble entire systems from scratch using the cache and message bus.
• Backtesting: Multiple venues, instruments, and strategies simultaneously using historical quote tick, trade tick, bar, order book, and custom data with nanosecond resolution.
• Live: Identical strategy implementations between research and live deployment.
• Multi-venue: Run market-making and cross-venue strategies across multiple venues simultaneously.
• AI Training: Engine fast enough to train AI trading agents (RL/ES).

nautilus

nautilus - from ancient Greek ‘sailor’ and naus ‘ship’.

The nautilus shell consists of modular chambers with a growth factor which approximates a logarithmic spiral. The idea is that this can be translated to the aesthetics of design and architecture.

Why NautilusTrader?

Trading strategy research is often conducted in Python using vectorized approaches, while production trading systems are implemented separately using event-driven architectures in compiled languages. NautilusTrader removes this separation. A Rust-native core provides a deterministic event-driven runtime for both research and live execution, while Python serves as the control plane. The same architecture, execution semantics, and time model operate across both environments, allowing strategies to move from research to production without reimplementation.

Python bindings are provided via PyO3 for the Rust‐native v2 runtime. During the v2 transition, v1 receives only critical security backports on the develop_v1 branch. See the v2 migration guide for migration steps and compatibility details. No Rust toolchain is required to install prebuilt wheels.

This project makes the Soundness Pledge:

“The intent of this project is to be free of soundness bugs. The developers will do their best to avoid them, and welcome help in analyzing and fixing them.”

MSRV: NautilusTrader relies heavily on improvements in the Rust language and compiler. As a result, the Minimum Supported Rust Version (MSRV) is generally equal to the latest stable release of Rust.

Integrations

NautilusTrader is modularly designed to work with adapters, enabling connectivity to trading venues and data providers by translating their raw APIs into a unified interface and normalized domain model. The following integrations are currently supported; see docs/integrations/ for details:

• ID: The default client ID for the integrations adapter clients.
• Type: The type of integration (often the venue type).

Status

• planned: Planned for future development.
• building: Under construction and likely not in a usable state.
• beta: Completed to a minimally working state and in a beta testing phase.
• stable: Stabilized feature set and API, the integration has been tested by both developers and users to a reasonable level (some bugs may still remain).

See the Integrations documentation for further details.

Roadmap

The Roadmap outlines NautilusTrader’s strategic direction. Current priorities include stabilizing the Rust‐native core, improving documentation, and enhancing code ergonomics.

The open-source project focuses on single-node backtesting and live trading for individual and small-team quantitative traders. UI dashboards, distributed orchestration, and built-in AI/ML tooling are out of scope to maintain focus on the core engine and ecosystem sustainability. New integration proposals should start with an RFC issue to discuss suitability before submitting a PR. See Community-contributed integrations for guidelines.

Security

OpenSSF Scorecard

Security is a priority for the NautilusTrader project, and we value the work of those who help identify and resolve vulnerabilities. We apply layered controls across the development and release lifecycle, with signed releases, continuous vulnerability management, and transparent development practices:

• Source and review controls: CODEOWNERS gate critical infrastructure, dependency manifests, and lock files; protected branches require signed commits and passing CI; release tags are immutable; and Rust dependencies are sourced only from crates.io.
• Dependency intake: lock files pin every dependency with cryptographic checksums, third-party Python packages install from wheels only, new dependency and tooling versions observe a publication cooldown before adoption, cargo-vet audits Rust provenance, and cargo-deny checks Rust dependencies against an allow list of licenses compatible with NautilusTrader’s LGPL-3.0-only license.
• Scanning and fuzzing: Gitleaks secret screening and Zizmor Actions auditing run pre-commit; CodeQL runs on PRs to master and pushes to nightly; cargo-audit, cargo-deny, cargo-vet, OSV Scanner, and pip-audit run on audit-relevant PRs and daily schedules; cargo-fuzz targets cover selected adapter and signing surfaces.
• Build and release integrity: GitHub Actions are pinned to commit SHAs, CI runners are hardened with egress allow-listing, Python artifacts carry SLSA build provenance, container images are Sigstore-signed with attested SPDX SBOMs, and PyPI and crates.io publishing uses OIDC Trusted Publishing gated to a protected release environment that never runs pull request or fork code.
• Runtime cryptography: TLS and most runtime cryptography use aws-lc-rs, the Rust binding for AWS-LC, with Ed25519 signing via ed25519-dalek.

The OpenSSF Scorecard badge above is one automated repository-health signal; it complements manual review, CI hardening, and security audits rather than replacing them.

Reporting a vulnerability

Report privately through GitHub Security Advisories, or email (PGP key available on request). We acknowledge reports within 48 hours and patch critical vulnerabilities within 30 days. A careful vulnerability report takes real time and effort. We appreciate that, and unless you prefer to remain anonymous, we credit reporters in the relevant security advisory and release notes. The Security Policy details scope, coordinated disclosure, and step-by-step release verification. The Security Architecture describes the release supply chain end-to-end. For the full policies, see the Responsible Disclosure and Supply Chain Security policies; CI/CD security is documented in .github/OVERVIEW.md.

Versioning and releases

NautilusTrader is still under active development. Some features may be incomplete, and while the API is becoming more stable, breaking changes can occur between releases. We strive to document these changes in the release notes on a best-effort basis. We aim to follow a bi-weekly release schedule, though experimental or larger features may cause delays.

Branches

We aim to maintain a stable, passing build across all branches.

• master: Reflects the source code for the latest released version; recommended for production use.
• nightly: Daily snapshots of the develop branch for early testing; merged at 14:00 UTC and as required.
• develop: Active development branch for contributors and feature work.

The v2 release-candidate line is the transition toward a stable API for version 2.x. Once this milestone is reached, we plan to implement a formal deprecation process for any API changes. This approach allows us to maintain a rapid development pace for now.

Precision mode

NautilusTrader supports two precision modes for its core value types (Price, Quantity, Money), which differ in their internal bit-width and maximum decimal precision.

• High-precision: 128-bit integers with up to 16 decimals of precision, and a larger value range.
• Standard-precision: 64-bit integers with up to 9 decimals of precision, and a smaller value range.

By default, the official Python wheels ship in high‐precision (128‐bit) mode on all supported platforms.

For pure Rust crates, high-precision works on all platforms (including Windows) since Rust handles i128/u128 via software emulation. The default is standard-precision unless you explicitly enable the high-precision feature flag.

See the Installation Guide for further details.

Rust feature flag: To enable high-precision mode in Rust, add the high-precision feature to your Cargo.toml:

[dependencies]
nautilus_model = { version = "*", features = ["high-precision"] }

Installation

We recommend using the latest supported version of Python and installing nautilus_trader (ht)