NautilusTrader 2.0 was der Rust-Kern für Python-Trader ändert.

NautilusTrader ist eine quelloffene Trading-Engine, in der dieselbe Strategie im Backtest und im Live-Betrieb läuft. Mit Version 2.0 wechselt der Kern von Cython zu Rust, Python bleibt die Ebene, in der Sie Strategien schreiben, konfigurieren und steuern. Stand 06.10.2026 ist 2.0.0 aber noch nicht final: Aktuell ist der Release Candidate 2.0.0rc6, die letzte stabile Version auf PyPI heißt 1.231.0, und die Entwickler raten selbst davon ab, Release Candidates mit echtem Kapital einzusetzen. Für Python-Trader heißt das: Die Richtung steht fest, die Migration ist echte Arbeit mit vielen geänderten Namen und einigen stillen Verhaltensänderungen, und der Zeitpunkt sollte zu Ihrem Live-Betrieb passen. Dieser Artikel erklärt, was sich ändert, wie Sie NautilusTrader gegenüber vectorbt, Backtrader und LEAN einordnen und wie ein sauberer Migrationsplan aussieht. Grundlage sind PyPI, das GitHub-Repository und der offizielle Migrationsleitfaden.

Hinweis: Dieser Beitrag gibt den Rechts- und Steuerstand zum unten angegebenen Datum allgemein wieder. Er ist keine Rechts- oder Steuerberatung und ersetzt nicht die Prüfung Ihres Einzelfalls durch eine Rechtsanwältin, einen Rechtsanwalt, eine Steuerberaterin oder einen Steuerberater. Alle Angaben ohne Gewähr für Vollständigkeit und Aktualität.

Was ist NautilusTrader?

NautilusTrader ist eine Open-Source-Plattform für algorithmischen Handel unter der Lizenz LGPL-3.0. Die Dokumentation beschreibt sie als Rust-native Engine für mehrere Anlageklassen und Handelsplätze. Unterstützt werden laut Projekt Krypto-Börsen (zentral und dezentral), Devisen, Aktien, Futures, Optionen und Wettbörsen. Fertige Anbindungen gibt es unter anderem für Interactive Brokers, Binance, Bybit, OKX, Kraken, Coinbase, Deribit und Betfair sowie für die Datenanbieter Databento und Tardis.

Der Kern ist ereignisgesteuert: Die Engine verarbeitet Marktdaten, Orders und Ausführungen als Abfolge einzelner Ereignisse mit Zeitstempeln in Nanosekunden-Auflösung. Das ist langsamer als ein vektorisierter Backtest, bildet aber Orderlogik, Teilausführungen und Zustände realistischer ab. Das Projekt kennt drei Betriebsarten:

• Backtest: Simulation auf historischen Daten (Quotes, Trades, Bars, Orderbuch).
• Sandbox: Echtzeitdaten mit simulierter Ausführung, also Paper-Trading.
• Live: Betrieb auf Paper- oder echten Konten.

Das Versprechen dahinter: Die Strategie, die Sie im Backtest geprüft haben, ist derselbe Code, der später Orders sendet. Wer bisher in Python recherchiert und die Live-Version neu geschrieben hat, kennt die Fehlerquelle, die damit wegfällt. Grundlagen zu Backtest-Architekturen finden Sie im Artikel Backtesting mit Python von Grund auf.

Was ändert sich mit Version 2.0?

Die zentrale Änderung ist der Unterbau. Version 1.x nutzte einen Kern in Cython, also Python-nahem Code, der zu C kompiliert wird. Version 2 setzt auf einen Kern in Rust, angebunden über PyO3, eine Bibliothek, die Rust-Code als Python-Modul verfügbar macht. Laut Projekt ist Python in v2 die „Steuerebene“ für Strategielogik, Konfiguration und Orchestrierung, die Rust-Engine erledigt Ereignisverarbeitung, Netzwerk und Ausführung. Auf PyPI stehen vorkompilierte Pakete (Wheels) für Python 3.12 bis 3.14 auf Linux, macOS (ARM) und Windows bereit; für diese Plattformen müssen Sie den Rust-Kern nicht selbst übersetzen.

Für Ihren Code bedeutet das vor allem neue Namen und neue Muster. Der offizielle Migrationsleitfaden listet Dutzende Änderungen, darunter:

