WAIT — Single-maintainer risk — review before adopting

• Last commit today
• 5 active contributors
• LGPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 90% of recent commits
• ⚠ LGPL-3.0 is copyleft — check downstream compatibility

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

Nautilus Trader is a production-grade, Rust-native algorithmic trading engine built on deterministic event-driven architecture. It executes backtests, paper trading, and live trading across 18+ exchange adapters (Binance, Coinbase, Kraken, Betfair, etc.) with Python bindings via PyO3, enabling quant traders to build systematic strategies with microsecond-level latency and reproducible execution. Monorepo (Cargo workspace) with crates/core as the deterministic event engine, crates/adapters/ containing 18 exchange-specific integrations, crates/backtest for simulation, crates/cli for CLI tools, and crates/pyo3 wrapping the Rust engine for Python. State flows through event handlers; persistence via crates/persistence and Cap'n Proto serialization (seen in .cargo deps).

Quantitative traders, algo trading developers, and prop trading firms who need a deterministic, high-performance trading platform with multi-exchange support. Contributors are systems engineers and Python/Rust developers building exchange integrations (see crates/adapters/) and trading infrastructure.

Production-ready and actively developed (v0.58.0, Rust 1.95.0 requirement). The project shows strong CI/CD (35+ GitHub workflows including nightly-miri, security-audit, performance), comprehensive test coverage (codecov badge present), and 41.6M lines of Rust code. Recent activity includes nightly builds, Docker support, and structured workspace organization—clear signals of professional maintenance.

Low-to-moderate risk: 40+ workspace crates create complex dependency management (see crates/adapters with 18 exchange integrations—each a potential maintenance surface). LGPL-3.0-or-later license requires derivative compliance. Risk of breaking changes exists (v0.58.0 still pre-1.0), but mitigated by strong CI and nightly test channels. Watch for exchange adapter deprecation (APIs change quarterly).

Active development on nightly branch (separate version.json). Workflows include nightly-docs-features-check, nightly-miri (unsafe code verification), and performance benchmarking (codspeed badge). Docker/Jupyter support added (.docker/jupyterlab.dockerfile). Exchange adapters actively maintained (Hyperliquid, dYdX, Polymarket integrations suggest recent expansion).

Clone and build:

git clone https://github.com/nautechsystems/nautilus_trader.git
cd nautilus_trader
cargo build --release

For Python bindings: pip install nautilus-trader or build wheels via .github/workflows/build.yml. Docker available: docker-compose -f .docker/docker-compose.yml up.

Daily commands: Dev build: cargo build (incremental). Run tests: cargo test --workspace (or nextest via .config/nextest.toml: cargo nextest run). Run CLI: cargo run --bin nautilus-cli -- <cmd> (crates/cli). Backtest: Write Python strategy, use crates/backtest engine. Live trading: Configure adapters (crates/adapters/<exchange>) and use crates/live orchestrator. Docker: .docker/entrypoint.sh for containerized setup.

• Cargo.toml — Workspace root configuration defining all 30+ member crates and shared dependencies; essential for understanding build structure and version management across the entire trading engine.
• crates/core — Core trading engine crate containing deterministic event-driven architecture; foundational abstractions for all trading logic must be understood before modifying subsystems.
• crates/execution — Order execution engine implementing the critical path for trade placement and management; any changes impact trading determinism and risk controls.
• crates/adapters — Multi-exchange adapter layer for Binance, Kraken, Coinbase, and 15+ venues; defines extension interface for connecting new market data and execution sources.
• .github/workflows/build.yml — Primary CI/CD pipeline orchestrating Rust testing, Python bindings via PyO3, and wheel distribution; defines integration testing standards for all contributions.
• build.py — Custom build script coordinating Cargo compilation with Python package generation; required for local development setup and understanding cross-language integration.
• .pre-commit-hooks — Enforces 25+ custom code quality checks (nautilus conventions, formatting, DST compliance, error handling); every PR must pass these lints before merging.

Add a New Exchange Adapter

1. Create adapter crate directory: crates/adapters/{exchange_name}/ (crates/adapters/{exchange_name}/Cargo.toml)
2. Implement MarketDataClient and ExecutionClient traits from core; handle websocket/REST connections and message serialization specific to exchange API (crates/adapters/{exchange_name}/src/lib.rs)
3. Define order state machine and fill/settlement logic that maps exchange fills to Nautilus order events (crates/adapters/{exchange_name}/src/execution.rs)
4. Register adapter in workspace and create integration test against sandbox environment (Cargo.toml)
5. Add adapter to CI workflows for nightly testing (.github/workflows/build.yml)

Add a New Technical Indicator

