KI-native Runtime für Kraken-Trading-Strategien

Nein. Ihr Strategie-Code verbindet sich direkt mit Kraken und sendet Befehle basierend auf Ihrer eigenen Logik, Ihren Kontoberechtigungen und Ihrer Integrationsmethode. TradingHost stellt lediglich die Runtime bereit, in der dieser Code ausgeführt wird.

Nein. Der API-Zugang wird von Kraken bereitgestellt. Sie sind selbst für Ihr Kraken-Konto, die API-Berechtigungen, Zugangsdaten und die Einhaltung der Nutzungsbedingungen von Kraken verantwortlich.

Nein. TradingHost ist die Cloud-Runtime, in der Ihr eigener Strategie-Code ausgeführt wird. Wir bieten keine Signale, KI-Vorhersagemodelle oder vorgefertigte Bots an. Mit TradingHost schreiben oder generieren Sie Ihre Strategie selbst (oft mit Cursor oder Claude Code), verwalten sie als Ihren eigenen Code auf GitHub und nutzen TradingHost, um sie live auszuführen. Während Produkte wie 3Commas oder Cryptohopper die Strategielogik vorgeben, führt TradingHost Ihre eigene Strategie aus.

AWS und DigitalOcean bieten Ihnen reine Rechenleistung. Sie müssen sich selbst um Betriebssystem-Updates, Container-Orchestrierung, Log-Weiterleitung, Secret-Rotation, Ausfallsicherheit in anderen Regionen und das Uptime-Monitoring kümmern. TradingHost bietet Ihnen eine verwaltete Runtime, die speziell für Trading-Strategien entwickelt wurde: GitHub-natives Deployment, MCP-basierte Steuerung direkt aus KI-IDEs sowie integrierte Log- und Health-Dashboards. Wenn Sie die Infrastruktur selbst verwalten möchten, ist AWS eine Option. Wenn Sie die Runtime als Managed Service nutzen wollen, ist TradingHost der direktere Weg.

Ja. TradingHost führt Python-Strategien aus. Wählen Sie einfach die Framework-Runtime, die zu Ihrem Stack passt, oder deployen Sie Ihr eigenes Repository.

Ja. TradingHost unterstützt jede Programmiersprache, die in einem Container ausgeführt werden kann.

Ja. CCXT stellt zwei separate Exchanges bereit: kraken für Spot und Margin sowie krakenfutures für Perpetual- und klassische Futures. Beide erfordern unterschiedliche API-Key-Sets. TradingHost führt Ihren CCXT-Container für eine oder beide Schnittstellen aus. Hinterlegen Sie einfach die entsprechenden Zugangsdaten als Secrets. Details zur Einrichtung finden Sie in der Dokumentation zur CCXT-Framework-Runtime.

Ja. Spot-Keys werden in Ihrem Hauptkonto auf kraken.com erstellt, während Futures-Keys separat unter futures.kraken.com generiert werden. Da sich die beiden Authentifizierungsmethoden unterscheiden (HMAC-SHA512 mit API-Sign für Spot, APIKey + Authent-Header für Futures), benötigt eine Strategie, die auf beiden Märkten handelt, zwei Sätze von Zugangsdaten und in der Regel zwei separate Clients.

Für reines Spot-Trading bietet Freqtrade erstklassigen Support für Kraken. Für plattformübergreifendes Trading oder Perpetual Futures deckt CCXT sowohl kraken als auch krakenfutures über eine einzige Bibliothek ab. Der kraken-Connector von Hummingbot ist die sauberste Option für Market-Making, unterstützt jedoch nur Spot.

Ja, sofern Ihr Projekt entsprechend konzipiert ist. Sie können mehrere Strategieprozesse oder -dienste innerhalb einer Runtime ausführen oder sie zur besseren Isolierung und betrieblichen Klarheit auf verschiedene Runtimes aufteilen. Weitere Informationen finden Sie auf der TradingHost-Runtime-Seite unter dem Multi-Strategie-Modell.

