KI-native Runtime für bitFlyer-Handelsstrategien

Nein. Ihr Strategie-Code verbindet sich direkt mit bitFlyer und sendet Aufträge 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 bitFlyer bereitgestellt. Sie sind selbst für Ihr bitFlyer-Konto, die API-Berechtigungen, Ihre Zugangsdaten und die Einhaltung der Nutzungsbedingungen von bitFlyer verantwortlich.

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

AWS und DigitalOcean stellen reine Rechenleistung bereit. Sie müssen sich selbst um Betriebssystem-Updates, Container-Orchestrierung, Log-Weiterleitung, Secret-Rotation, Ausfallsicherheit in verschiedenen Regionen und Uptime-Monitoring kümmern. TradingHost bietet Ihnen eine verwaltete Runtime, die speziell für Trading-Strategien entwickelt wurde: GitHub-natives Deployment, MCP-Steuerung direkt aus KI-IDEs sowie integrierte Oberflächen für Logs und Systemzustand. 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 bindet bitFlyer über die vereinheitlichte Klasse `bitflyer` an und deckt den Spot-Handel für die Regionen Japan, USA und EU ab. Das japanische Crypto CFD-Produkt (FX_BTC_JPY) wird von CCXT nicht nativ als Standard-Primitive unterstützt. Für dieses Margin-Produkt sollten Sie die native bitFlyer Lightning API ansteuern. Details zur Einrichtung finden Sie auf der Seite zur CCXT-Framework-Runtime.

Nein. Das japanische Crypto CFD-Produkt (FX_BTC_JPY, ehemals Lightning FX) ist für bitFlyer Japan lizenziert und steht nur Nutzern mit einer japanischen Lizenz zur Verfügung. Konten von bitFlyer in den USA und der EU erhalten eine andere product_code-Zuweisung und können FX_BTC_JPY unabhängig von der Strategielogik nicht über die API handeln. Strategien, die dieses Produkt nutzen, müssen über ein in Japan lizenziertes bitFlyer-Konto laufen, und der Egress-IP-Bereich der Runtime sollte zur Jurisdiktion des Kontos passen.

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

Der schnellste Weg ist das Forken einer TradingHost-Framework-Runtime: CCXT für ein sofort einsatzbereites Spot-Projekt. Alternativ können Sie Ihr eigenes GitHub-Strategie-Repository verknüpfen, wenn Sie die native Lightning API für das japanische Crypto CFD-Produkt nutzen möchten. Das Verknüpfen eines GitHub-Repositorys und das Erstellen einer Strategie ist kostenlos. Die Runtime-Tarife finden Sie auf unserer Preisseite.

In Ihrem von GitHub verwalteten Secrets-Workflow. TradingHost liest diese zur Laufzeit über GitHub Repository Secrets, Environment Secrets oder Ihren eigenen freigegebenen Prozess zur Verwaltung von Secrets aus. TradingHost benötigt zu keinem Zeitpunkt die Verwahrung Ihres API-Schlüssels oder Secrets. Details dazu finden Sie unter Plattform-Secrets.

Nein. Strategien sollten niemals Auszahlungsrechte benötigen. Nutzen Sie stattdessen eingeschränkte Berechtigungen (Lesen, Handeln) und gegebenenfalls IP-Whitelisting.

Ja. TradingHost unterstützt die MCP-basierte Steuerung für KI-IDEs wie Cursor, Claude Code, GitHub Copilot und CLI-basierte KI-Agenten. 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. Mehr dazu erfahren Sie unter MCP-Steuerung.

Beides. Die MCP-Steuerung funktioniert über CLI-basierte Agenten (Claude Code CLI, eigene MCP-Clients, geskriptete MCP-Aufrufe) genauso zuverlässig wie direkt aus einer IDE. Der GitHub-native Deployment-Prozess funktioniert zudem völlig ohne KI-Tools: Ein einfacher Push auf Ihren Main-Branch stößt das Redeployment an.

Die Runtime erkennt den Absturz und stellt die relevanten Logs und Statusinformationen bereit. Sofern unterstützt, kann die betroffene Strategie neu gestartet werden, ohne andere im selben Container ausgeführte Strategien zu beeinträchtigen. Ihr Strategiecode ist weiterhin selbst für eine sichere Fehlerbehandlung, den Schutz vor doppelten Orders und Risikokontrollen verantwortlich. Siehe Observability für Logs und Status-Schnittstellen.

Die product_code-Zuordnung von bitFlyer ist nach Jurisdiktionen eingeschränkt. Derselbe Lightning API-Endpunkt bedient zwar Nutzer in JP, US und der EU, aber jede Jurisdiktion sieht eine andere Auswahl an verfügbaren Produkten. Ein US- oder EU-Konto, das auf FX_BTC_JPY (das JP-exklusive Crypto CFD-Produkt) zugreift, erhält unabhängig von den Berechtigungen des API-Schlüssels product-not-available-Fehler. Strategien, die vor 2024 auf „Lightning FX“ ausgerichtet waren, müssen seit der Umbenennung im März 2024 ebenfalls auf FX_BTC_JPY migriert werden. Legen Sie die product_code-Liste als Konfiguration fest, die auf der Jurisdiktion des Kontos basiert. Die vollständigen Anweisungen finden Sie oben im Abschnitt „Betriebliche Hinweise“.

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

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