1. Implement Indicator trait in new module with stateful update logic and deterministic output (crates/indicators/src/lib.rs)
2. Define input validation, parameter bounds, and warmup period requirements (crates/indicators/src/your_indicator.rs)
3. Add unit tests covering edge cases (gaps, NaN, warmup transitions) and reference against academic formulas (crates/indicators/tests/test_your_indicator.rs)
4. Export from crates/indicators/src/lib.rs and update public API docs (crates/indicators/src/lib.rs)

Add a Backtest Feature or Risk Control

1. Define new event type or order state extension in core event schema (crates/core/src/events.rs)
2. Implement processing logic in backtester's state machine or executor (crates/backtest/src/engine.rs)
3. Add determinism validation: ensure replay produces identical results with same event sequence (crates/backtest/tests/test_determinism.rs)
4. Create example strategy demonstrating the new feature (crates/backtest/examples/your_feature_example.rs)

Expose New Core API to Python

1. Define PyO3 wrapper module for Rust types and methods using #[pyclass] and #[pymethods] (crates/core/src/python.rs)
2. Build wheel via build.py and verify binding signature matches Python type hints (build.py)
3. Add Python-facing docstrings and examples showing integration with backtester or live trader (crates/core/src/python.rs)
4. Update version in crates/core/Cargo.toml and trigger wheel build in CI (Cargo.lock)

• Rust + PyO3 — Deterministic execution with C-like performance (nanosecond-precision timing), memory safety eliminating use-after-free bugs in latency-sensitive code, and seamless Python bindings for strategy development without sacrificing speed.
• Append-only Event Store — Enables deterministic replay for backtesting and debugging; every production trade is auditable from the event log; allows state reconstruction at any point in time without losing information.
• Multi-Adapter Pattern (Binance, Kraken, Coinbase, etc.) — Venue-agnostic core engine allows testing strategies across exchanges and building venue-neutral algorithms; reduces lock-in to single broker and enables portfolio optimization across multiple venues.
• Async/Await (Tokio) — Efficient concurrent handling of multiple websocket feeds and REST API calls without thread overhead; enables thousands of concurrent order and data streams on modest hardware.
• Cap'n Proto (Message Serialization) — Zero-copy deserialization for latency-critical market data; deterministic serialization ensures identical binaries on replay; schema evolution for adapter protocol changes.

• Determinism-first architecture (immutable event log, no local state caching)

  • Why: Trading systems must be reproducible for regulatory compliance and debugging; requires re-executing all events on state queries.
  • Consequence: Slight latency overhead on state reads (~1-5ms) compared to cache-first systems; forces careful consideration of event volume and system throughput; simplifies correctness proofs but requires discipline in strategy code.

• Single-threaded event loop per strategy (sequentially process events)

  • Why: Eliminates race conditions in position/order state; ensures consistent snapshots across correlated instruments.
  • Consequence: CPU-bound indicators or risk checks can block event processing; strategies must use async I/O; does not exploit multi-core for single-strategy computation (though can run multiple strategies in separate processes).

• Production-grade exchange adapters for 17+ venues vs. open exchange library dependency

  • Why: Standard
  • Consequence: undefined

1. Cap'n Proto schema changes: Serialization format is defined in .capnp files (see .cargo/audit.toml)—breaking changes require schema versioning and migration. 2. Exchange API rate limits: Each adapter (crates/adapters) has different limits; backtest mode bypasses them but live mode will silently queue/drop requests if not tuned. 3. Determinism assumption: Event-driven design requires wall-clock time mocking in tests (crates/testkit)—real system time in backtest breaks reproducibility. 4. PostgreSQL as optional persistence: Some features assume persistence (risk checks, order replay) but fall back to in-memory; partial schema in crates/persistence/ means migrations must be manual. 5. Python-Rust FFI stability: PyO3 bindings (crates/pyo3) lock to specific Python versions (check Cargo.toml pyO3 features)—pip install on unsupported Python 3.x will fail silently. 6. Docker entrypoint assumptions: .docker/entrypoint.sh assumes /data mount and specific env vars (see .env.example); missing vars cause cryptic startup failures.

• Deterministic Event-Driven Architecture — Nautilus Trader's core guarantee—replay same events in same order yields identical trade results; critical for strategy backtesting and production validation
• Cap'n Proto Serialization — Zero-copy message format used for order/trade persistence and IPC in crates/serialization; enables microsecond latency and schema evolution
• Time Mocking / Virtual Clocks — Backtesting requires deterministic time control (no wall-clock drift); crates/testkit provides mock clocks so tests are repeatable
• PyO3 FFI (Foreign Function Interface) — Bridges Python strategy code to Rust engine (crates/pyo3); enables rapid strategy iteration while keeping core execution in performant compiled code
• Command-Query Responsibility Segregation (CQRS) — Order submission (command) and fill events (query) are separated in crates/execution; allows audit trails and async acknowledgment without tight coupling
• Portfolio State Reconciliation — crates/portfolio maintains position and cash state; must reconcile with exchange fills and handle partial fills, rejections, and latency—core risk control
• Risk Framework / Pre-trade Checks — crates/risk applies position limits, margin checks, and order validation before exchange submission; prevents catastrophic losses and regulatory violations