• Importe: TradingNode heißt jetzt LiveNode, viele Klassen liegen direkt unter nautilus_trader.model oder nautilus_trader.backtest.
• Callbacks: on_quote_tick wird zu on_quote, subscribe_quote_ticks zu subscribe_quotes, on_order_book zu on_book.
• Konfiguration: Config-Klassen sind keine msgspec-Strukturen mehr, sondern Rust/PyO3-Typen. Eigene Felder werden als Keyword-Argumente im Konstruktor deklariert. Strategien registrieren Sie explizit am Node, statt sie in der Konfiguration zu verschachteln.
• Datentypen: Order.avg_px und Order.slippage sind jetzt Decimal statt float. Vergleiche mit Float-Literalen können deshalb fehlschlagen. Leere Enum-Werte wie „keine Orderseite“ sind None.
• Live-Lebenszyklus: LiveNode.run() oder run_async() ersetzt das bisherige Starten und Pollen.

Dazu kommen Brüche zwischen den Release Candidates selbst. In rc6 wurde etwa der BitMEX-Adapter entfernt, Gebühren werden nicht mehr am Instrument, sondern über das Gebührenmodell des Handelsplatzes konfiguriert. Wer früh einsteigt, migriert also nicht einmal, sondern zieht mehrmals nach.

Was bedeutet der Release-Candidate-Status für Live-Systeme?

Ein Release Candidate (RC) ist eine Vorabversion, die funktional weitgehend fertig ist, deren Schnittstellen sich aber noch ändern dürfen. Die 2.0-Reihe läuft seit Ende Juni 2026 in diesem Modus. Die Daten laut PyPI:

Die Entwickler sind in der README deutlich: Release Candidates seien für Tests durch die Community gedacht, nicht für Produktivumgebungen wie Live-Trading mit echtem Kapital. Für den stabilen 2.x-Zweig ist ein formaler Deprecation-Prozess angekündigt, also geordnete Übergangsfristen für API-Änderungen. Bis dahin gilt der Hinweis, dass Breaking Changes zwischen Releases möglich sind. Der angestrebte Rhythmus ist ein Release alle zwei Wochen.

Gleichzeitig läuft für die 1.x-Reihe eine Uhr. Laut Migrationsleitfaden bekommt der Branch develop_v1 nach dem Wechsel auf v2 nur noch für etwa drei Monate kritische Sicherheits-Backports, keine neuen Funktionen und keine Angleichung an v2. Wer heute ein Live-System auf 1.231.0 betreibt, steht also zwischen zwei Risiken: zu früh auf einen RC wechseln oder zu spät auf eine Version, die nicht mehr gepflegt wird.

Gleiche Engine für Backtest und Live: Vor- und Nachteile.

Der größte praktische Vorteil ist die gemeinsame Ausführungslogik. Wenn ich Trading-Systeme entwickle, entstehen viele Fehler genau an der Übergabe: Der Backtest rechnet mit Schlusskursen, der Live-Code reagiert auf Ticks; der Backtest kennt keine Teilausführung, der Broker schon. Eine Engine mit gleichem Zeitmodell und gleicher Orderlogik in beiden Welten reduziert diese Lücke deutlich.

• Vorteil Parität: Strategie- und Ausführungsalgorithmus-Code ist in Backtest und Live identisch.
• Vorteil Realismus: Orderbuch-Daten, Orderarten wie IOC, FOK oder GTD und bedingte Orders lassen sich im Backtest abbilden.
• Vorteil Betrieb: Zustand lässt sich laut Dokumentation in Redis oder PostgreSQL sichern (PostgreSQL in v2 mit Einschränkungen, siehe unten), die Engine läuft in Docker.
• Nachteil Tempo der Recherche: Ereignisgesteuerte Backtests sind für breite Parameterstudien deutlich aufwendiger als vektorisierte Werkzeuge.
• Nachteil Komplexität: Sie arbeiten mit Actors, Nodes, Message Bus und Konfigurationsobjekten. Die Einarbeitung dauert länger als bei einem schlanken Backtest-Skript.
• Nachteil Abhängigkeit: Ein großer Teil der Logik liegt in Rust. Fehler im Kern beheben Sie nicht mal eben selbst in Python.

Realistisch bleibt: Gleiche Engine heißt nicht gleiche Ergebnisse. Slippage, Latenz, abgelehnte Orders und Verbindungsabbrüche im Live-Betrieb bildet auch die beste Simulation nur näherungsweise ab. Parität beseitigt Implementierungsfehler, nicht Modellfehler und nicht Überanpassung.

NautilusTrader, vectorbt, Backtrader oder LEAN?

Die vier Werkzeuge lösen unterschiedliche Probleme. Die Tabelle fasst den Stand Oktober 2026 zusammen.