Der schnellste Weg ist das Forken einer TradingHost-Framework-Runtime: CCXT, Freqtrade oder Hummingbot bieten sofort einsatzbereite Projekte. Alternativ können Sie Ihr eigenes GitHub-Strategie-Repository anbinden. Das Verknüpfen eines GitHub-Repositorys und das Erstellen einer Strategie ist kostenlos. Die Tarife für die Runtimes finden Sie auf der Preisseite.

In Ihrem von GitHub gesteuerten Secrets-Workflow. TradingHost liest sie zur Laufzeit über GitHub-Repository-Secrets, Environment-Secrets oder Ihren eigenen freigegebenen Secret-Management-Prozess aus. TradingHost benötigt zu keinem Zeitpunkt Zugriff auf Ihre API-Keys oder Secrets. Details zum Sicherheitsmodell finden Sie unter Plattform-Secrets.

Nein. Strategien sollten niemals Auszahlungsrechte benötigen. Nutzen Sie stattdessen eingeschränkte Berechtigungen (Guthaben abfragen, offene Orders abfragen, Orders erstellen/ändern, Websocket-Zugriff) und richten Sie, wo möglich, ein IP-Whitelisting ein.

Ja. TradingHost unterstützt die MCP-basierte Steuerung für KI-IDEs wie Cursor, Claude Code, GitHub Copilot und CLI-basierte KI-Agenten. Diese KI-Tools können Deployments prüfen, Logs einsehen, Strategien neu starten und Runtime-Workflows verwalten. MCP dient dabei als Steuerungs- und Monitoring-Schnittstelle, nicht als Pfad für die Trade-Ausführung. Details dazu finden Sie unter MCP-Steuerung.

Beides. Die MCP-Steuerungsoberfläche funktioniert über CLI-basierte Agenten (Claude Code CLI, eigene MCP-Clients, geskriptete MCP-Aufrufe) ebenso gut wie aus einer IDE heraus. Der GitHub-native Deployment-Workflow läuft zudem völlig ohne KI-Tools: Ein ganz normaler git push auf Ihren Main-Branch stößt ein erneutes Deployment an.

Die Runtime erkennt den Absturz und stellt die relevanten Logs sowie Statusinformationen bereit. Sofern unterstützt, kann die betroffene Strategie neu gestartet werden, ohne andere im selben Container laufende Strategien zu beeinträchtigen. Ihr Strategie-Code bleibt weiterhin selbst für eine sichere Fehlerbehandlung, den Schutz vor doppelten Orders und Risikokontrollen verantwortlich. Details zu Logs und Status finden Sie unter Observability.

Kraken erfordert pro API-Key monoton steigende Nonces. Jede Form von Parallelisierung führt hier zu Fehlern. Nutzen Sie einen Key pro Worker-Prozess, verwenden Sie eine Nonce mit Nanosekunden-Auflösung und vergrößern Sie das Nonce Window des Keys in den Kraken-Einstellungen, falls bei Lastspitzen weiterhin Kollisionen auftreten. TradingHost zeigt diese Fehler direkt in den Container-Logs an. Die vollständige Anleitung finden Sie oben im Abschnitt „Betriebliche Hinweise“.

Für Futures ja: demo-futures.kraken.com ist ein vollständiges Abbild der Live-Futures-API mit separater Registrierung und eigenen Keys. Für Spot gibt es keine öffentliche Sandbox. Testläufe (Dry-Runs) erfolgen daher entweder mit minimalen Ordergrößen gegen die Live-API oder gegen aufgezeichnete Daten innerhalb der Runtime.

TradingHost läuft in den Regionen EU und US-East. Wählen Sie die Region, die der Matching Engine Ihrer Strategie am nächsten ist. Details zu Routing und Latenzen finden Sie auf der Regionen-Seite.

Nein. TradingHost konzentriert sich rein auf die Live-Runtime und das Deployment. Backtesting gehört in Ihren Research-Stack, Ihr Framework oder in AlgoBuilder.