• TA-Lib/ta-lib-python — Technical indicator library that Nautilus Trader's crates/indicators might integrate or reference for algorithm implementations
• blueshift-finance/blueshift — Algorithmic trading platform in Python; Nautilus Trader's closest functional competitor (different arch: pure Python vs. Rust-native)
• vnpy/vnpy — Chinese open-source trading framework; similar multi-exchange adapter pattern and event-driven design
• quantopian/zipline — Backtesting engine that Nautilus Trader builds upon conceptually (deterministic replay, portfolio state)
• ccxt/ccxt — Cryptocurrency exchange REST/WS client library; Nautilus Trader adapters wrap these or implement native protocols

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for pre-commit hooks validation

The repo has extensive pre-commit hooks (.pre-commit-hooks/) for code quality (cargo_fmt_stable.sh, check_copyright_year.sh, check_dst_conventions.sh, etc.) but lacks automated integration tests verifying these hooks work correctly across the workspace. This would catch hook breakage early and ensure contributors can rely on them. Given the 40+ crates in the workspace, a dedicated CI workflow testing hook execution on sample violations would be high-value.

• [ ] Create .github/workflows/pre-commit-hooks-test.yml workflow
• [ ] Add test scenarios in a new crates/testkit/pre-commit-fixtures/ directory with intentional violations (bad formatting, missing copyright, invalid cargo conventions)
• [ ] Verify each hook in .pre-commit-hooks/ correctly detects and reports violations
• [ ] Ensure workflow runs on PRs and reports hook failures clearly

Add adapter pattern tests for all exchange adapters

The repo contains 18+ exchange adapters (crates/adapters/binance, betfair, kraken, coinbase, dydx, etc.) but the file structure suggests no standardized test suite validating the adapter interface contract. Adding comprehensive tests ensuring all adapters implement required traits (market data subscription, order submission, position tracking) would prevent integration regressions and help new contributors understand the adapter pattern.

• [ ] Create crates/adapters/adapter-tests/ crate with shared test macros
• [ ] Define canonical adapter interface test suite covering: connection lifecycle, market data streaming, order lifecycle, error handling
• [ ] Apply tests to at least 5 adapters as examples (binance, kraken, coinbase, dydx, hyperliquid)
• [ ] Document adapter implementation checklist in crates/adapters/README.md

Implement Cargo feature dependency validation in CI

With 40+ interdependent crates (core, execution, portfolio, indicators, etc.) and complex workspace dependencies, there's high risk of feature flag combinations creating broken builds. The repo lacks automated CI checking if common feature combinations compile (e.g., 'live' + 'backtest', 'persistence' with/without 'serialization'). This would catch dependency DAG issues early.

• [ ] Create .github/workflows/feature-combinations.yml workflow
• [ ] Define matrix of N common feature combinations in Cargo.toml comments or separate config
• [ ] Run 'cargo check' and 'cargo test' for each combination across critical crates (core, execution, portfolio, live)
• [ ] Report which combinations fail and why in CI output

1. Add missing tests for crates/indicators: The indicators crate (technical analysis) lacks unit test coverage for edge cases (e.g., NaN handling, zero-length windows)—add parametrized tests in crates/indicators/src/tests/ for each indicator type. 2. Document exchange adapter API gaps: crates/adapters/ has 18 exchanges but no compatibility matrix showing which endpoints each supports (Orders, Positions, Balances, etc.)—create a markdown table in docs/ and update crates/adapters/README. 3. Implement backpressure handling in event loop: crates/core/src/engine.rs processes events sequentially but doesn't bound the event queue—add metrics and optional backpressure logic (drop vs. queue strategy) when queue depth exceeds threshold.