Eine pragmatische Faustregel: vectorbt für die schnelle Breitensuche in der Recherche, wenn Sie Tausende Varianten prüfen wollen (mehr dazu im Artikel vectorbt Pro: Features, Performance, Praxis). NautilusTrader oder LEAN, wenn aus einer Idee ein laufendes System mit realistischer Ausführung werden soll. LEAN bietet ein großes Ökosystem und eine Cloud-Plattform, NautilusTrader ist stärker auf Krypto, Orderbuch-Daten und selbst betriebene Infrastruktur ausgerichtet. Backtrader ist für bestehende Projekte noch nutzbar, für neue Systeme würde ich wegen fehlender Releases seit April 2023 genau prüfen, ob das Risiko tragbar ist.

Sinnvoll kann auch eine Kombination sein: Ideen werden vektorisiert vorsortiert, die wenigen Kandidaten dann ereignisgesteuert mit Kosten- und Ausführungsmodell nachgetestet.

Welche Grenzen und Risiken hat die Migration?

Der Migrationsleitfaden benennt offene Lücken selbst. Einige davon können ein bestehendes System blockieren:

• Eigene Adapter: Laut Leitfaden gibt es für selbst geschriebene Python-Adapter (Unterklassen von LiveDataClient oder LiveExecutionClient) noch kein v2-Gegenstück; eine Schnittstelle dafür ist geplant. Wer einen eigenen Broker angebunden hat, muss diesen Punkt vor jeder Planung klären.
• Persistenz: Der PostgreSQL-Cache speichert in v2 keinen Actor- oder Strategiezustand; Redis unterstützt das.
• Datenkatalog: Ältere Order-Event-Daten im Katalog sind mit dem neuen Schema nicht lesbar und müssen neu erzeugt oder migriert werden. Der BacktestNode unterstützt in der Katalog-Konfiguration keine Custom Data und keine Data Frames.
• Stille Verhaltensänderungen: Ohne gesetztes default_leverage nutzen Margin-Konten im Backtest jetzt Hebel 10, in v1 ohne Hebel. Dreht eine Position über null, gilt der Preis der drehenden Ausführung als neuer Einstiegspreis; v1 behielt den alten. Fehler in eigenen Portfolio-Statistiken werden geloggt statt geworfen.

Gerade der Hebel-Punkt zeigt das Risiko: Der Code läuft fehlerfrei durch, die Kennzahlen sehen plausibel aus, sind aber mit einem anderen Risikoprofil gerechnet. Ein Hebel verstärkt Gewinne und Verluste gleichermaßen; im Live-Betrieb kann eine falsch übernommene Einstellung zu Verlusten bis zum Totalverlust des eingesetzten Kapitals führen. Ein Vergleich der Kennzahlen zwischen v1 und v2 auf identischen Daten ist deshalb Pflicht, nicht Kür.

Migrationsplan von 1.x auf 2.0 in sechs Schritten.

Für einen solchen Versionssprung empfiehlt sich ein schrittweiser Abgleich statt eines harten Umstiegs:

1. Bestandsaufnahme: Welche Adapter, Datenformate, eigenen Statistiken und Persistenz-Backends nutzen Sie? Gleichen Sie die Liste mit den bekannten Lücken im Leitfaden ab.
2. Getrennte Umgebung: v1 und v2 importieren beide als nautilus_trader. Installieren Sie v2 nie in die Umgebung Ihres Live-Systems.
3. Referenzläufe sichern: Speichern Sie mit 1.231.0 Backtest-Ergebnisse auf festen Datenständen: Orders, Fills, Positionen, Kennzahlen.
4. Code portieren: Importe, Callback-Namen, Config-Klassen, Decimal-Vergleiche. Setzen Sie Hebel und Gebühren explizit, statt sich auf Standardwerte zu verlassen.
5. Abgleich: Gleiche Daten, gleiche Strategie, Ergebnisse auf Ebene einzelner Orders vergleichen. Jede Abweichung muss erklärbar sein. Das Repository enthält zusätzlich ein Skript für Laufzeit-Vergleiche zwischen v1 und v2.
6. Sandbox vor Live: Erst Paper-Trading über Wochen, dann Live mit kleinem Volumen, und zwar erst mit einer finalen 2.x-Version.

Die Installation eines RC in einer frischen Umgebung sieht laut Leitfaden so aus:

# eigene Umgebung nur für v2
uv venv --python 3.14
source .venv/bin/activate
uv pip install --pre nautilus_trader

# ohne --pre: installiert die stabile 1.x-Reihe
pip install -U nautilus_trader

Pinnen Sie die RC-Version in Ihren Abhängigkeiten exakt. Sonst holt das nächste Update unbemerkt den nächsten RC mit neuen Brüchen.

Was Sie jetzt tun können: Einstieg je nach Ausgangslage.

Ob Sie jetzt handeln, hängt von Ihrer Ausgangslage ab:

• Neue Projekte ohne Altlast: Starten Sie direkt mit v2 in der Recherche und im Backtest. Die Dokumentation beschreibt bereits v2, ein späterer Umbau von 1.x entfällt. Live erst mit finaler Version.
• Bestehende 1.x-Systeme im Live-Betrieb: Jetzt parallel migrieren und abgleichen, aber produktiv auf 1.231.0 bleiben, bis 2.0.0 final ist und Ihre Abgleiche sauber sind. Planen Sie das Sicherheits-Backport-Fenster von etwa drei Monaten ein.
• Systeme mit eigenen Broker-Adaptern: Zuerst klären, wann die Adapter-Schnittstelle für v2 verfügbar ist. Ohne sie ist eine Migration nicht abschließbar.
• Reine Recherche mit vielen Varianten: Hier bringt NautilusTrader wenig. Ein vektorisiertes Werkzeug ist schneller am Ziel.

Rust-Kenntnisse brauchen die meisten Python-Trader dafür nicht; entscheidend ist, dass Rust-Kern und Python-API getrennte Verantwortungen haben. Bei der Umsetzung oder Migration eines konkreten Systems unterstütze ich mit Trading-Automatisierung: Architektur, Tests, Abgleich und Betrieb, ohne Anlageberatung.

Häufige Fragen.

Ist NautilusTrader 2.0 schon final erschienen?

Nein. Stand 06.10.2026 ist die aktuelle Vorabversion 2.0.0rc6, seit 05.10.2026 auf PyPI, die letzte stabile Version auf PyPI ist 1.231.0 vom 02.08.2026. Die Entwickler empfehlen Release Candidates nicht für Produktivumgebungen wie Live-Trading mit echtem Kapital. Prüfen Sie vor einer Entscheidung den aktuellen Stand auf PyPI und in den Release Notes.

Wie installiere ich NautilusTrader 2.0?

Mit pip oder uv und dem Schalter --pre, zum Beispiel uv pip install --pre nautilus_trader in einer frischen virtuellen Umgebung. Ohne --pre installiert pip die stabile 1.x-Reihe, deren API nicht zur v2-Dokumentation passt. Da v1 und v2 beide als nautilus_trader importieren, gehören sie nie in dieselbe Umgebung. Fertige Wheels gibt es für Python 3.12 bis 3.14, ein Rust-Compiler ist dafür nicht nötig.

Muss ich von NautilusTrader 1.x auf 2.0 migrieren?

Mittelfristig ja, wenn Sie das Projekt weiter nutzen wollen. 1.231.0 ist laut Release Notes als letzte 1.x-Version vorgesehen, neue Funktionen gibt es nur noch in v2. Nach dem Umstieg erhält der v1-Zweig laut Migrationsleitfaden nur etwa drei Monate kritische Sicherheits-Backports. Sinnvoll ist, jetzt parallel zu migrieren und Ergebnisse abzugleichen, produktiv aber erst mit einer finalen 2.x-Version umzustellen.

Was ist der Unterschied zwischen NautilusTrader und vectorbt?

vectorbt rechnet vektorisiert mit NumPy und Numba und prüft sehr viele Parameterkombinationen gleichzeitig, ideal für die schnelle Recherche. NautilusTrader verarbeitet Daten ereignisgesteuert, bildet Orderlogik und Ausführung realistischer ab und nutzt dieselbe Engine für Backtest und Live-Betrieb. Beides lässt sich kombinieren: vectorbt zum Vorsortieren, NautilusTrader für den Nachtest und den Betrieb.

Brauche ich Rust-Kenntnisse für NautilusTrader 2.0?

Für Strategien in Python nicht. Python bleibt in v2 die Ebene für Strategielogik, Konfiguration und Steuerung, der Rust-Kern kommt als fertiges Paket. Rust-Kenntnisse helfen, wenn Sie Fehler im Kern analysieren, eigene Komponenten nativ bauen oder ein System ganz ohne Python-Laufzeit betreiben wollen.

Quellen und Stand.

• nautilus-trader (Release-Historie) — PyPI
• nautilus_trader README — Nautech Systems / GitHub
• Migrate from v1 to v2 (MIGRATION_V2.md) — Nautech Systems / GitHub
• Overview (Concepts) — NautilusTrader Documentation
• Release Notes (RELEASES.md, u. a. 1.231.0 und 2.0.0rc6) — Nautech Systems / GitHub
• vectorbt — GitHub (polakowo)
• LEAN Algorithmic Trading Engine — QuantConnect / GitHub
• backtrader (Release-Historie) — PyPI

Stand: 6. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen ein Trading-System auf NautilusTrader aufbauen oder von 1.x sauber migrieren? Unverbindlich anfragen — wir klären Architektur, Abgleichtests und den Weg in den Live-Betrieb. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.