• Low · Environment Configuration File Template Exposed — .env.example. The .env.example file contains template environment variables including NAUTILUS_PATH. While this is a template, it demonstrates the expected structure of sensitive configuration. If developers copy this without proper care, path information could leak. Fix: Ensure documentation clearly states that .env should never be committed to version control. Add explicit warnings in .env.example about sensitive data. Consider using a .env.example.encrypted approach or documented schema without actual paths.
• Medium · Rust Edition 2024 - Potential Compatibility Risks — Cargo.toml (workspace.package). The workspace specifies edition = '2024' which is extremely new and may have limited tooling maturity and community testing. This could introduce unexpected vulnerabilities or breaking changes not yet discovered. Fix: Verify that Rust edition 2024 is intentional and well-tested for production use. Consider using a stable edition (2021) for production-grade software unless 2024-specific features are critical.
• Medium · Broad Workspace With Multiple Adapter Integrations — Cargo.toml (workspace members). The workspace includes 18 adapter crates integrating with various exchanges and services (Binance, Kraken, Coinbase, etc.). Each external integration increases the attack surface for supply chain attacks and compromised dependencies. Fix: Implement strict dependency auditing for each adapter. Use cargo-audit and the existing .supply-chain/audits.toml actively. Consider dependency isolation and sandboxing for external integrations. Regular security reviews of adapter code are critical.
• Medium · Third-Party Exchange Integration Security Risk — crates/adapters/* (various exchange adapters). Multiple adapters integrate with exchanges (Binance, Kraken, Bybit, Deribit, etc.). These adapters likely handle API keys, credentials, and sensitive trading data. Compromise of adapter code could expose user credentials. Fix: Implement credential management best practices: never log API keys, use secure credential storage, implement rate limiting, validate all exchange responses, implement connection timeouts, and audit adapter code regularly.
• Low · Pre-commit Hooks Complex Security Checks — .pre-commit-hooks/. Multiple pre-commit hooks check for various conventions and patterns (.pre-commit-hooks/* files). While beneficial, the complexity increases risk of logic errors in validation scripts. Fix: Ensure all pre-commit hook scripts are well-tested, version-controlled, and reviewed. Document the purpose of each check. Consider using standard tools rather than custom scripts where possible.
• Low · Docker Configuration Exposure — .docker/docker-compose.yml, .docker/*.dockerfile. Multiple Dockerfiles and docker-compose configuration files (.docker/*) exist. These may contain hardcoded configurations or expose internal networking details. Fix: Review Docker configs for hardcoded credentials, default passwords, or exposed internal ports. Use Docker secrets for sensitive data. Ensure base images are regularly updated and scanned.
• Low · GitHub Actions Workflows Security — .github/workflows/. Multiple GitHub workflows (.github/workflows/*.yml) exist for CI/CD including security-audit.yml and codeql-analysis.yml. These workflows have elevated privileges and could be targets for attack. Fix: Implement workflow security best practices: pin action versions with full commit hashes (not tags), limit job permissions to minimum required, audit secrets access, review external action dependencies, use environments for sensitive operations.
• Low · Complex Cryptography Module Requires Scrutiny — crates/cryptography/. The codebase includes a cryptography crate (crates/cryptography) for a trading engine. Cryptographic implementations are critical for security. Fix: Ensure cryptographic code uses well-tested libraries (not custom implementations where possible). Conduct regular security audits of crypto code. Use established algorithms and key management practices. Document all cryptographic functions.
• Medium · Event Store Module Potential Data Sensitivity — crates/event_store/. The event store (crates/event_store) persists trading events which may contain sensitive financial data, account information, or trading strategies. Fix: Implement encryption at rest for event data. Implement audit logging

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/nautechsystems/nautilus_trader shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live nautechsystems/nautilus_trader repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/nautechsystems/nautilus_trader.

What it runs against: a local clone of nautechsystems/nautilus_trader — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in nautechsystems/nautilus_trader | Confirms the artifact applies here, not a fork | | 2 | License is still LGPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch develop exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of nautechsystems/nautilus_trader. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/nautechsystems/nautilus_trader.git
#   cd nautilus_trader
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of nautechsystems/nautilus_trader and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "nautechsystems/nautilus_trader(\\.git)?\\b" \\
  && ok "origin remote is nautechsystems/nautilus_trader" \\
  || miss "origin remote is not nautechsystems/nautilus_trader (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(LGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"LGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is LGPL-3.0" \\
  || miss "license drift — was LGPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify develop >/dev/null 2>&1 \\
  && ok "default branch develop exists" \\
  || miss "default branch develop no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "crates/core" \\
  && ok "crates/core" \\
  || miss "missing critical file: crates/core"
test -f "crates/execution" \\
  && ok "crates/execution" \\
  || miss "missing critical file: crates/execution"
test -f "crates/adapters" \\
  && ok "crates/adapters" \\
  || miss "missing critical file: crates/adapters"
test -f ".github/workflows/build.yml" \\
  && ok ".github/workflows/build.yml" \\
  || miss "missing critical file: .github/workflows/build.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/nautechsystems/nautilus_trader"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.